loading...

re: Why Mandarine is by far the best server-side framework in Deno VIEW POST

FULL DISCUSSION
 

@andreespirela , great write up, thank you.

I am still not clear on the benefits of a @GET('/route') vs .get('/route')

This seems overly verbose. More lines of code mean its harder to maintain. While I do think enterprises will benefit from the rigid structure, I don't think this works as well for smaller projects.

I can totally see the benefit of being familiar with SpringBoot developers. But coming from python and node, I am having trouble drawing out the benefits from the extra syntax. Yep, it for sure uses Typescript. But classes are really not that great and are less performant that functions last I checked.

Is the benefit just the organization and rigid structure, outside of personal preference?

Purly asking about the syntax, and choice of class with decorators. I am all in on Deno myself. =)

 

Well, it really depends on how you feel about decorators as mentioned before. For me, and for many people (I personally come from a Java environment) decorators make the code more readable, when you have functional references like router.get(), the boilerplate can get real big in terms of expansion and nested routes, the use of router.get() forces you to have all your routes (or main routes) in a single file. With Decorators such as @Controller and @GET you can divide your business logic and controller logic into multiple files which at the end will be processed by Mandarine. Also, the use of decorators is not only about routes but injection (strong design patterns), Mandarine uses decorators at all levels, if you look at this table among with the examples on the link, you can see how Mandarine injects values through the use of you calling it per se, making your code more automatic, and your business logic will be reduced to many lines of codes at the end, the idea behind this is that decorators can process variables so when the variable reaches the business logic is already processed with that said, while decorators can seem to have boilerplate, the benefits in the long-term are really related to pre-processing and having a great reduction of common logic and common code in the business logic.

While it is true that classes are less performant than functions, it really depends on how you load & call classes, the performance of a class and a function is really slight (in Mandarine). In the case of Mandarine, every component in the dependency injection container (including controllers) is a singleton, which means, Mandarine does not have to create a new object rather than just call it as if it was a regular function so in terms of performance, classes do not really affect the outcome, in fact, they can offer a better coding environment inside a OOP related-style (Of course, if you are more of a functional programming person, you will totally prefer functional programming).

The benefits from a enterprise perspective is really what plays a role here, having your application divided into multiple classes and controllers without having to have the main logic (let's say the main controllers) in a single file plays a huge role on how you organize your application which is one of the points Mandarine tries to cover.

In a nutshell, while it is true that there are no "facts" when it comes to the benefits of one or the other, organization & the extend & benefits of using decorators in the long term will save you a lot of code and business requirements, the very fact that through decorators you can know the metadata of a parameter, function or class at compile time makes your code have so much less boilerplate and more pre-processing (as described), the effects of these will not be of course visible in very small projects, but the benefits of these will be required in long-term or large projects.

Long answer, hopefully it's worth the read.

 

I really appreciate the write up. Thank you!

Code of Conduct Report abuse