I'm working on this web app using NextJS with server-side rendering, and I've integrated Supabase for authentication and database access. Everything's in one repository, and it seems like a straightforward setup. However, I'm a bit confused. Since it connects to Supabase, does that mean it isn't a monolith? Or could it be classified as a distributed monolith? And just how can a web app with a database be a monolith? Wouldn't the database need to be part of the app itself? I feel like I'm missing some key concepts here!
3 Answers
In my experience, I’d say it’s a monolith at its core, but not because of the Supabase connection. With NextJS, all the API calls you're making from the same repository give it that monolithic vibe. And while this classification might seem boring, it’s totally normal for small apps. Monoliths simplify things like deployment and pull requests since everything’s cohesive and doesn’t require extensive coordination.
Honestly, when I think of a monolith, I picture everything packed into one file or a couple of files, especially for small programs. I don’t see anything wrong with that as long as it's manageable. When you start packing tons of code and complexity, that’s when you might consider refactoring into a better structure. Just let your project evolve naturally until it needs that change.
That makes sense! It’s all about doing what works for the project size and complexity.
So, if you deploy all your code as a single unit, that's typically what we call a 'monolith.' The database isn't usually seen as a separate service, so it doesn't change that classification. When you have multiple services deployed independently, that's where you get into microservices territory. For small projects, breaking things into microservices isn't usually a good idea; it's better suited for larger teams tackling bigger projects.
Got it! So the connection to the database is part of that single unit, making it a monolith?
Interesting! So monoliths can be okay until you really grow in size?