Their Go services definitely read like a very beginner or prototype project. There are no tests, lots of global state, and little separation of concerns between request/response business logic etc.
Yes, it was a rush job. It started off nice, with tests and stuff. Then, we had to hit a deadline. I wrote 100% of the backend code. There were no other authors. Getting tons of functionality written without time to go back and refactor or improve as I improved my knowledge sucked, plus there were a lot of other non-code responsibilities at the time. If I had time, I would have spent a lot more time improving this code. For instance, I discovered gRPC interceptors way too late :-)
I recently started contributing to Buffalo, the Go web library by Mark Bates, and it addresses a lot of the issues we had, such as managing webpack for development environments.
Fun fact: I wrote a quick scraper in Go to relearn it before jumping in to the V2, and Francesc from Google did a code review of it for the first "Just For Func" episode. That made me realize just how much I had to improve my Go code: https://www.youtube.com/watch?v=eIWFnNz8mF4&t=2s
> Curious, since it was just you writing the backend, what was the reasoning behind doing microservices + react SPA. Both of those require a lot of commitment, and coordination. Microservices especially are something I'd be more likely to consider with a very large team/many teams instead of a single developer.
> Would you choose a microservice architecture again?
For microservices - we were planning integrations with messy systems. Think, having to poll an API, deal with XML, or have to do custom auth on lots of different incoming data endpoints. Microservices made it easy to add new experiments (like our ical service) easily without adding complicated logic to the central datastore. For reference, we already had API keys and signed agreements with four integration partners (POS, HR, etc) that we wanted to roll out in a short period, with more people lining up. We also wanted to add messaging capabilities beyond SMS quickly, so that's why we architected the bot like that - where some providers had strict sending limits (like twilio) but others did not require as much of a strict queue.
For react - I didn't pick that and I've actually completely unfamiliar with the library. I'm learning VueJS now and that would be my choice for future SPAs. Now that I understand how shared components work, I would have changed a lot of the system design.
I'm already starting on my next company. It's a monorepo with three folders: pkg (packages), cmd (any `package main` commands), and static (all JS, SCSS, etc that gets built by Webpack then wrapped up in a single bindata.go). The primary app is a monolith. However, I'm making it possible to add additional service, such as cron jobs in separate containers or a command line utility based on the same protobuf definition.
Curious, since it was just you writing the backend, what was the reasoning behind doing microservices + react SPA. Both of those require a lot of commitment, and coordination. Microservices especially are something I'd be more likely to consider with a very large team/many teams instead of a single developer.
Would you choose a microservice architecture again?
