DEV Community

How would you build a full stack Node.js web app today?

Marko Anastasov on February 01, 2019

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!

Collapse
 
gksander profile image
Grant Sander

I've got a handful of node apps with the following stack:

  • Strapi for the backend. I really enjoy it! Nice wrapper around Koa and mongoose.
  • Use Nuxt.js to pre-render my Vue app. I'm a big Vue fan, and Nuxt makes the development really enjoyable.
  • Vuetify as a component library.
  • Until projects need to scale, I deploy both on the same server and use Nginx as a reverse proxy and to serve static assets.
Collapse
 
markoa profile image
Marko Anastasov • Edited

Thanks! I thought it was a typo but there are really Next.js, Nuxt.js and Nest.js 😅

Collapse
 
itsjzt profile image
Saurabh Sharma

😋

Collapse
 
koresar profile image
Vasyl Boroviak

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.

Collapse
 
alexsorinsky profile image
alexsorinsky

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.

Thread Thread
 
koresar profile image
Vasyl Boroviak

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.

Collapse
 
gksander profile image
Grant Sander

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.

Collapse
 
kamalhm profile image
Kamal

Vuetify and Vue is also my tools of choice! Not sure about Nuxt and Strapi, will look into it further

Collapse
 
tgeber profile image
tgeber

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?

Collapse
 
gksander profile image
Grant Sander

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.

Thread Thread
 
tgeber profile image
tgeber

Thank you very much for the detailed explanation. I will definitely take a closer look at Strapi.

Collapse
 
thespiciestdev profile image
James Allen

All-in with TypeScript, on both ends: back with NestJS and front with Angular.

  • I'll front my NestJS application with serverless functions (i.e. AWS Lambda, Azure Functions, etc.)
  • I'll build and host my Angular artifacts on a CDN.
  • I'll update my client-facing pages to point to the latest artifacts at the CDN.
  • I'll cache and build with Bazel (once all of the kinks get sorted out!)
  • I'll pick my database according to the application's purpose/business.
Collapse
 
markoa profile image
Marko Anastasov

How do you organize the serverless functions and frontend code in Git?

Collapse
 
thespiciestdev profile image
James Allen

A single repository with nestjs and angular folders, a shared folder 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 nestjs folder 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.

Thread Thread
 
markoa profile image
Marko Anastasov

Awesome, thank you for sharing!

Collapse
 
davidyoung77 profile image
David Young

Do you have a starter repos I can reference to get this going, this is exactly what I am working on?

Collapse
 
thespiciestdev profile image
James Allen

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.

Collapse
 
imthedeveloper profile image
ImTheDeveloper • Edited

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.

Collapse
 
dvddpl profile image
Davide de Paolis

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

Collapse
 
dmfay profile image
Dian Fay • Edited

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.

Collapse
 
markoa profile image
Marko Anastasov

Very insightful, thank you! Kudos for Massive

Collapse
 
gillchristian profile image
Christian Gill • Edited

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.

Collapse
 
markoa profile image
Marko Anastasov

Do you keep the backend and frontend code in the same or separate repositories?

Collapse
 
gillchristian profile image
Christian Gill

If you are going to use the same language, then definitely the same repo. Easier to share code (and types).

Collapse
 
ahmaddeel profile image
AhmadDeel

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

Collapse
 
mandaputtra profile image
Manda Putra

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.

Collapse
 
markoa profile image
Marko Anastasov

The testing stack matters too! 💪

Collapse
 
kalevski profile image
Daniel Kalevski

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

Collapse
 
khophi profile image
KhoPhi

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)

Collapse
 
bastianhilton profile image
Sebastian hilton

I'm using Gridsome for sites like my personal site that doesn't need a backend. its fast and uploading to Netlify is easy and free.

For bigger sites where i need search, authentication, and a headless approached backend. I use Nuxtjs as my Frontend, Strapi for my Backend hosted on a VPS at the moment until it needs to scale.

I've tried everything from Wordpress, Drupal, Magento, Apostrophe, to python like Wagtail and these two above seems to be my go to as they are fast to learn and build. Also gotta love the all in javascript approach as well.

Collapse
 
revskill10 profile image
Truong Hoang Dung

NextJS for Frontend.
PostgreSQL for Database.
Lamba Serverless for REST API.

Collapse
 
deck1187hw profile image
Miguel Puig

Server:

  • Strapi

Client:

  • Nuxt
  • bootstrap-vue.js

Happy days

Collapse
 
lukvonstrom profile image
Lukas Fruntke

My company is starting to adopt nest.js and it is pretty good so far if you have the ability to research the way how some features work yourself, as the Documentation still lacks sone details

Collapse
 
itsjzt profile image
Saurabh Sharma

I would just go with express and friends and SSR pages without anything react.

Collapse
 
markoa profile image
Marko Anastasov

Yes, there is life without a JS framework for sure.

Collapse
 
itsjzt profile image
Saurabh Sharma

😋

Collapse
 
nputhiyadath profile image
Nidhish Puthiyadath

Express for rest services with mongoosejs for mongodb
passport-jwt for authentication
angular for UI, with angular material library

Collapse
 
gnsp profile image
Ganesh Prasad
  1. Reduce the problem statement to mathematical equations and functions
  2. Plain old functional JavaScript both on server and client (preferably react on frontend)
  3. Docker and docker-compose
Collapse
 
bradsheppard profile image
Brad Sheppard

My go-to full stack:

Frontend - React (w/ Typescript), NextJS, MaterialUI
Backend - NestJS
Infrastructure - Kubernetes w/ Helm Charts