Show HN: Assembly: A Pythonic Object-Oriented Web Framework Built on Flask | Hacker News Reader

Show HN: Assembly: A Pythonic Object-Oriented Web Framework Built on Flask

mardix.github.io

67 pointsmardix43 comments

> 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.

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".

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.

I thought the whole idea of Flask was to keep it simple. Reduce the amount of boilerplateing and potentially "useless" features of other frameworks, i.e. Django + DRF. For what I've seen so far, it looks like you've put the Django + DRF features on top of Flask.

My question would be, why should I use Assemby instead of Django + DRF?

Looking at the docs, then looking at the amount of contributions on Github, the answer is simple: You shouldn't.

Well, clearly the project is in its early stages. I would be up to try something new if there is a good reason for it.

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.

Instead of shitting on Flask (which is in fact great as-is and nicely suited to large projects via Blueprints), why not just build your own web framework and try to get support from the community based entirely on the merits of your framework? And I agree with others comments that this project seems to be adding mostly a bunch of magic Django-esque contraptions to the code, which I very deliberately choose Flask to avoid.

And so maybe Assembly finds a "this one's just right" spot between minimalist Flask and maximalist Django.

it would be superb if something like this can be built on the newer ASGI based frameworks - Starlette or Fastapi (which is built on Starlette).

They are among the fastest python frameworks according to techempower benchmarks, have automatically included type checking and are async.

Indeed, it's surprising that someone is building today a framework in Python that is not async, when it's pretty easy to do so (compared to eg. the twisted days, but even to pre3.6 days).

Async is not helpful for most projects and complicates the rest.

While async is a huge plus of fast api I’ve found the documentation creation to be the most helpful. My 2c.

That's an odd assertion. What kind of things do you think most projects do? I'd say most projects have network IO happening (querying databases, storing data to e.g. S3, communicating with other web services), in which case async absolutely is helpful and far more performant.

https://techspot.zzzeek.org/2015/02/15/asynchronous-python-a...

That's nearly 5 years old now, so even the bits of that which are backed up with actual data aren't of much use. Benchmarks of asyncio in python 3.4.1 are going to be wildly different than in later versions. I understand the argument he's trying to make about db access and performance, but modern benchmarks seem to disprove his argument, e.g. https://www.techempower.com/benchmarks/#section=data-r18&hw=... and https://www.techempower.com/benchmarks/#section=data-r18&hw=... .

Not sure what I’m looking for.

In the second URL, most async frameworks can deliver around 10x the number of http request for endpoints doing 20 sql queries to pg (15000 vs 1500 for flask/django...).

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).

Yes, sorry, those are benchmarks for python web frameworks making db queries. All the top performers are async frameworks.

Yes I’ve seen this site before and knew that the top performers are async. However thought there was a particular application where it helped most, eg websockets rather than simple crud. Most apps aren’t making super simple queries like this either. Whether any of it matters much I’m not sure.

>Assembly Makes Flask Great Again

The fact that flask can bar a basis for other frameworks makes Flask (and werkzeug) great in itself.

This phrasing turned me off. In the USA there are political connotations such that to over half the population, the meaning of 'making great again' is the exact opposite.

I didn’t realize Flask wasn’t great?

From the tutorial:

    class Index(Assembly):
      index(self):
        return

How is this valid Python?

Probably another case of code that is published, but never executed. The first block of code on the tutorials page has the missing def keyword. Feels like a human editing error to me.

it's not.

Be aware that repository has 0 (zero) contributors on Github.

If you want a very Object Oriented Python web framework thats actively maintained and older than Django and Flask check out CherryPy. It was the only framework I saw that you just make a class and expose your routed methods and they become end-points. Every other Python framework looked odd to me with all the annotations.

Have used it fot 3+ years in production and its done me well.

Can this handle websockets and streams?

Some good ideas here. Similarly, one thing that bugs me about all/most frameworks is that you have to spend a significant amount of time “wiring things up,” ... connecting models to views to the admin.

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.

One tip: add a comment to the thread giving the backstory of how you came to work on this, and explaining what's different about it. That tends to seed discussion in a good direction. Good luck!

I think its quite a poor choice for web framework name ;-)

But it would sound really sexy to be able to say that "I've build that using Assembly" :)

If you want to be able to say that, you should actually do that: https://asm32.info/fossil/repo/asmbb/artifact/68f9999f296320...

Also, this is a terrible, horrible name, seriously.

I'm pretty sure there there is scant Assembly language content in Assembly.

Picking a short, unused name related to the project is hard.

Not really?

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

You may have missed "related", although I suppose use of the Roman alphabet sort of counts.

Since it's a web framework, how about "Web Assembly" instead? Oh wait...

It is a terrible name. You can do web dev in pure Assembly and it actually makes sense in contrast with yet another framework over a framework over an interpreter over POSIX-libraries.

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.

I thought the flowers bracketing the name unappealing as well.

While the intro complained about application scalability, I wondered about Assembly's relationship to Flask blueprints.

You're going to dump on them for flowers on the home page? Really??

I think more projects should feature flowers. They're nice. I feel confident O'Reilly would back me up on this one.

In the context of discussing the library's marketing/presentation I think the the branding is also fair game. It's also a little odd how at the bottom of the page it gives credits to the image as a non-commercial license. Personally I would recommend avoiding any licensed assets in such a project all together (when possible).

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.

Reply on news.ycombinator.com