We changed our tech stack! Here's why.
The Sampling Central tech team evolved their backend tech stack recently to make their lives easier and also to enable quick iterations for the product. The new backend is more robust, extensible, maintainable and most important, written on TypeScript ❤️
Read on to understand all the decisions we made regarding server, database and deployment.
Server: Firebase to NestJS
We went from a serverless technology, using Firebase, to a self maintained server using NestJS framework. We used Firebase auth and cloud functions before for any computational heavy tasks or tasks that required security, because we wanted Firebase's auto scaling feature and a short time to market.
The problem with using cloud functions was that although cloud functions make it easier to micromanage situations and needs because of their easier deployment, they add extra complexity on the overall architecture itself by virtue of not having a centrally maintained ecosystem of code like say in a NestJs codebase.
Cloud functions also suffer with the problem of cold starts.
Hypothetically we could have everything running on cloud functions (with the minimum instance limit set to reduce cold start problems) but that’s a cost tradeoff we need to address.
The things we need to consider to understand this decision are:
The costs associated with running everything (or most) things on cloud functions with a minimum instance limit set to at least 1 to “reduce” (not eliminate) cold start issues.
The hidden dev costs associated with poor concreteness of the codebase (with everything running on separate cloud functions)
We may even want to consider becoming too vendor locked in as a potential future downside.
Advantages
NestJS solved the issues by being a self managed framework to build server side applications . Other great thing about Nest is its robustness and maintainability. NestJS code has its own structure which brings all the developers on the same page and creates a harmony within the team.
Great code infrastructure
Robust framework
Consistent coding experience
Great abstraction for features like securing API endpoints, authentication, etc.
Typescript support
Easily extendable
Disadvantages
Steep learning curve
Manual scaling
Database: Firebase to PostgreSQL
Database too was the Firebase Realtime database (RTDB) and Firestore. The problems with RTDB were with scalability, our claimed samples are now close to 1-2 lakhs, and a lot of data was stored about each sample. We moved from RTDB to Firestore, but it also gave these problems:
No-SQL has issues dealing with relational data.
Performing analytics on the data itself becomes challenging as pointed out by Kavach.
Advantages
Firestore is a No-SQL database and PostgreSQL is a relational database. We made this transition because we wanted a ground up relational approach to our data.
Relational database for better analytics
Robust
Open source
Disadvantages
Not flexible like other No-SQL databases
Steep learning curve
As a bonus we also implemented Prisma as our ORM so that changing databases in the future is a breeze.
Deployments: Firebase to GKE
Our deployments were also done using the Firebase hosting service. A big disadvantage of it is that it was not possible to deploy docker containers on it. We needed containerisation for a much better developer experience and with the new backend we want to be able to deploy Docker containers. For that we use Docker and Google Kubernetes Engine (GKE).
Advantages
This was the right choice because.
Helps in managing deployment pipelines.
Provides auto-scaling capabilities on an application level.
Disadvantages
Steep learning Curve
Complex
As a bonus we implemented CI pipelines using Bitbucket for automated testing using Cypress.
About Sampling Central
Sampling Central (powered by FreeStand) is a SaaS enabled B2B marketplace for all your product sampling solutions. It helps you manage, track and analyse all your sampling campaigns at one place. To explore our product, you can contact us at anytime.
 |
|
🚀