App Build Update: Infrastructure
It’s been a while since my last update on building my app - ParenTime. While my progress hasn’t quite gone according to plan (when does it ever!), life happens and priorities change. However, there has been progress! For now, though, I’ll share a bit about the infrastructure plan I’ve laid out for the app to be hosted on AWS.
Leaning into AWS
I’ve opted to use AWS native services throughout the application’s stack, which does tie me into AWS quite a bit. However, this is for a number of reasons:
-
Using AWS native services tends to be much cheaper - often free for my use cases. This makes sense when you consider that AWS wants to lock you in!
-
It helps broaden my AWS-specific knowledge, which is part of the goal of building this app!
This means that if I weren’t also seeking to broaden my AWS knowledge, I likely would have made different decisions when choosing and setting up the infrastructure for this app. Also, not all of this is implemented yet, so if I start to uncover issues with my choices, I will make changes as needed.
The planned infrastructure
Here’s a breakdown of the components and some of the choices made:
- Using Cognito User Pools for the application’s identity provider
- Using CloudFront as the CDN for the client app’s static resources and to proxy API requests from the UI
- Using S3 to store the static UI assets
- High use of Lambda! From the server functions of the TanStack Start app to the .NET services that perform CRUD operations on the database
- API Gateway to manage the communication between the TanStack Start app and the backend .NET services
- Finally, an RDS Postgres database for storing application data
I’ve left out networking in this update, as I think that’s a discussion on its own. If that sounds interesting, leave a comment where I post this article, and I’ll write up the usage of VPCs and related resources to (hopefully) secure this setup appropriately.
One area I’d definitely consider making changes in the future would be to make the db commands operate against a queue instead of directly updating the database, however I’d base this decision on whether there are performance or other concerns with the synchronous updates to the database.
Where to from here
The MVP features of this app are mostly ready to go, so I’m busy setting up this exact infrastructure on AWS, starting with the database and backend .NET Lambda functions. There have been some really interesting learnings there already with networking and getting AOT-compiled .NET Lambdas running smoothly, which I’ll likely share in upcoming posts - stay tuned!