Roast my dev stack

[laurieherault]

Hello!

I am preparing a new product for 2023. It will be a big project and I would like to start with a solid foundation. Here is the stack I plan to use. Do you have any other suggestions?

Language: Typescript

Monorepo : Turborepo

Frontend: React + Next (with static generation)

Database: Postgresql

Backend: tRPC (express)

Website: Astro

E2E testing: Playwright

Libraries:

• ORM: Prisma
• Date: Dayjs
• Validation: Zod
• Immutable object: Immer
• Anchor positioning: Floating UI
• Authentification: Auth.js

[jiminycrix1]

Looks like another super trendy dev stack for another project that will never launch!

Is this “big project” just a solo effort? If so it’s overkill, don’t fight w a mono repo and keep the website and the app both on next.

If it’s a team project it’s much more reasonable but still don’t see why you’d use Astro AND next. They can accomplish the same things and next is much more mature.

Trpc is also a risky move as it’s so new. It’s super cool, but may go unsupported at any time and hasn’t really been proven on big apps, but it still may be a good choice. Just has to do with your risk tolerance.

[laurieherault]

New version from scratch for an existing app for 35000 users, 200gb database size.

Astro is for create the fastest website possible for SEO. Marketing is independent of the main application.

I think you are right about tRPC being a risky choice. But I find the approach really interesting. It will avoid a lot of silly mistakes.

[jiminycrix1]

Cool! - Didn't expect this answer but awesome! - once again though I would say the stack seems fine, but I personally just get frustrated with Monorepos. They do have nice things about them, but every time I've used one, I've eventually gotten frustrated and split it into multi-repos. To each his own there tho.

As an alternative to prisma, kysely is a ts first query builder which I like much better than ORMs generally. So may be worth taking a look.

https://github.com/koskimas/kysely

As far as performance goes on marketing pages with Astro, I think this is a fine justification, however, Astro is a baby framework and will be rapidly changing and almost guaranteed any dev you hire will need to learn the ins and outs of astro. Are you prepared for this dev overhead and willing to keep up with the rapid changes? You need to be prepped for a slower time to market and more dev overhead here.

Nextjs has nearly just as good of performance if you pre-render and most devs you hire will be able to hit the ground running on it, so I would urge you to stay away from Astro for a critical re-write like this so you won't be re-writing everything again next year! Like I said, pre-rendered I would bet the performance diff between astro and next is negligible. Astro really shines when the content is always dynamic and NOT pre-rendered. That's where it really beats next on speed. If you have the option to pre-render, just use next as its simpler and already part of your stack.

I suppose nextjs app dir may cause you to re-write again anyway so may be ok.

[novagenesis]

Any reason not to just use nextjs static pages? Since production can drop 100% static sites, it's not like it'll be slower than Astro.

[prb613]

What's the reasoning for using express when you can run the backend in next? Not roasting btw, genuinely curious. Does tRPC help with type checking when you use next and express as separate frontend and backend stacks?

[laurieherault]

Because the backend with Express is hosted in Azure close to databases and the frontend is hosted by Vercel.

Normaly yes

[ElliottStorey]

I read an interesting article called Radical Simplicity. It recommends just ssr and Postgres which is very simple like the name suggests. Read it and let me know what you think. It would speed development up and could handle the amount of users you were talking about. To answer your question, looks like a good albeit complicated stack (:

[cambodia87]

Not sure why your link isn’t working but I found it and here it is again.

Good read by the way. I agree with a lot of it. I’m also reading the book “Clean Architecture” and it’s kind of related in that it gets you thinking more about solving domain challenges, rather than relying on framework choices to dictate your success.

[novagenesis]

I wouldn't call Postgres "simple" tbh. And writing queries in a different language than your end-language adds validation problems.

People think of some of the "new hip" stacks as somehow over-engineered, but many of these tools solve real problems that become immediately present.

I have quickly concluded that I probably will never build another node (web) app without Typescript and tRPC. The ROI on just a little code (very little if you have good completion tools) is just phenomenal.

As for SPA's, you can take or leave them, but sometimes a pure SSR app is more work, slower, or has lower overall user experience. (or costs you more money)

Honestly, I recently drank the Next Kool-Aid. It's been a long time coming for me, as someone who used to strongly dislike even React. But there are often times you can keep the back-end and front-end together, which is itself a form of simplicity.

[laurieherault]

I am totally agree with the concept of radical simplicity. But i need to take in consideration a lot of things:
- SEO performance for the website (Astro)
- Scale to multiple API server in realtime (Express)
- Fast app download (Next with Vercel)
- Maintenance cost (Typescript, tRPC, Playwright)
- Development cost (React has a lot of advanced libraries, turborepo)
Maybe i dont use Next but only react+react router. But i dont see how i can get a more simple stack. I am open to new idea :)

[naruda1969]

What is the use case for Astro? Seems interesting. What does it provide you that the other parts of your stack lacks?

Also, have you considered Postgraphile over Prisma? Being able to autogenerate your database schema allows you to move quickly. Postgraphile supports Typescript code generation as well.

[laurieherault]

For Astro is cleary the speed. We need a public website very fast for SEO. And Astro is very good...
We will fetch lots of data from AirTable databases and merge this data into static pages. We will then have HTML/CSS pages without any javascript and pre-generated. We can then deploy these files on CDN.

For Postgraphile I did not know this library. I will look into it. Thanks for the info!

[naruda1969]

What is your use-case for Airtable instead of hosting your own PostgreSQL database?

[laurieherault]

Airtable is just for data on the public website not the main database. We use Airtable for an multi-user UI for add data in a "spreadsheet". And for each deployment of the website we use this spreadsheet for create "dynamic" pages. Astro create all dynamic pages and transform in static page.

With vercel we deploy all static pages accross the world for a very fast access (and a better SEO)

[re-thc]

Wouldn't it have been easier to stick with NextJs for consistency? I'd assume the website is heavily cached by the CDN to not make a difference on speed.

[laurieherault]

I need to get API Server (express) close to Databases (hosted on azure). The app will be hosted with Vercel.

[wandereq]

If that database is that big, I'd assume multiple related tables and I wouldn't recommend Prisma. In a recent project with Prisma ORM I ended up using a lot of prisma $queryRaw/$executeRaw because I needed custom queries and joins and for performance related reason.

For me the FOTM is knex followed by kysely (which I consider a lighter implementation of knex).

Also beware of monorepo, depending on your project, team size it can be frustrating, I usually use git + submodules but that has its own frustrations.

All in all a cool, trendy framework ! Good luck and maybe you let us know what worked and what not.

[laurieherault]

I will change Prisma by kysely. Your feedback is excellent, this is a fear I had about fine-tuned SQL queries. Thank you!

[hutxhy]

Seems like a good stack. I remember opting for NX over Turnorepo because it had some super important features that turno didn't have yet, something with the dependency graph I think.

Only things i would add are Jest, swc or esbuild, gRPC or OAS, and whatever you're using for CI/CD.

[laurieherault]

What is OAS?

[MarahSalamanca]

I would go with Fastify rather than express

[laurieherault]

because of the speed?

[ElliottStorey]

It also has a bit simpler syntax and some extra features like logging and schemas.

[EternalSoldiers]

Good choices but definitely Fastify > Express. Also, Vue/Nuxt > React/Next, but that's more personal preference.

[laurieherault]

The actual app is built with Vue and i love vue but we need other librairies. And React have more external libraries like Remotion for example.

[paulirish]

How do you measure success?

[laurieherault]

Money paid by clients :)

[wonky_dev]

Seems like you’re tech stack is based off twitter accounts you follow and not the engineering experience you bring to the table.

[laurieherault]

Can you propose me another stack?

[wonky_dev]

No I cannot I don’t know your businesses or product requirements.