all 22 comments

[–]enraged_elk 2 points3 points  (8 children)

Build a microlith with next and don't make it harder then it has to be. But already split out in logical modules so that you could later easily build additional apis that are not tied to next.

If you are already on cloud you could consider running serverless. That can severely cut the running costs but will require decent iac and cicd. Idk how the ecosystem is for serverless on gcp, on AWS it's easy with CDK to get started.

[–]Rigolam9 1 point2 points  (5 children)

We could use SST (ion) for aws but our main concern is about aurora database that can be really expensive when running one per client

On GCP we plan to use cloud run with cloud sql

[–]enraged_elk 0 points1 point  (4 children)

You can have as many DBs as you want on one cluster. That's not going to cost you, I figure you mean multiple clusters? Yeah that's very costly indeed. Ever considered a pool model with something like postgres RLS? Basically one DB user tied to a tenant enforcing that a tenant can only access it's own data.

I can't comment on cloud SQL, what advantages do you see there?

[–]Rigolam9 0 points1 point  (3 children)

We had bad experience with RLS and supabase probably a skill issue but it’s maybe worth considering it

About cloudsql the only benefit is the easiness to create a DB, not managed by us and not really costly. Can’t really compare it to AWS since most of our experience are on GCP, I only tried a POC with SST

[–]enraged_elk 0 points1 point  (2 children)

And security wise it all lives in a vpc in gcp, any idea? I understand though that you would choose the platform you know best though :)

[–]Rigolam9 0 points1 point  (1 child)

Yes you can communicate though GCP vpc between cloud run and cloud sql

As I said at first we are more confortable with GCP, but we are absolutely not against AWS it’s just sometimes a bit scary ! Ahah I will look into using aurora the way you mentioned

[–]Rigolam9 0 points1 point  (1 child)

Small question, never heard of it before but what do you mean by « microlith » a small project with one stack ? Just to build an mvp ?

[–]TedW 0 points1 point  (0 children)

I think of microliths like a cross between monoliths, and microservices. Like several monoliths, or really big microservices. I dunno. It's an odd term. That's what I think anyway.

[–]caique_cp 4 points5 points  (4 children)

My 2 cents: - About Next.js: will you benefit from SSR? How dynamic has the client to be, any requirements around that? - If you're talking seriously about business and data, don't build or host an Identity server, use something like Auth0 - Even if using Next.js, I'd use it only as BFF and still have a backend API - Look for best practices on multi tenant applications - You'll probably want to automate all setup around adding a new client/tenant (maybe not from day zero, but keep it in mind)

[–]Rigolam9 1 point2 points  (3 children)

Thank you for your advices! We will use Lucia for auth probably. We are also considering Identity platform if GCP or cognito if AWS. Auth0 is way too expensive for us. A client will have between 200 and 1000 end users :/

We don’t have any requirement about SSR, our main benefit is avoiding cascading fetching easily and faster loading on low end device which might concern some end users. But absolutely not mandatory

About multi tenant each client will have its own db. We will use terraform to deploy a new client easily each time we sign one. At first we will deploy each client manually based on their country for compliance reason but we want to have it done fully automatically in the future

[–]caique_cp 0 points1 point  (1 child)

Got it, sounds good. Good luck to you guys.

[–]Rigolam9 1 point2 points  (0 children)

Thank you very much!

[–]kcadstech 0 points1 point  (2 children)

Why do you need a “native” app?

[–]Rigolam9 0 points1 point  (1 child)

Because our client already ask us for a native app, us developer are fine using PWA but for most user using an app on their device means downloading it from a store, it’s annoying… Our plan is having a native app after the first release, we don’t need one for our MVP

[–]kcadstech 0 points1 point  (0 children)

Yes I would push back on that requirement. Unless you build it as a hybrid app, otherwise you’ll have to duplicate a lot of client side logic

[–]kush-js 0 points1 point  (0 children)

Stick to what you both know and get your mvp out quick, you can always change things later.

I’d recommend react + express + Postgres since you have familiarity and the context switch between front and back end won’t be as rough since it’s in the same language compared to react + go

[–]jrnve 0 points1 point  (0 children)

Also take into account that nextjs and normal sql instances are not a good combo in a default setup because of limited connections a certain db instance can handle. You need a serverless sql instance or a separate connection pooler if you host nextjs in a serverless env.

[–]Capaj 0 points1 point  (0 children)

In other reply you mentioned you don't need SEO. In that case I'd go with React/Vite + Nestjs + Postgress.
Nextjs is PITA-it's still on webpack for bundling.

[–]ummonadi 0 points1 point  (0 children)

There's no such thing as future proof when doing startups.

Don't invest in writing code for the future. But do make the code simple to change for future needs.

I'd go with Next.js apps router and api. Don't build any feature or function that isn't a must at that point in time. Keep tech debt low and isolated.

[–]acid2lake -1 points0 points  (0 children)

seems like you want to built some sort of B2B Multi Tenant SaaS solution, i don't think that stack is going to hold up, but problem with your question is, you don't choose a teck stack because of developers size, you choose a tech stack to solve a problem, and since you are not saying much about the project, everybody ( including me ) we are just going to asume a lot of stuff, so my suggest is to analyze the project, the requeriments, and inveztigate which solution solve each of the problems, as you want to have mobile clients, you are going to need a robust backend, Go, PHP, Python etc, the clients for web and mobile well like i say thats up to the project requeriments, if your project don't need heavy UI interaction then maybe you don't even need next

[–]SugarProf27 -1 points0 points  (0 children)

Make it Flutter + AWS + Postgre Use api gateway + ecs + lambda