On starting a Node.js Guild
In 2020, we established the Node.js Guild within Mobimeo to have a space for all engineers working with Node.js to discuss, align and co-operate with one another. This is the first post of a series of blog posts that will explore how we work with Node.js in our internal services and ideas for evolving our stacks!
But why? 🤔
Our internal services date all the way back to the year of 2015 (before moovel and Mobimeo joined forces in 2020), and that’s about 6 years by now. Practices, frameworks and libraries have evolved since then, and we began feeling like we were at a stalemate when it came to the evolution of those very same services: they were written once and just evolved upon, but not as frequently as we’d like. Additionally, given the nature of our microservice architecture and the multitude of teams, a lot of opinions on best practices were not aligned thus creating a bigger gap between them in terms of conventions, libraries and frameworks to use on our services.
Some years passed, and engineers started realising some of these services’ technical foundations became stale, thus creating an even bigger gap to the technologies that were rapidly appearing in the Node.js community. And this is when we got together, and decided to create a space for us to speak and align on all of these topics!
Behold, the Guild! 🙌
But how did we get together? There is an internal utility library at Mobimeo called node-toolbox — More about that in the next blog post! 😏 Some of the libraries used in that toolbox were deprecated, so some initiative was taken to replace it. Since it incurred an API breaking change, there was no way one person would be able to do it by themselves, so back in 2020, we gathered in a group of four (from different teams) and decided to take matters into our own hands.
A couple of months had then passed: Our alignment efforts paid off and we just didn’t want to stop there. Since we were all maintaining the very same library that constitutes the core of our services, which includes tools for HTTP clients, logging and others, we had the idea of creating a bi-weekly space for all other Engineers to join in and also participate in the iteration process. We decided to call it the Node.js Guild! Cheesy name, but it served the purpose — What’s a Guild anyway if not for a group of specialists to gather and nerd around a little bit?
So… How?
We wanted to start small and make sure we didn’t derail from the company’s main objective: Help our users move smarter within the cities we provide services in. So we set a couple of ground rules:
- Time — A one-hour meeting every two weeks on Wednesdays
- Place — Unfortunately with COVID-19 around, we stick to video conferencing
- Who — Anyone was free to join and participate, regardless of what their professional expertise is. Ideally, also one Node.js Engineer per team
- What — Every participant can bring in a topic of their choosing into the agenda, written and maintained in a collaborative document
- How — We timebox our topics and are friendly with one another! Consensus and agreement are our baseline for working together
Lessons? Definitely!
As time passed, we managed to go through a variety of topics, create alignment and come up with conventions together. All of this helped us iterate on our current stacks, service templates and internal libraries. But we didn’t want to stop there!
We quickly realised that time to work on these topics was rather scarce during the day aside from this little hour we had every two weeks. The Node.js Chapter then rose in its place, where we officially gained some more time to work on these topics by introducing an entire working day every two weeks to muster focus. More about that in a future blog post as well!
What next?
That’s it for today! In the next blog posts, we’ll talk about some of our internal libraries and templates, as well as even more lessons learned from the newly created Node.js Chapter. Stay tuned for more coming your way soon!
