I recently released the pilot version for a new app idea that I've been working on called Seudo, a cloud-based pseudonymization engine that lets customers build data workflows to transform their customers data into a format that is safe to share.
As an engineer and developer, I start with the tech stack. I know its not the best way of going about things, but I love building things and I love solving problems, and if the technical problems of a project don't intrigue me, I usually don't get very far. Given that this was the first project of (hopefully) many projects that I wanted to do under one umbrella, I wanted to set up my infrastructure and environments in such a way that I could reuse all components on projects down the road. Everything that I'm going to discuss in this post you can see a working version of at https://seudo.alpn-software.com.
Oh, and it needed to be cheap. Ideally, I wanted it to be free. And thats (more or less) what I accomplished, minus a few up front costs. The setup I'm going to walk through is designed to cost very little while you scale up your business. Most of it runs on AWS serverless, so you only really start incurring cost when you get a lot of traffic. Developing, deploying and releasing my MVP cost me a grand total of £15, and £13 of that was the domain. The running costs are next to nothing. In fact, it hasn't cost me anything since its release. The cost breakdown of the first few month is
Domain (purchased via AWS Route 53) - £13
DynamoDB costs - £1
Heres a high level overview of the tech stack
First and foremost, you need to choose a cloud provider. AWS is my go-to, but GCP or Azure have most of the same functionality just under a different name. Management of source code is the next critical component. Gitlab and GitHub both work well. I personally prefer Gitlab because you can create Groups and Subgroups to manage your projects. My big criticism of GitHub is that my projects usually have in the 10s of repos, and organising that in GitHub is not clean.
Next, all my infrastructure is always managed via Terraform, without fail. This doesn't just apply to the apps. It applies to all AWS users that have access to environments, all IAM roles that grant permissions, all S3 buckets that store data etc. The only AWS resource that I typically create manually is an S3 bucket for storing Terraform state, and an IAM role that Terraform CICD users can assume to create resources. Everything else (and I mean everything else) is in Terraform. I always use S3 to store the TF state (unless I'm using Terraform Cloud), and a DynamoDB table to manage state locks.
One of the nice things about Terraform is that you can store TF modules in a Git repository and then reference them remotely somewhere else. This lets you write re-usable Terraform modules that you can store in your existing Git setup, which really makes your Terraform setups clean and compact.
Python is my go to when building APIs. While it's not the most performant language, its by far the quickest to build and iterate on. Later down the road when performance becomes and issue, I might refactor some components in Golang to get a boost, but that's not common for me. I always design my APIs in a micro-service architecture. One of the biggest advantages early on is separation of concerns. When I'm working on an MVP, I would rather have small, repeatable components that I can develop individually as I find it significantly reduces my cycle and testing time. It's also a much more scalable approach so it really pays dividends throughout.
My go-to API framework for Python is FastAPI. Unless I really need something else (like GraphQL or gRPC), I'll go with FastAPI. All my APIs are packaged as Docker containers and deployed using AWS Lambda. In order to get FastAPI to work with AWS Lambda, I use an adapter called Mangum, which lets you run a FastAPI instance in a single AWS Lambda function. The result is one AWS Lambda function per API, which is incredibly cheap to a point where you can host projects indefinitely and stay within the AWS Free Tier.
I couple the Lambda functions with API Gateway, and this is where Mangum comes in. It essentially translates the AWS Lambda Event into an ASGI event that FastAPI can process. I have Terraform modules that I store in Gitlab for both the Lambda deployment, as well as the API Gateway. This lets me get an entire API up and running in ~ 20 lines of Terraform. Clean, easy, quick (and did I mention cheap?).
UI work is not my strong point, but I usually use Vue3 coupled with a component library like Vuetify or PrimeVue to build UIs. This is by far the most time consuming step for me, and the part I enjoy the least. But it needs to be done. When it comes to deploying, I almost always just use an S3 bucket fronted by a Cloudfront Distribution. Again, this is practically free until your requests start building significantly. No surprise, I have a re-usable Terraform module that I store in Gitlab that lets me create a FE deployment in ~ 10 lines of Terraform.
Thats it. The above is pretty standard. Nothing fancy, but it works. It's very low cost, and scales as you grow your application. Check out my latest app at https://seudo.alpn-software.com to see a live example.