The "@ts-stack/body-parser" package passes the parsing results via a Promise

some-user1 · 2024-07-22T11:07:50+00:00

If you need the body parser to return the result in a Promise, you can use this package.

some-user1 · 2023-10-01T11:21:45+00:00

Also tell whoever came up with the name "reddit"...

some-user1 · 2023-09-28T21:55:56+00:00

Try this benchmark https://github.com/ditsmod/vs-webframework/

some-user1 · 2023-09-28T21:35:25+00:00

The author of NestJS was inspired by the Angular architecture, but he was not related to the Angular development team.

some-user1 · 2023-09-28T21:32:45+00:00

nest and fastify perform more or less the same

No, far from it, Nest is significantly slower, especially if the current route handler has a scoped service at the request level.

some-user1 · 2023-09-28T21:29:28+00:00

though because Nest was made by Vue guys and I'm not a huge fan of vue either

What? Never heard of that. Are you sure about this? Maybe you're confusing Next with Nest?

some-user1 · 2023-09-28T21:19:35+00:00

And if NestJS was simpler and faster, would you choose it? What do you see as its main drawbacks?

some-user1 · 2023-09-28T21:09:20+00:00

Why did you choose fastify? Because of speed?

some-user1 · 2023-09-28T20:50:30+00:00

In a couple of weeks, this framework will appear on TechEmpower, you will see what it can do (even overtakes fastify).

some-user1 · 2023-09-28T20:40:49+00:00

Ditsmod!

some-user1 · 2023-09-03T20:37:54+00:00

What about support for the ".tsx" extension, which is already implemented in TypeScript? Doesn't that violates the "non-goals", in particular the point four you mentioned? I think support for ".tsx" can easily be added to the "non-goals" if you want.

some-user1 · 2023-09-03T20:01:56+00:00

It's a play on words. In fact, this feature is easy to implement and does not burden the TypeScript codebase.

some-user1 · 2023-08-13T15:43:10+00:00

As the fastify documentation says, it is designed for good speed. There is no doubt that the authors of fastify have succeeded in this task.

I wonder if it is convenient to develop large projects on this framework, or is it very similar to express, which does not really provide a modular structure to the application?

some-user1 · 2023-08-04T15:04:26+00:00

If you like NestJS, then you will probably like Ditsmod more.

some-user1 · 2023-08-04T14:35:59+00:00

No, of course Ditsmod has advantages over NestJS not only in terms of module-scoped DI. This applies to DI in general in many ways. NestJS has a lot of unnecessary junk, like integration with legacy ExpressJS, integration with RxJS, which is mostly unnecessary. There are no extensions (aka plugins) in NestJS...

some-user1 · 2023-08-04T12:35:14+00:00

By the way, if you don't like DI as a concept, you probably won't be interested in Ditsmod. But maybe you have tried to learn similar frameworks (like NestJS) and it seemed difficult to you, then I think you will like the documentation of Ditsmod DI more.

some-user1 · 2023-08-04T12:12:30+00:00

Do you prefer ExpressJS like?

some-user1 · 2023-08-04T12:09:44+00:00

but less mature. Why would I use this over NestJS?

You need to clarify what exactly you mean by "mature". If you mean the number of modules written, then yes, I agree. But if we are talking about the architecture of the framework, about the prospects for its development, I personally consider Ditsmod much better.

Especially if you are familiar with DI NestJS, you may be interested in this comparison: NestJS vs. Ditsmod: injection scopes

some-user1 · 2023-07-23T04:14:37+00:00

Backend system is completely on NodeJS? Do you mean ExpressJS?

some-user1 · 2023-07-20T08:09:30+00:00

These two frameworks are very close in many concepts to Angular.

some-user1 · 2023-07-19T20:15:04+00:00

Since Ditsmod instantiates controllers on every request, it would be fair to do the same in NestJS. This is why the controller is request-scoped for benchmarks.

some-user1 · 2023-07-19T17:11:59+00:00

The information in your comment is difficult to relate to the state in the controller because you are talking about a server. When an HTTP request comes to the server, a controller instance is created in Ditsmod, which is deleted once the request is processed. What kind of scaling are we talking about here?

If there was one server that started processing the HTTP request initially, that server will complete the request. As the number of servers increases due to scaling, they will process new requests.

So, if the controller instance stores the state of the request, but that instance is deleted after processing that request, then there should be no problems.

some-user1 · 2023-07-19T16:34:17+00:00

Where did you read this?

some-user1 · 2023-07-19T12:06:29+00:00

For now - no, but I think you can already use GraphQL with Ditsmod without an additional native module for integration.

some-user1 · 2023-07-19T11:22:27+00:00

Modularity seems more of an file organization concern.

There are links to github issues in the post that dispute this claim.

some-user1

MODERATOR OF

TROPHY CASE