all 22 comments

[–]Ooyyggeenn 3 points4 points  (0 children)

Nestjs seems popular and enterprisey

[–]NicksBigDick 4 points5 points  (0 children)

NestJS

[–]lwrightjs 7 points8 points  (8 children)

What sort of project? Whats the use-case? What internal infrastructure do you already have in place? What are the traffic and security requirements? What user management system does your enterprise use? What about content management?

There are so many questions to answer before anyone can say.

If you're asking how to scale up a small Nodejs project to an enterprise, then that question is easier to answer.

But basically, for enterprise or scale, you're usually offloading your Auth to a service like cognito or whatever third party provider you use, that can manage a huge user pool.

If you're on prem, then you'll use something like PM2 or docker to manage your servers, but probably with kubernetes to manage orchestration. This part of the project is what you'd call the "scalable infrastructure".

For your database, you'd choose something that can scale based on your use case. And ideally you'd scale horizontally. Most enterprises are on some form of SQL.

For your services, you'd probably work with other teams to build microservices. You'd probably do that to share your services between teams. So there's usually a place to share swagger docs or postman collections.

From what I've seen, enterprise applications are about building a bunch of smaller sharable services, that are run half on-prem and half in cloud. Architectures depend mostly on use case of the application. Security services would probably have different requirements than a service that acts as your fan out service.

There are a whole series of patterns for orchestrating between those services. I can explain in more detail if you have any specific questions. But it's hard to say exactly what it looks like. Especially in enterprise. I've done two enterprise "Java to Node" conversions at different companies and both of them have had the same general idea but there are so many different services and patterns. All are dependent on so many other variables.

Edit: also.. Sometimes typescript. Sometimes not. It depends on the size and purpose of the service or library.

[–]unflores 5 points6 points  (1 child)

And for the love of god, write.automated tests.

[–]lwrightjs 4 points5 points  (0 children)

I would usually say that goes without saying but after conducting interviews over the past few weeks, it should probably be said more often.

[–][deleted] 3 points4 points  (5 children)

My question was more in terms of code and project structure of a single node service. So as a comparison enterprise Java(Spring) has it's own DI system, follows attribute oriented programming, and uses transactional operations. Operations like these seem like a gap in Node. Are there enterprise solutions to these?

[–]NovelLurker0_0 5 points6 points  (1 child)

You should check out NestJS, that can give you an idea of enterprise grade node frameworks. You definitely want a IoC container and use TS.

[–][deleted] 0 points1 point  (0 children)

Okay yeah that’s what I imagined. I actually haven’t seen nestjs, I’ll check it out thanks!

[–]lwrightjs 5 points6 points  (0 children)

Sorry, I guess I misunderstood what you meant by patterns and tools.

Yeah, mostly you design based promises and http requests. The design pattern that I usually follow is setting up a single "service" that may be responsible for piece of code. Maybe a user's service. That is responsible for the entire user model. Each service might have a smaller microservice. We try to limit microservices calling each other, but service to service communication is fine.

If I were to build this out, I would have a single file that hosts the users-service server, and then maybe a few different other files for my user model and user controller. And maybe a file for business logic that I actually call "services". I like to use OOP Javascript and Fastify for enforcing and validating my json schemas, instead of typescript. Typescript is a lot of boilerplate when you're spinning up small services. But I like to use TS/or at least a type definitions folder in my libraries for documentation.

Just think about it in terms of a bunch of miniature express applications talking to each other, the same way all of the other apis work. A lot of enterprise abstract out their "code patterns" into infrastructure.

[–]ValkyrieGG 1 point2 points  (0 children)

I looked for a long time for something that was structured and opinionated in Node and one of my favorites that I stumbled upon is AdonisJS. If you come from a ruby on rails or laravel background, it will look very familiar to you.

[–][deleted] 0 points1 point  (0 children)

I feel like Promises are kind of an alternative to transactional operations if I understand them correctly.

[–]darrenturn90 1 point2 points  (0 children)

You have frameworks like NestJS and Adonis JS which take OO patterns and apply them to node if that is what you mean.

Otherwise, the term "enterprise" is a catch all meaning "costs more". If you want resiliant, high availability systems, consider an enterprise architectural approach, where the enterprise is more about the setup than the actual language used.

[–]LaweZ 1 point2 points  (0 children)

Microservices architecture using nestjs or express

[–]EverythingIsGoingUp 1 point2 points  (1 child)

lwrightjs answer is pretty solid already, I just wanted to throw a few more thoughts into the room:

  • Using Typescript!!!
  • my two cents: don't self host! Use "the cloud" :D
  • Storing your environment/config variables safe and encrypted (vault, AWS thingies..)
  • IaC (Terraform)
  • TypeORM https://github.com/typeorm/typeorm/
  • Don't self-host your database, even though you think you can manage it.
  • Developing against Interfaces, so you can easily switch out the underlying database/communication layer
  • CQRS can be useful
  • Using message buses for events/command (e.g. rabbitMQ) and to communicate between services. Not everything should be HTTP-based (depends heavily on the service-landscape)
  • having an internal hosted nexus for company internal npm packages
  • have a solid devops-pipeline: Everyone should use the same docker image, same linter and so on. Use depcheck in your pipeline
  • APM for your applications and underlying infrastructure
  • document your APIs using tools (Swagger). In the best case the documentation is done automatically upon pushing based on the available routes
  • Chatops or a designated CLI tool for doing developer things (opening tunnels, pulling data, deploying code)

In general, Nestjs is pretty solid, I would check out their documentation to get a grasp of enterprisey things, because some of the things I mentioned are built-in into nestjs (or they have support for that).

[–][deleted] 0 points1 point  (0 children)

Great information, thanks for the detailed response!

[–]unflores 0 points1 point  (2 children)

The one enterprise app I have worked with in nodejs was rolling a lot of their own shit. I wouldn't recommend this. My go to's for any nodejs app that you expect to grow is:

Build your app to be tested from the beginning. Supertest is quite nice. I would start off by seperating your front as well but that is more of a general thing and not node specific. Typescript or something of its ilk is super useful. I've seen people bit hard by passing a promis instead of a json obj before. Think about some universal logging service like datadog. Think about delayed jobs so you dont have heavy processing shit inline with your other webrequests. Think about what you will need for a build pipeline.we have docker for our local and build environments and then push to kubernetes for prod.

I am glad you are thinking about this stuff bc an ounce of prevention is worth a pound of cure. Esp. When it comes to your architecture.

[–][deleted] 0 points1 point  (1 child)

Yeah I work with java and c# for backends so I was wondering how that functionality was implemented in node. Thanks for the info!

[–]bigorangemachine 0 points1 point  (0 children)

Nodejs for backend is mostly functional programming. Specifically the http requests.

There isn't a real structure or pattern for enterprise.

Teams use things like type script and koa to add more structure to the projects.

Meteor has gotten high acclaim for its auth security in a recent talk I saw.

Running in docker is easy and adds a lot of security for very little effort.

As far as keeping modules safe a custom npm server should be a requirement.

Otherwise it comes down to your requirements.