loading...

What Mandarine Framework needs to be production ready

andreespirela profile image andreespirela ・3 min read

During the last few days, as the creator of Mandarine Framework, I have not been able to stop wondering whether Mandarine is ready for production environments, that does not mean whether Mandarine has everything but whether Mandarine is reliable enough.

Mandarine has grown over the past months in functionalities and stability, although the community is still fairly small, in fact, I am the only collaborator.

Mandarine has an extensive built-in tools that allow you to develop complex applications (front-end & back-end) with important Design Patterns such as SOLID & Dependency Injection. Everything in Mandarine is based on the MVC pattern, SOLID, and the use of Components (Your application should be modular in order to be well-distributed). Click here to see some of the features

With that said, I have to say: I do not feel comfortable with the idea of using Mandarine in production environments with a lot of traffic/usage.

The Deno Problem

  • Deno is fairly new, it is still in its early versions (1.1.1) and it is yet to be widely used.
  • Among other things, Deno has a lot of questions to be addressed like the multiple modules issue: What if a module goes down, what if the module of a module of a module goes down. Since Deno does not have a package manager like NPM and imports are cached but they are not directly related to our application, it is hard to define or track when a module breaks another module and ends up breaking your application too as well as many other issues you can think of related to this concept.
  • The fact that Deno is very new and its in early versions gives Mandarine a lot of impediments such as working with reliable Database modules, only if the Deno community grows to enterprise levels then Mandarine will be able to support multiple database systems.
  • With Deno being in its early versions as well as Mandarine, it is almost impossible to determine what impact Mandarine can have on a large production environment.

Why It is not production ready

  • It needs a testing framework not only to test the core behavior but also for users to be able to test their Mandarine-powered application
    • As of right now, Mandarine does not have unit tests. Every module must have unit tests.
  • Mandarine must have continuous integration with Github workflow.
  • Code needs to be refactor since there are part of the code that are not located in the right places.
    • Part of the code needs to be cleaned.
    • Everything in Mandarine should be a proxy or a factory in order to make testability easier.
  • Benchmarks must be created and added to the documentation in order to be able to measure how much changes are affecting.
  • Mandarine needs collaborators in order for it to grow and get impulse in both communities Javascript & Typescript.
  • Evaluate how things evolve with Deno.
  • Document the life cycles of Mandarine framework engine, and perhaps make the starter implementable so the developer can override behaviors.
  • Mandarine needs a website with the documentation and everything related to Mandarine. As of right now, Gitbook is being used but it turns out to not be enough.
  • Standards need to be implemented not only for the collaborators but for everyone who uses Mandarine.

Looking for collaborators

Mandarine is currently looking for Collaborators to help start addressing new features, fixes, but overall, the steps for Mandarine to be production ready (See issue here)

Disclaimer

I am the creator of Mandarine Framework

End

Do you have any thought? Please, I would love to know it even if I do not like it. Comment it below.

Posted on by:

andreespirela profile

andreespirela

@andreespirela

Creator of Mandarine.TS Framework. I am addicted to refactoring code. Self-taught since I was 9 years old. I love rockets.

Discussion

pic
Editor guide
 

I agree with you, it is not yet in a very stable point for production, regarding the packages nest.land is doing a great job since the packages are immutable, and to handle dependencies Trex is an option, only that it is based on imports map and using imports map is more aimed at projects in production than at libraries

 

I like nest.land, MandarineTS uses it for Orange, the official testing library of Mandarine. Although, I have to see the development of nest.land. As mandarine, it's in its early versions, and it's impossible to predict what can happen if thousand of thousand of people use it at the same time.

I'll be checking out Trex

PS: I saw your PR, checked your website, and github... Mandarine needs collaborators, feel free to reach out if this is something you'd like to participate in.