In 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.
Top comments (9)
This is an awesome article. We focus so much on the implementation details and learning how to make things work that we put it right at the heart of our applications instead of trying to push those details to the edges as your diagram illustrates.
In the .NET world, once Azure got big you'd see applications where every single class was in some way tightly coupled to ServiceFabric. Once that's done it's really hard to undo.
I could not agree more, we all have favorites that fall in and out of usefulness and popularity. We should focus on the intent and ideas that we are building with the tools like frameworks rather than the embedding our idea into the structure of the framework.
Exactly! Our ideas must be tools-independent.
Thanks for your comment.
I agree with the idea of not tying your business logic with the framework as it surely locks you to that specific one, I never faced the problem of the framework changing its direction or core philosophy. As a back end engineer with a few years of experience in my belt, I can say most popular Python frameworks don't suffer the problem of the goal changing. For example, Django has been very consistent with its batteries included and DRY philosophy year after year. Yes, the framework evolved a lot since it's inception, but nothing that would require essentially an overhaul of your existing codebase. On the other hand, another popular framework Flask is simply a "micro framework", meaning apart from the core mechanics you are free to implement whatever you want. So you are free to do your thing without worrying about common middlewares like session management and caching.
Download vanilla.js
Good article and examples.
Also +1 for the cover image👌
Thanks!!
Great article!
I think in the "Clean Architecture" book Uncle Bob talks about this.
amazon.co.uk/dp/0134494164/
Agreed on priciples. It can be a lot of hard work to decouple an app from its framework later on