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.
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.
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.
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 :(
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".
My question would be, why should I use Assemby instead of Django + DRF?
My current mindset is: - Simple internal API with not much complexity => Flask - Complex API with authentication and other moving pieces => Django.
Always taking into account the team's expertise.
They are among the fastest python frameworks according to techempower benchmarks, have automatically included type checking and are async.
The fact that flask can bar a basis for other frameworks makes Flask (and werkzeug) great in itself.
class Index(Assembly):
index(self):
return
Have used it fot 3+ years in production and its done me well.
That should happen automatically in my opinion. I’d like to create a model class in a models folder and have it found, loaded, tied to views, templates, the admin already. Customizable still of course.
Would also like an admin page to download common models like wordpress plugins. Say CMS with comments, roles, history/audit etc. All built to standard interfaces. Why do I have to reinvent this and wire it up every single project?
Also flowers and Trump themes are a weird combo. Especially when Flask is relatively unchanged. The design is either great or not depending on your perspective.
Also, this is a terrible, horrible name, seriously.
Picking a short, unused name related to the project is hard.
E. g. monitoring for mission critical servers. You really don't want the whole stack of unverified goodies on these machines, but since you already have TCP/IP for SSH, writing a simple web-server that reports machine health over HTTP is like a half-day job.
And it's verifiable since it's small. It doesn't drag the whole Python infrastructure with it.
While the intro complained about application scalability, I wondered about Assembly's relationship to Flask blueprints.
I think more projects should feature flowers. They're nice. I feel confident O'Reilly would back me up on this one.
But at the end of the day if you build and release an OSS project you should get to do whatever you want with it, like the use of emojis that was discussed in the postwoman.io project that came up last week.
My opinion is who cares, we should be discussing its technical merits first and foremost on a forum like this.
Literally throwing a dictionary on the floor and pointing would work. Or checking whether the name is being used via a 2-sec google search? People avoid start companies with the same name as other companies -- it's not that hard.
In this case, what about Fett? Flask + (D)jango Fett
Note that this thread is a discussion of a new web framework — one that will definitely do network requests, and likely to do db requests (over a network or a local socket, but I/O bound regardless).