NestJS and EventStoreDB as Backend stack
- Status: accepted
- Deciders: Kadaster Development Team
- Date: Apr, 2020
Context and Problem Statement
Depending on the stack of choice will follow the taste of event store.
- Speed in initial startup of the project
- Learning curve for adoption and contribution
- Long term maintainability
- Java stack with AxonServer
AxonServer integrates with the AxonFramework phenomenally. The AxonFramework will help and guide the development in a proper application of event-sourcing patterns for the developers. As event-sourcing is gaining more interest and has a growing community of developers familiar with this pattern, a framework providing guidance is a major assistance.
As Kadaster will be the Development Team of the initial system, their common stack might be of relevance. Kadaster's main stack is Java and they have experience with building and using the 'Axon stack' with Java.
On the other hand, Java will have a steeper learning curve and even more so if the code reflects event sourcing patterns to the max. This might be too much to ask?
- NodeJS, more specifically NestJS with EventStoreDB
And as already mentioned above, the actual developers of the Kadaster Development Team already had experience with NodeJS and TypeScript.
Chosen option: "NestJS with EventStoreDB", because of
- the already available experience of the developers in the Kadaster Development Team, and
- being the more lightweight stack of the two for initial setup, as well as for adoption later on by other organizations and developers.
- Within a few weeks (days really), the first initial setup of several components had been finished.
- The learning curve of the developers was mainly focused on the event-sourcing patterns and domain knowledge, rather than the technical stack itself.
- Adoption and readability for others has been easier, although this has not been huge in quantity.
- The runtime containers produced for each component have quite a small footprint, since the footprint of NodeJS/NestJS is smaller than the JVM (Java) footprint.
- NestJS allows us to build a split stack, exposing APIs on the backend. The frontend can simply query those APIs. This allows other teams to build their own frontend, or possibly integrate other (already existing) systems with the SensRNet backend.
- The event-sourcing pattern is not implemented in NestJS and even the EventStoreDB gives room for different usage. Therefore the developer were not guided as much as the AxonFramework would have done during development.
- Kadaster knowledge on how to apply event sourcing could not really be of use because of the different stack. While this might have been a drawback early on, this knowledge about event sourcing now has been instilled in the SensRNet team.