Marko Anastasov

Posted on Feb 1, 2019

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

#discuss #node #javascript

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!

Top comments (39)

Grant Sander • Feb 2 '19

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.

Marko Anastasov • Feb 2 '19 • Edited

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

Saurabh Sharma • Feb 2 '19

😋

Vasyl Boroviak • Feb 10 '19

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.

alexsorinsky • Jul 7 '19

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.

Vasyl Boroviak • Jul 8 '19

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.

Grant Sander • Feb 10 '19

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.

Kamal • Feb 3 '19

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

tgeber • Mar 15 '19

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?

Grant Sander • Mar 15 '19

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.

tgeber • Mar 15 '19

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

James Allen • Feb 1 '19

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.

Marko Anastasov • Feb 1 '19

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

James Allen • Feb 1 '19

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.

Marko Anastasov • Feb 2 '19

Awesome, thank you for sharing!

David Young • Mar 6 '19

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

James Allen • Mar 6 '19

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.

Davide de Paolis • Feb 4 '19

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

ImTheDeveloper • Feb 2 '19 • 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.

AhmadDeel • Feb 1 '19

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

Dian Fay • Feb 2 '19 • 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.

Marko Anastasov • Feb 3 '19

Very insightful, thank you! Kudos for Massive

Christian Gill • Feb 1 '19 • 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.

Marko Anastasov • Feb 1 '19

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

Christian Gill • Feb 1 '19

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

Manda Putra • Feb 2 '19

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.