After a successful launch of my latest SaaS Product, FeedHive, I've been asked this question countless times.
What is the Tech Stack of FeedHive, and what were the main considerations for the architecture.
Well, there are - of course - many great solutions.
But let me just break down the Tech Stack and architecture that I chose for this SaaS Product.
FeedHive runs Cloud Native on a fully Serverless Architecture.
When you're bootstrapping a SaaS business, this is an extremely attractive solution, given the pay-per-use pricing model that is associated with Serverless.
This solution is not only saving you time and overhead - it also automatically scales as users come in and demand goes up.
But most importantly - it's also super cheap.
On Amazon Web Services, I pay 0.08$ pr. user, pr. month, on average.
That means, that with the current pricing model of FeedHive, if just 1 out of 62 users is on the paid plan - they will cover the server cost entirely.
All data is stored in DynamoDB.
It's fully managed by AWS, so you don't need a server running to host the database.
This enables extremely high flexibility when it comes to up- and down-scaling your solution.
GraphQL is a query language and an alternative to SQL and MySQL.
With GraphQL we can specify exactly what we need and the relation between the data coming from the backend, all in a single request.
AWS has a solution called AppSync which enables you to create a managed GraphqQL layer to securely access, write, and combine data from one or more data sources.
You can link a DynamoDB table as a data source directly, without having to write custom resolver logic.
AppSync is again fully managed, so you don't need a server running your GraphQL API.
The entire backend of FeedHive is written in TypeScript, executed in a Node.js environment running on individual Lambda Functions that live in the cloud.
Even though you can link a DynamoDB table as a data source directly using AppSync, you typically need a bit more custom resolver-logic.
Fortunately, you can use Lambda as a data source for AppSync as well.
And once again: The environment that the lambdas are executed in is entirely managed by Amazon Web Services.
The pricing can be a little difficult to figure out a first, since both the duration and memory consumption of a lambda is factored into the price, but essentially, you pay $0.00-00-1667 for every GB-second, and $0.20 pr. one million requests.
Finally, Amazon Web Services has a great solution to handle authentication of your users called Cognito.
With FeedHive, you log in using Twitter, which is a third-party social Identity provider.
Amazon Web Services call this Federation.
After authenticating with a social Identity provider, Cognito will securely map the authenticated user to the roles that are allowed to access the resources on AWS that the user needs to access and use the app.
Optionally, you can create a User Pool, which is a managed user directory, containing all the relevant information about a user.
In this way, you don't have to worry about maintaining a user table in a database yourself.
And here's where it gets really incredible.
AWS runs a library called Amplify, which you can install on your front end and will help you tremendously with user authentication on the client-side.
The Front End of FeedHive is written in React.
It's especially powerful for writing Single Page Applications, or so-called SPAs.
React has amazing TypeScript support as well.
In fact, the entire Front End of FeedHive is written in TypeScript.
For the state management of the application, FeedHive uses Recoil, which is an upcoming atom-based state management library.
It's still in beta, but it is an absolutely awesome alternative to the tedious, "boilerplaty" solutions we currently have out there.
The SPA itself is hosted on S3 and distributed with CloudFront.
As mentioned before, Amplify enables us to integrate a lot of the things we have covered so far.
Most importantly, it makes it really easy to manage authentication using Cognito.
FeedHive authenticates using Twitter as a social identity provider, but the options when combining Amplify and Cognito are more or less limitless.
You can use any Social Identity Provider like Facebook, Google, GitHub and Twitter, but you can also use enterprise identity providers like SAML or OpenID Connect.
You can even use Amazon Web Services' own hosted authentication endpoint for absolute ease.
I am a huge fan of Test Driven Development, and I use this approach whenever the situation allows me to.
Both the front end and back end of FeedHive contain unit tests written and run by Jest.
Additionally, I'm a huge fan of Cypress, which I use rigorously for both integration tests and full end-to-end testing.
As a part of the deployment pipeline, GitHub Actions will spin up in a hosted test environment which Cypress will use to run end-to-end tests against.
So, finally, I want to mention the deployment setup.
FeedHive uses the Serverless Framework.
This allows us to use infrastructure-as-code for the entire cloud infrastructure.
We can set up both DynamoDB, AppSync, GraphQL Schema, and all our Lambdas in a single yml-file.
It's an incredible tool!
Let's do a quick summary.
The biggest takeaway from the tech stack that I have chosen for FeedHive, is that it's serverless!
If you want more details, you can read the full article here:
I hope you got something out of this write-up.
Feel free to ask any questions in the comments, and I'll answer the best I can!
Good luck with architecting your next SaaS Product 🚀