Hacker News new | ask | show | jobs
by petargyurov 2401 days ago
> Flask is very easy and simple. It's fun to put a few endpoints in a single file. However when your application starts growing into an endless of endpoints, tons of models and views, or your team is having more people, it is very necessary to have some sort of structure in your application.

How is this different than the typical Blueprints setup? My Flask applications are split into modules, each with its own Blueprint; this helps organize large projects.

2 comments

To that same quote: seriously? I've used Flask quite a bit, and never in a single file. Look up a decent (non-toy) tutorial, and they won't either.

I _think_ it's trying to offer something a bit more Rails-like. If that's its objective, it should say that, and not start with such a strawman.

CakePHP does the same routing by naming convention, and I can't stand it. Forcing you to name your functions based on the url is horribly inflexible and has bit me in the ass before. There are sloppy ways around it such as modifying .htaccess, but it leads to an inconsistent codebase where either only some routes are done the way the framework intends, or all routes are done an entirely different way.

I've been instructed to add endpoints with a specific URL, but the corresponding naming requirements for routing was already taken by another method that was heavily used throughout the application. So either tell marketing that won't work because of technical reasons (which doesn't go over so well), or re-name a bunch of perfectly good code because the framework is inflexible.

Yep. Maybe not true, but also sounds too much for me like object-orientation is the saviour to all structural problems, and by just using it all these issues will go away.

No, that is not the case, practice taught us now for years it can even become the opposite; heck why are universities still teaching this without questioning :(

No programming paridigm will solve every problem well. And plnety of problems are easy enough that any paradigm will solve them well enough.

The author is simply offering one solution to a particular problem from one paradigm. Plus it's python so it mixes and matches with functional programming more than most.

I don't think it's a case of seeing everything through a beginner's lens of "freshman level object-orient all the things".