Journey for a home-made back-end, part II: a team around a platform
TL; DR: Go is a great tool for back-end development, but is awesome when bringing different profiles on a project.
Last time, we introduced the journey to build our back-end. Since these early times, the core service for core information is up and running on a cluster and in use by the mobile developers. The development went from a single-person process (myself namely) to a team of two full-time, with three other people using the service, reviewing and giving feedback for their usage, current and to come (plus Cyril complaining that the code we write generates way too many assembly instructions 😁).
That’s why we switched to a new phase, with the back-end running and being used on one side, we can’t just commit and publish right away, especially with breaking changes. Each wave of new changes comes with more detailed explanations and tests cases which serve both as a guarantee of correctness and as examples (a contract between the server and client applications).
A retrospective on the choice of Golang
At the time of the publication of the previous article, we were still iterating a lot on the code base as we improved our understanding of the best practices and how to make the best out of the whole stack (on that part, the Gopher Slack was really amazing as a community, thanks guys!).
The choice was really helpful on two points:
- Being productive today without hindering tomorrow
- Understanding everything that is going on without having to write trivialities
Of course, no language is perfect and some problems were a bit harder to solve and express in a simple way, see the famous Go proverbs to understand the spirit behind it (did someone whisper generics?).
Clear is better than clever. Rob Pike
Working with Go has also influenced my thoughts about the number of features in a language and its relation with cognitive charge. Go has obviously taken a very opinionated side in this debate, but I tend to be annoyed by languages offer too many things to express the exact same thing.
However, Go’s fit to our project and team appeared as obvious when going through the on-boarding of other developers with another focus (the mobile developers taking a first look at the back-end) and new members joining the tech team. The tiny set of features to learn and understand allowed everyone to browse through the code base without having to ask for details on the behavior of components.
A quick tour of the components of the core API
As any Go project, the API is split in several packages each performing a set of tasks:
- The model package is a separate repository defining the core atomic types, structures, interfaces and behaviors. It is kept separate to be vendored in the API but also in other services.
- A sqlbase package handles the exchanges with the SQL database, performs the validations on the data (including checking links between entities for example: a user has to exist before a horse is linked to them).
- A mongo package does the same thing for data stored in a MongoDB, it corresponds to static data without relations or logically complex queries to perform.
- An authentication package calls an external service to validate user authentication. This one is rather small, but keeping it isolated from the API avoids rewrites if we decide to change the way we authenticate the clients. It simply exposes a function to validate client credentials (is this a real user?) and another one doing the same validation and returning which user it corresponds to (is this a real user, and which one is it?).
- An api package defining the endpoints, their behavior and parsing and processing the information received in the requests.
One advantage of this architecture is the flexibility with which it can be split in different services, the authentication, mongo and sqlbase packages can be seen as back-ends for the api package which receives direct client requests.
Another point is not to have to worry (too much) about dependencies (out of the standard library). We have very few of them, and each is contained in a single package.
Perspective for the following weeks
We started building the back-end to offer features to our clients that we could not with simple Back-end-As-A-Service but soon realized it offered huge advantages, including quicker deployment and iterations than when depending on updates of mobile applications.
As we saw the advantage of Go for collaboration within the team, we also realized it can be the language of choice on different platforms. The servers are the obvious choice, but why not the mobile with the new integration possibilities, and even on the firmware with some adjustments. This would mean Go would become the single language to handle models, logic, algorithms and would then be coupled to the native technologies of the different platforms. Time will tell ;)
To keep going with this thrilling adventure and extend the experience, we’re expanding the team, take a look at our offers: jobs.equisense.com
