Building a SaaS - Ch. 1 The Beginning

That's right, I'm throwing my hat in the ring to be a SaaS competitor. It may not going anywhere as everyone and their mom are building a SaaS nowadays, but nothing ventured nothing gained. The idea for the project came from my friends about their remote work experience. It seems that a common complaint, especially when it comes to brainstorming sessions, is the fatigue that comes with hours long video conferencing sessions. So my platform will be a forum like mind-mapping tool that will center video based messages that you can add on the go or whenever a brilliant thought strikes.

The Architecture

The purpose of building this is multifold. After passing the AWS Developer Associate certification, I wanted to build something that can help solidify the skills I learned while studying for the exam, all while creating a basis for me to build a money making project.

My project will be built out with a serverless microservice architecture relying on AWS Lambda and Fargate functions for most of the business logic heavy lifting. All of the microservices will be exposed to each other and to the client via API Gateway.

The purpose for going serverless is that there is no need for real time communication between the client and the database or between any of the other users on the platform. Cold starts generally won't be an issue since since functions will be of a call and forget nature where errors can always be sent to users at a later time. Also, using AWS's Elasticache will save on data retrieval time.

The client will be a webapp with Slack and/or teams integration along with a mobile application. The web application will be built with the most glorious library of all, and the one that can not be beat /s React. I will attempt to use Gatsby with Apollo for dynamically generated content on a static site for faster load times.

The Microservices

Having never really been exposed to microservice architecture before, I decided to read this section of Microsoft Azure's documentation. It is as paired down of a version of how to implement microservices as you can get. However, Domain Driven Design by Eric Evans is still on my reading list. I also managed to find a shorter pdf of all the concepts here.

Given the size of my app, I could have gone with a monolithic architecture. However, I went with microservices for both practice sake and ease of development. In order to determine the domains, I imagined how a small company working on this app might structure their departments to run this platform. From their, I determined that there were 4 domains in which each could potentially have it's own team to service it. The four domains are:

• User Accounts

• Topics List

• The Topic Itself

• Video Recording

Originally, I had thought that video recording could be wrapped up into the topic, but it made sense to have it as a separate domain as the to not hinder its potential growth in function. As of right now, the idea will be to make a microservice for each domain until the aggregates in each of the domains warrants it's own.

I will keep you updated on the progress.

Thanks for reading!