Never fight a framework
We have already come a long way in development and engineering. There is tools for almost every repeated thing now. There are tools for protocols, there are tools for patterns, there are tools for integration—you get the gist.
And its very convenient to use them, and I am in full support of it (usually). But the problem comes when you pick a framework or tool to use to solve a particular problem. It can be anything - it can be as small as picking bootstrap to speed up your design, and it can be as complex as picking some platform libraries to support some protocol. It gives you great boost, its easy to begin with usually, it helps you solve the problem in hand, roll feature / things quicker, also maybe give you a discount for not knowing everything in depth yet achieving the result.
But it starts a rabbit hole as well; frameworks are, till some extent, generally opinionated, or I would say they have some prescribed patterns (many people call it best practices too). So if you start fighting it, that’s where things can get nasty. What does fighting it mean (it can mean overriding random things, not using the prescribed practices, trying to write one thing in another, and the list keeps going)? I would give few examples
I have seen people using Fastapi because it supports Async really well and offers other benefits like having a micro framework, out-of-the-box support for Python, etc. But they try to use it as a Django. They will create unnecessary abstraction just to get some convenience they have in Django to have similarities here. By no means, I mean this is wrong, but will you be able to actually leverage what Fastapi offers you if you try to mould it as Django?
I see people using bootstrap but after some time start to override random classes and at one point they will start fighting with bootstrap with more css code overriding everything
Or anything else—let’s say someone picks a library that helps them to do authorisation and it only supports CSV format to add policies. Maybe they could just use an adapter pattern or some preprocessing to convert data to CSV, and the tool should take care of the rest? But I have seen people trying to override random methods inside the library to get things working weirdly. And at what cost later they get to the unique bugs , performance issue, hard-to-understand code, etc
To summarise, I am by no means against enhancing an existing tool or moulding it to your pattern, but it should happen with careful planning and consideration and try to leverage the best offering from the tool you are using and not be shortsighted and only solve problems at hand because its so easy to think, Hey, why not?
So be careful next time you are fighting a framework :)
PS: This blog is a WIP in some sense, as I wrote this raw. Maybe someday i will edit it to add more examples, follow best blogging practices (LOL, I am fighting the framework here), and maybe make it more easy to consume. But thanks for reading anyway. Happy to chat about anything in this if you have got different perspective. Thank you!
