Bringing more of Nest.js to Blitz - Should we endorse backend architecture principles?

[Skn0tt]

In our community Discord, @flybayer asked the following:

I personally like Nest a lot (used it in EntE), and I wrote a (surprisingly popular) article on integrating it with Next.js (which is surprisingly easy).

And while Nest is great, there's a million other ways to structure your backend.
Some people really, really, really like the onion architecture; others would advocate for a plain-old MVC; and there's so many more people with other opinions.

In this discussion, I'd like to gather opinions and ideas around the following questions:

1. Should Blitz endorse specific backend architecture principles?
2. If yes, which one(s)? Why?
3. If no, why not?
4. How strong should Blitz be opinionated about this?

Looking forward to hear your thoughts! Make sure to add upvotes/reactions to ideas and thoughts you like 👍

[Skn0tt]

I'll start! :D

Personally, I think that Blitz should not be too opinionated about this. Any kind of architecture should be possible.
For many small projects, I associate "architecture" with "boilerplate" and "overhead", and these words don't match Blitz' value proposition.

However, this doesn't forbid Blitz from recommending something! Especially when projects become bigger, architectural patterns gain importance.
Blitz should take a stand and recommend some kind of architecture guideline. Which one it is, I have no strong opinions about.

(Personally, I really like the idea of the Onion architecture - although I've never built a product with it, so this is to be taken with a grain of salt.)

[amesas]

I would prefer opinionated + being able to choose your own, like Prisma.

NextJS is already un-opinionated.

A framework that has initial answer on "how-to-do-this-or-that", like Rails or Laravel, would be great.

Forget about how, and work only on the product.

[flybayer]

I'm especially curious to hear from folks who are using Nest about what you would like to see in Blitz and ideas for how it could be implemented/integrated.

[markhughes]

I don't mean to throw the "A" word around, but Angular can be embedded into Nest: https://github.com/nestjs/ng-universal

Perhaps a similar approach for those wanting Nest would prefer something like a module that would load blitz as the fallback?Should someone want those two running side by side.

[emeraldsanto]

Considering we're already using an opinionated framework (especially with regards to routing) on the front-end with Next, I'm sure having a preferred structure on the back-end, while not necessarily enforcing it exclusively, could really be beneficial for newcomers. This could help front-end focused developers ease into the server side of things with a little guidance.

Maybe this could be achieved via templates instead? That way there's still options but the Blitz core is not tied to anything specific.

[uptonking]

node backend is not as popular as php-laravel, ruby-on-rails.
but I believe js is the future.
nestjs is trending in the node backend.
I hope blitz can choose nestjs atchitecture as backend to help making the node backend standardized and better to compete with laravel and rails.

• benefits:
  • classic architecture inspired by angular
  • directly use existing integration solutions like serverless, passport,swagger, schedule, nestjsx/crud

[codthing]

For those who have never used Angular, the syntax of nest is inexplicable, it is not like traditional js

[philipj93]

One of the benefits of using Next.js as a base is the ability to maintain a serverless architecture. That way it's cake to throw your Blitz app onto a platform like Vercel. When you add a custom server, using something like Express or Koa, you'll lose some of the nice static optimization features Next provides.

To be clear, doesn't the idea of using a framework like Nest.js imply a custom server?

[Skn0tt]

We won't integrate Nest.js - although Nest.js definitely can be integrated with Serverless.

But we maybe could assimilate some of it's architecture patterns!

[philipj93]

🤯 That's so cool, definitely going to try the catch-all handler pattern out!

[dngrhm]

👋 I'm just starting to test out Blitz, so take my opinion with the appropriate grain of salt. There is a reason for the "Great -end Divide". The data layer (backend 🙉) is where projects diverge. You will want a very different backend for e-commerce vs. blog vs. todo vs. ... The other option is to go so generic that it is not useful. Express can do anything, but that doesn't get you a headstart on anything.

I'd suggest a more modular route allowing choice. Extend Blitz's recipes to include backend choice. This might require setting up the project as a yarn monorepo to allow for independent deploy process for client(s) and server(s).

[awidjaja]

Agree.

[eduardoarandah]

Opinionated is good

Everthing in their box is a great idea.

For the experienced one, changing structure is easy, but not the other way around.

A newbie can make a mess real quick, or over-engineer because some opinions from stackoverflow / quora.

[paulm17]

I'm working with nestjs. So far I've added

Prisma,
DTOs,
Image uploading with Multer,
Interceptors,
http request (for hitting other 3rd party endpoints),
websockets,
nats (mq) connectivity,
jwt tokens (signing for 3rd party services).

I've probably covered most of it. 😸

Problem is. I'm getting to the point where I'm getting an itch to scratch. As a side point, the next docs aren't great. Compared to Laravel and Vue, they aren't noob friendly and don't explain concepts well enough. I've had to cobble this up by googling articles, looking at github repos and even at package repos. Not to mention some of the deviations didn't work for me (such as JWT).

A further side point. Not sure about the community. 🤨 I've seen a couple of arguments between mods and users over semantics and when I had an issue with JWT. I came across one user who was adamant that because I wasn't using it for passport, I was the one with the problem. Although the nest devs derived jwt from jsonwebtoken. To resolve the issue, I had to use the original package.

Anyway, that wasn't why you called... 😀

What I don't like the most is that I'm duplicating work. Mainly with

Prisma,
Types

Having 1 source of truth, for such a large project as mine would be supremely helpful. But more than that, I have 3 codebases (BlitzJS, NestJS, Golang) I'm having to maintain. I'd like to get that down to 2.

I was thinking. At a high level. Could we have something like this?

Pages: sets up routes like it does now.
Controllers: sets up api routes to return data.

This way, we have a pseudo MVC when doing something like:

import FooController from "app/controllers/FooController";

const [data] = useQuery(FooController);

The controller would just be pointing to a service, which in turn would use prisma to grab the data and return it. Sure in this case it's a simple query. But nest allows for much more complex scenarios than blitz currently does.

So the question is. Is there a way of forking nest, so that something like /hoangvvo/next-connect could be realised and have more endpoints for the application. Additionally, have these same endpoints available by the application only.

Anyway. I just thought I'd share my thoughts as an opening salvo. I'm getting to a point with my project where I may be able to divert time getting into the guts of Blitz and then Nest and for my own purposes trying something out. Like I say, I have a bit of an itch. Usually when I can't no longer ignore them, I start to fork the framework that I'm working on. I did this for codeigniter, laravel and countless js/php packages 🤣.

If anyone has any ideas on what I should be looking at first to prepare. I'll be all ears. Thanks 👍

[benedyktdryl]

I would like to ask for clarification about this topic, is it about:

• adding NestJS patterns to BlitzJS stack
• replacing current BlitzJS code with NestJS parts
• integrating BlitzJS with NestJS application

Or it's about all of it?

---

In my opinion, replacing parts of BlitzJS abstraction with NestJS will be beneficial for several reasons:

• opinionated structure
• great docs
• enterprise support out of the box

Also, NestJS offers a range of abstraction useful for integrating stack with external parts (or other applications) in various ways:

• https://docs.nestjs.com/techniques/events (to be used internally)
• https://docs.nestjs.com/microservices/basics (to integrate with other services)
• https://docs.nestjs.com/techniques/queues (so we can schedule external work to be done out of BlitzJS thread)

Talking about that, even if you are not considering switching to NestJS based abstraction, it would be great to offer some integration concepts for people using BlitzJS as this is IMHO important area - it's easy to start working with BlitzJS but it might be hard for folks to integrate BlitzJS into existing solutions or extend BlitzJS functionality with some custom functionality. It might not relate to NestJS but I am referring to it because it's the only framework I consider enterprise-grade.

[flybayer]

How I've been thinking about it is taking things people like from Nest and building them into Blitz. So they would take on a bit more of a Blitz flavor but have the same power.

[smolattack]

tl;dr: I hope whatever Blitz will offer does not force me to use new, class or extends keywords, decorators and other such OOP vestiges

Below is just a wish list and not meant as criticisms or demands

I'm not sure what most people like about Nest but I hope it is mostly the architectural patterns mentioned by @benedyktdryl. A big part of Nest is a lot of concepts common to Java/C# which makes sense if you want to attract those kind of developers to adopt your framework (or Node/JS in general). It makes much less sense when you consider JS supports higher order functions and has no obvious need for DI or gang of four inspired OOP patterns.

I think Blitzjs's pool of users are either established Node developers (who don't need converting) or people new to fullstack development (or development in general). If those developers then decide they want to use the OOP side of JS, then they're free to do so, as long as Blitz doesn't force the issue as Nest kind of does. If it is absolutely necessary to cater to such needs, I'd rather see a Nestjs recipe (i.e., you either do it the Blitz way OR here's an escape hatch and do it this other way)

[flybayer]

@smolattack that's similar to how I'm thinking about it. Take Nest features and implement them in a Blitz-flavored way.

[codthing]

Yes, I also hate decorators, which make the code ugly and difficult to read.

[awidjaja]

It is better to provide option to inject nest module and extract the API. Let the original nest js app stay in its original repo. People can use NX to create monorepo to join both blitz and nest source code together just like what they do today with next and nest.

[niklasgrewe]

I have also worked with Nestjs and find the structure very clear and simple. All features are individual modules such as auth, tasks etc.. My structure are quite similar in Blitz. For the individual features of my app, I have created several folders: auth, users etc.. After a few weeks of development, I realize that this organization is not perfect yet. I have everything sorted by features, but it's hard for me to see which functions are for the backend and which are for the client. I have some helper functions that are for backend and client and then I have functions that are only for backend and only for client.

I would like to see some improvement at this point. Personally it would help me if we had a backend and a client main folder. So we could better differentiate which code is for the backend and which code is for the client.

@flybayer But isn't such a structure already possible now?

[flybayer]

What about adding a convention of filename.server.js for server only files that will be excluded from the client bundle? This will be the convention for server components, and so I think it will work nicely.

[paulm17]

If we are to take the best things from Nest. When why don't we have controllers also. As when you instantiate a controller, you are in the "backend".

Personally, I think the whole backend and frontend terminology should melt away. A solution would be that the developer just works on the system as is.

[niklasgrewe]

What about adding a convention of filename.server.js for server only files that will be excluded from the client bundle? This will be the convention for server components, and so I think it will work nicely.

I find the idea very good. its easy to use and you understand better what is not included in the client bundle. I would be happy if this is added to Blitz 👍

[flybayer]

@niklasgrewe ok yeah that'd be great! Welcome to make a PR. Add it to this file: https://github.com/blitz-js/blitz/blob/canary/nextjs/packages/next/build/webpack-config.ts. Perhaps as module.rules entry that uses noop-loader

[Mahamed-Belkheir]

I've been following Blitz.js for a while but I haven't used it yet, so take my opinions with a bag of salt, but I've been writing backends in node.js/typescript for a while, imo, Blitz is currently close to a barebones MVC project, JSX pages are the view layer, the ORM models are the Model layer, what's missing is the Controller.

Since I haven't used it myself I can't tell for sure, but I imagine having every route be its own file to grow tiresome at some point, especially for simple CRUD operations (speaking of which, is there a reason why queries and mutations are split? i skimmed the docs but i didn't see a point on why, my only guess is that they're setup as GET and POST routes).

What I have in mind is somewhat simple, you export a class extending a base controller type, you define your API methods there, with the same way queries mutations work right now, resolver.pipe can be turned into a decorator and have it work like it did before.

Example:

export default class ProjectsController extends Controller {
    @Mutation()
    @resolver.pipe(
        resolver.authorize()
        resolver.zod(projectSchema)
    )
    async addProject(input) {
      // etc etc
    }

    @Query()
    @resolver.pipe(
         resolver.authorize()
    )
    async viewProject() {
       // etc etc
    }
}

and then you'd fetch an instance using useController(ControllerClass)

This approach is basically just grouping together the scattered queries and mutations into one class. this approach would benefit from the .server.js suggestion earlier for user made backend code, e.g (splitting your business logic out of the controller and ORM layer)

Pros:

• only changes one layer of blitz (query/mutations)
• can continue reusing the resolver pipe like before
• can create default controllers for auth and CRUD with pagination etc
• can add dependency injection to dynamically change controller behavior (e.g injecting a different prisma model into a CRUD controller)
• can use more decorators to define route properties (e.g query or mutation, swagger docs generation, etc)
• can stay backwards compatible, we can keep useQuery and useMutation and add useController

Cons:

• Have to introduce an OOP styled layer to a mostly functional framework
• Have to introduce decorators to modify the controller methods, though you can get by with just the resolver.pipe decorator

This wouldn't give Blitz a full blown backend solution, but I think it includes the least learning overhead to blitz.js users, compared to integrating with Nest.js, while at the same time offering enough to build more elaborate backend structures.

As for the cons, you'd face the same either way if we took the Nest.js route, and ORMs technically already introduced OOP into the project.

[Skn0tt]

I agree that full-blown OOP concepts / MVC concepts as seen in Nest.js aren't a good match for most Blitz.js applications (I think @flybayer mentioned that somewhere, too). Not because OOP / MVC are bad styles for the backend, but because they don't fit React's single-direction dataflow well. Mixing code styles between backend and frontend doesn't seem like a good idea, especially if there's no hard separation between the two!
Thinking about the single-direction dataflow, CQRS might indeed be a good fit!
A blog post on "CQRS & how it brings structure to Blitz apps" would be a great starting point I think.

[paulm17]

@smolattack I went down the rabbit hole and planning to investigate Rescript with Blitz (next week). Are you currently using it with Blitz and how are you finding it?

Also the prospect of using Rescript on the FE and BE is very intriguing! 🤔

[smolattack]

A blog post on "CQRS & how it brings structure to Blitz apps" would be a great starting point I think.

OMG, please someone make this real 🥺

[smolattack]

@smolattack I went down the rabbit hole and planning to investigate Rescript with Blitz (next week). Are you currently using it with Blitz and how are you finding it?

Also the prospect of using Rescript on the FE and BE is very intriguing! thinking

Sorry for late reply but newborns tend to erase time! I've never used Rescript but I am experimenting with fp-ts and its ecosystem. The link I used was just to illustrate a point as opposed to promote its usage. When you start thinking in functional style, you tend to notice quite a lot of weirdness in code you would have thought to be quite neat before. For example, I never thought throwing was a side effect (I never liked throwing but could never put my finger on what exactly bothered me about it). Trying to use fp-ts and io-ts in Blitz is a challenge because you have to undo or work alongside so much effectful code. I don't know how Rescript could work with Blitz but it would be quite neat if someone figured it out

[awidjaja]

Nest is enterprise grade. Next is also enterprise grade. Allowing the nest integration is required if blitz wants to replace next. CQRS is supported by nest out of the box so I don't understand the rant about incompatible oop thing while wanting a solution on using CQRS.

[utsho-sadhak-joy]

add nodejs or django
This will be optional
user can decide which framework they will use?

[redbar0n]

the point of Blitz is to be Full Stack, so having a backend with Django, Rails or Laravel etc. is out.

[paulm17]

I'm not sure you understand what BlitzJS is. I think it's best you take a look at the documentation on the website and some of the introduction videos. 👍

https://www.youtube.com/watch?v=TTe56M1QscM

[codthing]

If I follow the CCD development model, such as using Storybook, I don't know if it will work. For me, I can use Node-based development frameworks such as Hapi, koa, and Fastify to do almost the same thing, and it has better scalability. I think that if Blitz wants to be more impressive, it needs to produce the necessities and even semi-finished products needed for the project more quickly. For now, frameworks like Blitz did not touch my heart in the first place. Our sense of direction does not seem to be very clear.I think the cross-generation product is definitely not looking vague, it should give people a strong sense of direction.Know where we are and in which direction we should go.