How Mandarine Framework could surpass NestJS
Tags: nestjs, mandarine, typescript, deno
Published: 2020-10-28 20:49:36

# Introduction
Mandarine is a relatively new typescript framework that runs on [Deno](https://deno.land). Its objective is very simple: to provide as many built-in functionalities as possible for application development.

Mandarine is a ready-for-production framework & one of the few packages that are production-ready, and [by far, the best server-side framework in Deno](https://dev.to/andreespirela/why-mandarine-is-by-far-the-best-server-side-framework-in-deno-52dd)

Mandarine was mainly inspired by [Spring Boot](https://spring.io/projects/spring-boot) & owns a big set of built-in tools for development such as [Dependency Injection](https://www.mandarinets.org/docs/master/mandarine/dependency-injection), [Built-in authentication system](https://www.mandarinets.org/docs/master/mandarine/auth-introduction), [MQL (Mandarine Query Language)](https://www.mandarinets.org/docs/master/mandarine/mandarine-query-language), [ORM (with MQL)](https://www.mandarinets.org/docs/master/mandarine/data-interaction), Built-in session middleware, CORS middleware, and much more.

For more information about what Mandarine has and why is _perhaps_ the **best server-side framework** in Deno, [click here](https://dev.to/andreespirela/why-mandarine-is-by-far-the-best-server-side-framework-in-deno-52dd).

# Mandarine & NestJS
Mandarine & NestJS are perhaps brothers from different mothers, they are really similar in terms of syntax & features, some would definitely argue Mandarine has a much _better & simpler_ syntax than NestJS, this is because NestJS tends to adopt the Angular pattern of modules while Mandarine only cares about declarations: there's no such thing as a "module" in Mandarine.

Mandarine does not have the concept of "modules" or "providers", everything is plain declaration of ES6 classes & decorators and it's ready to be used. NestJS on the other hand, abstracts this a little bit more.

Finally, friendly reminder that Mandarine & NestJS run on different runtimes: Mandarine is for Deno while NestJS for NodeJS.

# Mandarine: Richer In Functionalities
Mandarine is perhaps richer in functionalities. This does not mean that Mandarine has all the features NestJS has, not at all. This means, Mandarine has many others (and more) built-in tools that make development easier and reduce the boilerplate of many packages with only one goal: Every major functionality you would write in Mandarine _should be_ a Mandarine-powered feature.

To explain this a little better, let's look at some of the features Mandarine has:
- [Built-in Authentication] (https://www.mandarinets.org/docs/master/mandarine/auth-complete-guide) (No need to write the logic behind securing endpoints, or authorizing users as it is already provided)
- [Built-in Repositories](https://www.mandarinets.org/docs/master/mandarine/data-repositories) (No need to code the logic behind database queries as Mandarine's ORM is fully powered by MQL)
- [MQL (Mandarine Query Language)](https://www.mandarinets.org/docs/master/mandarine/mandarine-query-language)
- [Session Middleware](https://www.mandarinets.org/docs/master/mandarine/session-middleware) (No need to use external packages to manage sessions, as it is already built-in in Mandarine with the option to create your own session container)
- [CORS Middleware](https://www.mandarinets.org/docs/master/mandarine/cors-middleware)
- [Serving Static Content](https://www.mandarinets.org/docs/master/mandarine/serving-static-content)
- [`X-Response-Time` Header Middleware](https://www.mandarinets.org/docs/master/mandarine/built-in-response-time-header)
- [Resource Handlers](https://www.mandarinets.org/docs/master/mandarine/resource-handlers) (Interceptors for different kind of static content)
- Pipes
- Custom Decorators

And of course, there are a few more features that are important but that is not the purpose of this post.

> For more information about Mandarine's feature, visit [its official documentation](https://www.mandarinets.org/docs/master/mandarine/introduction)


# Mandarine surpassing NestJS, Really?


> Extraordinary claims require extraordinary evidence

Many of you may be thinking, how come a Deno framework could possibly better or more stable than a NodeJS one? 
Let's start with some facts:
- Deno is at version 1.5.0, and it's production ready, this has been stated even by Ryan Dahl (Creator of NodeJS & Deno)
- Deno is richer in functionalities.
- There is already room to argue NodeJS and Deno are both good enough for production environments, some would argue Deno is even better since it provides a set of built-in dev tools (like bundling, linting...) & typescript support as first language.

With that said, we can put Mandarine & NestJS at the same level of the discussion in terms of real-world stability.

# Mandarine's Plan To Be Better... Much Better
Deno has an excellent relation with Rust, in fact, you can connect Rust-written libraries to Deno & call the methods inside those libraries through JS. When you think about it, the limit is the sky. We are talking about direct connection of a very powerful language like Rust (which some argue it's much better and simpler than C++) being called/used from a very popular language like JS. **This is a key for Mandarine's plan of success**.

As stated in [this blog: ](https://www.mandarinets.org/posts/making-mandarine-the-most-stable-framework-with-rust-)
>  If Deno is not capable of providing a required feature for stability, we would use Rust again to cover these needs.

That means, Mandarine is not only a Typescript framework but will also be powered by Rust.

### Why does this matter ?
Rust is a very popular language (most loved language for 4 years in a row according to [Stackoverflow](http://stackoverflow.com/)), it has been out there for 10 years, and we can all agree it is very very stable. As a matter of fact, Google is considering integrating it in its V8 engine ([Click here for more](https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability))

Now with Deno, Rust & Mandarine, Mandarine would connect every requested feature that Deno cannot provide to its Rust core which means, Rust would provide functionalities to Mandarine thus bringing Rust's stability & Rust limitless internal processes to Mandarine (The JS/TS world).

Quick example of what this means: You want to use Mandarine to modify images, but there are no packages in Deno to do such things (nor Deno provides such functionality). It doesn't matter, Mandarine will provide you a rust application to modify images that you can call from your JS/TS application.
Of course, this is a very vague example, Mandarine's rust core is meant to go along with Mandarine's goals. But I mention this example for a better perspective on what this means.

### What does this have to do with NestJS & Mandarine?

With the support of Rust, Mandarine can provide functionalities that are yet to exist in Deno & NodeJS, this will give Mandarine advantage in both runtimes.

One of the main features of NestJS (which Mandarine is missing) are microservices. Microservices in NestJS are entirely coded in Typescript (JS). On the other side, Mandarine could provide a communication-interface for microservices written in Rust but used in the JS side, thus providing performance and more stability in terms of maintenance. 

### Is It Happening Already?
One of the goals Mandarine has had for quiet a long time is to provide a very stable, multi-threaded, database driver not only for Deno but for its internal usage.

This week, Mandarine came out with [`Mandarine Postgres`](https://deno.land/x/mandarine_postgres@v2.1.6), a PostgreSQL rust driver that you can use from Deno which officially made Mandarine a framework with mixed codebases.

This driver makes use of [`tokio-postgres`](https://github.com/sfackler/rust-postgres) under the hood, a widely-used Rust driver for postgres which has been out there for more than 4 years.

This, again, is one of the examples of "What Deno can't provide, Rust can".


# The End

This post is not meant to dismiss NestJS awesome work and features rather than presenting both facts & views to how Mandarine _could_ in the future surpass NestJS in terms of functionality and perhaps stability with the Deno core.

This post is also meant to show how Deno can get to be more stable than NodeJS in some scenarios, or how packages in Deno can take advantage of Rust for the better.

The different opinions towards NestJS are just that, opinions. It is up to the reader to interpret this post. While it is true that Mandarine may be at the same level of NestJS, it is also true NestJS has been out there for much more time and it is widely used globally because of the excellent work they have done & provided to different companies around the globe.


----------------


<img src="https://raw.githubusercontent.com/mandarineorg/mandarineorg_web/master/app/mandarine-static/assets/images/headers/orange.png" width="300" height="300" />

## Simple Usage
[Click here](https://www.mandarinets.org/docs/master/mandarine/hello-world) to see a quick example on how to get started with Mandarine

## Mandarine on social media
- [Twitter](https://twitter.com/mandarinets)
- [Discord](https://discord.gg/qs72byB)

<img src="https://raw.githubusercontent.com/mandarineorg/mandarineorg_web/master/app/mandarine-static/assets/images/headers/black.png" width="300" height="300" />