Cover photo

#4 - Architecting a Backend Stack

DailyThots: Writing my daily thoughts as I build a startup tool that rethinks how people work together from the ground up.

So I figure today I'd talk about how I'm approaching the backend of my MVP (minimum viable product). For context the most impressive thing I've built before this was a magic 8 ball app for an online python tutorial that ran on local host.

But I've done a graphql course recently and so how hard can it be. The plan is simple. Work backwards from the data. So I don't know what the front end will look like, but that's ok. I mean I've made some mockups, but that's not important. I figure if I know this is the data, I'll figure out the tables for the database (I've also done a course on Relational Databases in uni so that's also useful.)

I figure relational database is good because I want the consistency and I have a good idea of how the data should be structured and I don't need the scale of no-sql.

So the idea is: these are my tables. People will enter data into the app, I'll do some calculations and store the data and the results of the calculations in the database then send the stored data back to the app. Actually it makes sense to do the calculations on the app and only send it to the database when they hit save. Otherwise it would take too long. If you click save, you're used to waiting so that's ok.

I also realize I have no idea what it actually means to make a web app. I know pieces. There is a front end. There is a database. There is a server. There are containers and that's so there is a unified hardware your application can run. But also your application isn't stored on the database, that's the data. Also the website itself, the front end has to be stored somewhere.

Lucky for me I came across this picture and a related blog post which made it more clear what it means to actually launch a web app:

That's how this person did it anyway. Also there is serverless architecture which is different than containers and also seems more intuitive to me. All I care about, at least for my application is that you run the relevant functions. Let's be honest though I have no idea what I'm talking about.

So long story short, I'm using Hasura which is connected to Neon which manages a Postgres database. I barely understand that last sentence myself. Postgres is a database management system, Neon is the database itself and they use serverless architecture and Hasura makes it easy to generate graphql scheme for your front end. I'm hoping as I learn to put these technologies into practice I'll understand it beyond an esoteric level which is where I currently am.

I chose Neon because Replit is using them so I know they won't go out of business for a while. Also they made it easy to connect to Hasura so I took that as a sign from the universe. Also their docs seemed fairly intuitive. I chose Hasura because it came up while I was looking for Prisma alternatives. Don't ask me why I'm looking for Prisma alternatives. I have no idea what I'm doing, it just feels right. Also if you're thinking I'm overcomplicating it and I should just use a simple RESTful API then you're right but this feels right and let's see where it goes.

I still need to figure out how to do user authentication (prob 0Auth) and what sessions are and how they work.

Why am I doing it like this? Why not just hack together something, it's an MVP after all. I can just use excel docs. I know this is the classic founder mistake of not focusing on speed. Of building too much and not prioritizing validating the idea. But for what I'm building this will pay off. Which is what every founder says. I feel like Tobias in this clip:

End of Daily Thot #3

More Daily Thots?