An attempt to formalize JS development patterns
Node’s permissiveness to reuse libraries, logic, and types across front-end and back-end applications gave rise to the “full-stack developer” archetype: an engineer skilled enough to work on any part of the application it needs. The emphasis on freedom and flexibility, without imposing strict coding standards or application structures, made it clear that each Node application seems to follow a different approach.
Based on his experience in building various applications, he defined a series of principles for an improved experience when writing node applications.
InfoQ contacted him to learn more about these principles.
InfoQ: Hello, Alex. Thank you for taking the time to answer our readers’ questions. Can you describe your responsibilities and what motivated you to write the knot tao?
Kondov: I’m currently a lead engineer at News UK, leading two of our teams of enablers who are building libraries, development tools and infrastructure for the rest of the engineers. My day-to-day responsibilities aren’t that different from any other developer, but I read and review more code than I write.
The goal behind Tao of Node was to formalize some of the common patterns I’ve used successfully in my career and save time for engineers just starting out. The Node ecosystem values freedom and choice, but sometimes it helps to have a set of starting principles. Making good moves puts you in good positions, much like chess.
InfoQ: Good read, but long. Top 5 takeaways for the reader? Do you intend to make them enforceable through linters?
Kondov: First off, I think application structure is critical, so I would advise people to always organize their Node services around domain components and entities rather than technical responsibilities.
Second, collocate related functionality and create nested modules.
Third, build layers between transport, domain, and data access logic.
Fourth, for performance, make sure you don’t jam the event loop with heavy operations and you’ll solve most of your speed worries.
Finally, don’t worry about database changes when it comes to abstractions – if you ever need to change the storage of an application in production, the data in it should be your biggest concern.
Although I was considering creating a ESlint plugin, in the end I preferred to keep them as guidelines. This way I don’t limit people’s creativity, because many rules are context dependent.
InfoQ: How would you recommend putting theory into practice? How to implement it on existing projects?
Kondov: Room by room. Start by improving the structure, it involves the least amount of refactoring. The reorganization of the code base mainly requires import path changes. With a better structure, you can tackle each module at a time, separating the layers and dividing the logic. Like a messy shelf, everything has to come out before you can rearrange it.
A possible side effect of the refactoring could be the decrease in code quality. Once the mess is cleared up, you’ll have a more organized and productive app to work with.
InfoQ: What would be your biggest concern when looking at the JS ecosystem? What would you need?
Kondov: Node.js is a powerful tool that I would use for any application that does not require heavy calculations or manipulation of large data structures. It particularly shines when it comes to high-volume I/O, but it can easily falter if used for a problem it can’t fix. Its community is pretty resourceful, but it definitely needs some standardization, especially for tooling.
Tao of Node is my attempt to formalize some of the development patterns, but the JS community, in general, can benefit from a single tool that manages the toolchain – Manuscriptessays, linters, etc.
In the meantime, the once browser language only gained popularity and was awarded the silver medal by The Serverless State of DataDog report, while GitHub’s language stats lists it as one of the main languages used in the first quarter of 2022.
Comments are closed.