As someone who has been doing web projects for quite a while, I can safely say that I’ve seen a large number of solutions pop up over the years, which in the end pretty much do the same. In recent years, I’ve been noticing the rise of microframeworks. While I understand the inherent desire for a lighter code base, what I’ve found as a primary weakness is that there’s a lack of features that most people probably want out of the box.
Maybe I’m ranting a bit against Python’s Flask but that’s going to be the focus of this discussion (although I know there’s other microframeworks and I’m certain that they have their share of issues as well). Flask purports to allow people to choose other pieces in building their applications such as the templating system, model frameworks, etc. Out of the box, you immediately get Jinja2 and Werkzeug for stuff like routing. The rest pretty much is left up to you, although the documents do demonstrate small examples in piecing your application together.
I guess from my point of view, there really isn’t such a thing as a simple project where you can just toss a few lines of code to get what you really need working out the door. “Hello world” examples just don’t cut it for web applications, even microservices which may still have their own set of complexities that go beyond the novel examples provided in these documents.
Although the idea of an inherently loosely coupled system sounds enticing, the real problem is that by making your components too loosely coupled you lose the coherence of a problem that you need to solve. Concretely speaking in the case of Flask, splitting out database abstraction and other common pieces of web infrastructure make what you’re trying to accomplish really frustrating. For instance, I’m trying to get Flask-Alchemy working to spit out json. There’s a json function packed with Flask but it cannot handle serializing the result set from Flask-Alchemy. Instead, you either have to hand roll your serialization (which seems moronic) or use yet another external component. Why can’t these components just work together out of the box? That makes no sense.
Now, before you go off and say, “Well, that just means you can use some other ORM.” That’s like the old days where people would talk about having something like an ORM to allow enough abstraction to allow you to not be concerned over your specific database vendor and allow for future changes. That little last bit has become retarded thought abstraction because it’s improbable that one will change vendors at all.
But that’s the key here. It’s better just to have enough of a basic solution tied together rather than presenting options. Why? Most people are going to end up hunting and pecking for the “correct” solution. But if you’re too split up, then this needlessly causes endless confusion and debate on what the actual “correct” route is. Instead, enforcing an opinionated “correct” route/architecture early on minimizes the debate and allows people to focus on the business-centric solutions as opposed to wandering around through hundreds of Google searches and Stackoverflow pages just to find an ideal answer.
In Flask’s case, if you’re intending to create micro services (which might mean simply an API endpoint serving as a layer of abstraction over a database and a few tables), then you better make sure all the other pieces come together easily in some manner. It won’t matter if the core is small or fat if there’s not enough of a unified vision of how something ought to work.
At any rate, I get the desire for what might feel like a lightweight solution. But I just feel it’s impractical almost equally to an overarchitected solution. There needs to be a middle ground for a situation like this. I mean, web programming has been around long enough now where the basics should be easily covered by now. But I’m not getting that feeling, at least with regards to Flask.
Leave a Reply
You must be logged in to post a comment.