If you were to start a new web project with Node.js today, how would you pick your stack? I'm looking for suggestions spanning both backend and front-end. Thanks!
For further actions, you may consider blocking this person and/or reporting abuse
Read next
JavaScript Memory Management and Optimization Techniques for Large-Scale Applications
Harish Kumar -
My First JavaScript Web App: Interactive Image Coordinate Finder
Ryan VerWey -
Unit, Integration, and E2E Testing in One Example Using Jest
Mohamed Mayallo -
Learn useActionState quickly with an example (Next.js 15)
Alex Booker -
Top comments (39)
I've got a handful of node apps with the following stack:
Thanks! I thought it was a typo but there are really Next.js, Nuxt.js and Nest.js 😅
😋
I've been writing full stack using nodejs for about 6 years now. Tried a humongous number of backend and Frontend frameworks. Nearly all them.
My current stack of choice is exactly the same. Yes, including the Nginx approach.
If I can't use MongoDB, then the backend framework would be either Hapi or Nest.
what d'u think about v4.loopback.io/ ?
its just like Nest, but sponsored by IBM and developed by StrongLoop (which is now one of IBM companies)
personaly i found that loopback v4, lets say... more academically rigorous but has a bit poor documentation than Nest.
i'd be really interesting to see what the man with 6 years of full stack in background thinks about this serious framework.
Thanks for the question.
I'd have to back off expressing any opinions about lb4. I haven't played with versions 2 or 3 either.
Meanwhile, I believe in GraphQL (as a concept). And don't believe in a bright future of the http servers (yes, even Hapi and Nest). In the future we'd need 1 endpoint (REST is going to vanish step by step) for application data.
Sorry for not answering your question and bringing own gibberish to the discussion.
That's actually quite fascinating to me! I also tried just about every framework as well before landing on this stack. Used to write my backend in express and mongoose, but I really like the way Strapi bootstraps and organizes things. I find it helps me keep things a little more organized, and I find the GUI quite helpful during development and debugging.
Vuetify and Vue is also my tools of choice! Not sure about Nuxt and Strapi, will look into it further
That sounds interesting. Can you explain in more detail why you use Strapi for the backend? Do you really want to have a GUI for managing records in the backend or what is the reason?
For me, the GUI is a secondary reason for using Strapi.
My primary reason for using it is this: it imposes a little bit of structure and opinion on your node app. Just enough so that your project isn't a mess and you know where to look for things, but not so much that it restricts what you can do with it. Basically, it bootstraps Koa and Mongoose (and some other tools) in a really nice way, and gives you a nice way to configure/use them. After building Express apps, it was refreshing to have some structure and eliminate some of the tedium of setting up projects.
Although I'm not using the GUI for adding content, I have found it very useful during development (inspecting data and relationships), and can help in tracking down issues in production. With Strapi's GUI, if pieces of data are related, you can easily jump between them - as far as I know, this isn't something that can be done in a MongoDB client (like Robo3T).
If you've ever built an app with Express and Mongoose, I recommend at least trying Strapi. I was skeptical about the "headless CMS" nature of Strapi at first, but that's just "icing on the cake" for me now. Don't think of it as something like WordPress - think of it as a structured Node app with a convenient GUI placed on top.
Thank you very much for the detailed explanation. I will definitely take a closer look at Strapi.
All-in with TypeScript, on both ends: back with NestJS and front with Angular.
How do you organize the serverless functions and frontend code in Git?
A single repository with
nestjsandangularfolders, asharedfolder with interfaces and other overlapping classes and from there the organization of new files and scripts would be made on a case-by-case basis (i.e. what's cross-cutting or application-specific.)I'd organize serverless function code in the
nestjsfolder as they'd all likely just wrap the application in a cloud specific way (an AWS wrapper, an Azure wrapper, etc.) and have their respective build/deploy scripts there, too.Awesome, thank you for sharing!
Do you have a starter repos I can reference to get this going, this is exactly what I am working on?
While not exactly, I have a monorepo (github.com/METACEO/monorepo-example) that shows a structure that I use to achieve the above.
Depending on my cloud provider, I'll write top-level scripts to help with development, deployment, etc. (all of which I hope gets much easier with Bazel.)
Tailoring this monorepo to something cloud-specific probably deserves it's own write-up beyond a comment.
Lerna monorepo. React, Redux, Amplify and entire AWS: GatewayAPI and Lamda + DynamoDB if NoSQL or Aurora if relational, Cognito for Authentication, Cloudfront for CDN , S3 for storage of webapp and other stuff, Cloudwatch for logging and metrics.
AVA for testing and XO for formatting.
eventually Typescript.
all infrastructure defined and deployed with Serverless Framework
Honestly for me it comes down to requirements really.
I personally don't mind using something like sails.js which follows an MVC framework pattern but heavily opinionated.
I've worked with clients on pure static with elements of a headless CMS and also pure markdown content. Usually something as simple as static html and native js calls pushed up to netlify. Search using Algolia and if I need cms contentful and others are nice.
There's a million options, it's not a bad thing. I would say you don't have to just jump into a world of react or vue either. There's always a heavy bias to web development trends but as someone who works in architecture I often have to think about the third party services, authentication/authorisation factors, client incumbent systems, non functional requirements.. the list goes on.
Lately for full stack, I see no issue with still using MVC frameworks but honestly don't worry too much whatever road you go down.
I work with typescript.
At back-end I use nest.js which is based on express and written in typescript. It is an MVC framework.
At front-end I use Angular
I did just this a few months ago:
Primary database: Postgres, unless there's a pressing reason to use something else
Data access layer: assuming Postgres, Massive (my own project)
Web framework: koa; Express may be more popular in this category but koa supports async route functions
Templating: koa-views with pug
Frontend JS: jQuery, if that
Styling: CSS preprocessors seem pretty interchangeable, I haven't had a reason to use anything other than LESS
Build: npm scripts
Routes are organized so that state changes always happen through a dedicated API route instead of POSTing to a route that redirects or renders. This ensures other frontends can still use the system (assuming they authenticate), and means it's pretty easy to drop a more complex single-page frontend solution in should the need arise.
TypeScript might be nice if you have a sufficiently large team but for the most part I think of JavaScript's lack of static guardrails a feature, not a bug.
Very insightful, thank you! Kudos for Massive
TypeScript for sure, or even some other language that compiles to JS (e.g. I know people developing Node JS apps using Reason).
Just express on BE and React on FE.
Typed language because of the confidence it gives you that things work (or at least there are more chances they work).
Express because I like the simplicity of it and then you can choose how to organize.
React because of it's paradigm. View as a pure function of the data, JS as the way to build UIs (instead of some DSl based in HTML). And also it has a big community so you'll find a lot of things already solved.
Do you keep the backend and frontend code in the same or separate repositories?
If you are going to use the same language, then definitely the same repo. Easier to share code (and types).
Express/Fastify, Nuxt/Angular/Markojs
I usually use nuxt with fastiy on one, Nuxt had the template, but that for simple one. If the apps got big enough I separate my apps. For fast realtime dev, i use Feathersjs.
Dont use typescript yet. 🤔 Should I? Never seen my use case in it.
For linter I use xojs. Simple no overwhelming setup.
Testing as usual, tap, assert, mocha, chai.
Just learning docker now, so maybe will include it later.
The testing stack matters too! 💪
server:
express.js
sequelize
source in ES6 stage-0 (babeljs)
client:
Reactjs
Redux
Database:
MySQL for production
Sqlite for development
Redis as key store for things like tokens for auth and data caching
Migrations:
custom script based on sequelize
proxy server:
nginx
everything packed in docker containers and runned with docker-compose
Choice of stack for me for some years now is the MEAN
MongoDB for the storage
Express for the APIs
Angular for all things frontend (using Angular Material). PWA out of the box support great.
Node.js
Although I've played with Cockpit (by Agenjeto) and recently, Strapi (the 3 alpha)