Most people overthink their backend way too early. You start building a new product and suddenly you’re researching Kafka, Redis, background worker...
For further actions, you may consider blocking this person and/or reporting abuse
no serverless? how do you expect this to scale???
Now you are just trolling :)
he's a friend, trolling is required by law :D
Neat, less mess means more time for building fun stuff instead of fixing problems all day, but it's pretty good. But does keeping things simple always work when your app grows and gets bigger challenges?
I'd say so! Mostly because you can continue to vertically scale for a very very long time and that gives you time to start planning.
I can't agree more with you. Many modern patterns are overkill for most projects and produce unnecessary complexity (and opportunities for things to break).
As I get older I appreciate simple over "clever". You can write a monolith in a way that can be decomposed in the future, if needed. But cross that bridge when you come to it.
are you just using express and typescript or something else ?
I'm using Fastify with typescript. I know you didn't ask me. But there you have it.
I'm still interested in the answer of Shayan.
Yes still using express and trpc
I was procrastinating on a personal project because of this. I've only focused on frontend development for the past years, and I was struggling with choosing the stack. By reading this post, you motivate me to stop overthinking about setting up all the perfect tools and just start. Great post!
Could you clarify what you mean by
LISTEN/NOTIFY? Is that a feature in postgres?LISTEN & NOTIFY events are supported in Postgres: postgresql.org/docs/16/sql-listen.... - They're postgresql's pub/sub system. It can do everything from respond to record changes (say a job state change, or a declined credit card transaction), INSERT notifications, sending messages between DB clients, etc.
But there are some important considerations:
I use node's pg_listen module running on a dedicated docker container with a single non-pooled connection, and then something like NATS or gRPC to broker messages as needed.
Bonus reading: look into the pg_cron postgres extension for scheduling jobs in postgres directly:
Combined with LISTEN/NOTIFY, it's super powerful.
Thanks for all the valuable insights!
Well we are using kotlin with PostgreSQL, and on jvm at least we had to use a non maintained PostgreSQL specific connector without pooling to use listen notify. It was a few year's ago but are there better connectors now a days? Also listen notify has an 8k transfer limit afaik?
Having said that I like PostgreSQL a lot and always say, let's prove that our system is actually reaching the limits before adding more complexity using maybe load tests so I agree with the essence of the article.
I'm a strong believer in the NAP stack - NestJS, Angular, and PostgreSQL. Still only TS and pSQL and a bit more boilerplate than your lean setup but it scales very easily and having both front and back end follow similar architecture patterns is huge when bringing new coders in.
This is spot on. I've seen too many teams overcomplicate their architecture way before they have product-market fit. TypeScript + Postgres is a killer combo—fast to build, easy to maintain, and flexible enough for 95% of use cases. Love the reminder that users > infrastructure debates. Build the thing first, then worry about scale.
Great article. I love "You’re Not Google. Scaling Isn’t Your Problem (Yet)". You are absolutely right my friend.
Give yourselves some space to breath dear devs.
Thank you :)
100% on point. Less is very, very often more.
F* great article!
Most startups and scale ups should just follow what you are suggesting
Thank you , very nice Artical
I'm also using typescript with Fastify framework and MariaDB (mysql)...
I was thinking about refactoring everything to Golang. But you might be right.. Its easier to on board new contributors, since the frontend is also Typescript with Angular.
What do you think about using MariaDB vs Postgresql?
@shayy so is MariaDB also approved 😊?
I usually only jump between the following now depending on my requirements but it follows a very similar pattern of Typescript, and in my case, MySQL.
MySQL for me because I'm the most familiar with it, I have more experience with it, and I've been using it since about 2003
Totally agreed 👍
When it comes to Postgres (or any other database), I usually prefer to use it simply for storing and retrieving data, keeping all of the business logic, etc on the Node.js side.
Hence I'm curious - what kind of advantages does LISTEN/NOTIFY have over handling events entirely within Node.js?
Especially if you have only one Node.js instance.
i think keeping things this simple sounds great tbh - i've def wasted way too much time overbuilding for stuff that didn't need it
Full ack. Especially the part about postgres: most people don't know how powerful a postgres is. LISTEN/NOTIFIY alone is very unknown, although you can do so many things with it.
Also added your article to the next issue of the weeklyfoo.
Next: let's talk hardware (different needs/setups for different applications for example: Fintech app, messaging and chat app, social media app, e-commerce app etc...)
good luck scaling this -- just saying typescript is good for demoing but can quickly destroy your stack...
But that’s the point: when you need to scale, then is the time to get complicated.