Anderson. JIn this article I'm going to talk about Back End frameworks
Frameworks have been popular in many ecosystems, not only javascript's. This has brought variety to the community. There are so many options for developers, free frameworks, and paid ones. They're powerful and very useful.
But some frameworks try to replace the architecture of our systems. And that is only the beginning of the problems.
Many frameworks sellers authors offer these pieces of software to solve community problems, and that's perfect. We all thankful. But a framework will not resolve ALL your problems, they can't. The author knows their own problems, co-worker problems, friends, and maybe some complaints about development flow that they've read on twitter, reddit or DEV.to. That's the reasons of why the frameworks are created, to solve those problems, not yours.
The problems you have can coincide with the problems that authors trying to solve, that's common, otherwise the frameworks would not be so popular.
The risks begin when we start to fall in love with the frameworks. It's pretty common read the docs and find a tutorial or a starter-page describing in detail how to integrate that framework to your app. In other words, wrap your architecture around that framework. Normally this implies extend framework's public classes or import some source code inside of your business entities, linking more and more your app with each line of code you write.
So. What happen if your system architecture is pretty strict?
Obviously you don't want third party code inside your business rules, but let's say that you're ok with that, you trust in framework X.
But. What happen if the framework isn't useful for your app anymore?
The product has grown up and the framework may not meet the needs of the current app, so the framework isn't as useful as has been in the earlier stages. But that is ok for you, and you feel comfortable coding a couple hours more.
And if with the time the framework evolves in a direction that isn't ideal for your app?
Functions changing, functions dying, updates not-retrocompatibles, etc.
The problem is obvious, all these risks sooner or later will charge invoice, and the damage will be bigger while more grows the app. Those risks are always in there, but most of the time we say 'I Agree' and we put on the wedding ring.
The solution is simple: Don't marry the framework!
A good software architecture is framework independent. You can see frameworks as app details or tools and it's a good practice to keep them as far away as possible from business rules
if it's necessary that some extended classes be inside of intern layers of the app, the ideal solution would be use proxies and keep those proxies as plugins that you could use with your business rules.
Conclusion
The frameworks can be powerful and useful. And the authors will always be deep believers in the piece of software that they write for our community, the problems begins when the users marries with the frameworks. You don't wanna be that person.
Watch from close every framework, don't buy just because it's on trending.
Yeah, the framework X looks pretty cool, but, what is the cost? How you are going to use it? How you are going to protect your app from it? How you are going to preserve the system design when you integrate that framework?
Be skeptical. Ask all these questions to yourself at the moment of choosing a new framework, in order to prevent that it takes all the control of your app.
