BlackSheep: Fast ASGI web framework for Python | Hacker News Reader

BlackSheep: Fast ASGI web framework for Python

github.com

63 pointsklaussilveira47 comments

I enjoy building frameworks and libraries for fun, so kudos to you for that. At first glance, BlackSheep seems to combine the aspects of Flask, Django, and FastAPI. However, I’m a bit skeptical about its ability to coexist alongside them. The one feature I believe could drive the success of the next Python framework is the ability to operate in nogil mode.

What is the plus value vs a 'classical' equivalent like FastAPI ?

So as far as I can tell, this is basically a more modern Flask. It pulls in design lessons from FastAPI, but it's still more batteries included such as templating (jinja2) and authentication.

Neat, but tbh I am very bearish on Python's future beyond APIs - templating html in Python is a terrible idea for anything larger than a hobby site, when you can have an API-first app with a React+Typescript frontend.

And if you need more than FastAPI, you might as well use django-ninja and get the full Django ecosystem at your disposal.

For Django, there's also django-bridge. This lets you build React apps that are backed by Django views/routing. You can also use Django's built-in authentication and forms which isn't easy with APIs.

Yes, auth between Django and a PWA is not a solved problem. It seems people just give up and go the hosted auth route or something.

But it's also really not that difficult. Auth just takes a lot of practice for people to grok so most people don't want to touch it.

I'll open source something once we're done solving the problem cleanly at my company.

There is no canned way to do it in one shot, but using regular Django session authentication together with a PWA frontend hosted separately is not that difficult.

The actual authentication remains on the Django app, using the standard way of POSTing to a login form and receiving a session cookie -- only instead of a server-generated page serving a HTML form, you have the PWA lipstick sending data directly. This approach is so much simpler than dealing with id/access/refresh tokens, encryption keys, black lists, and all of the OIDC dance.

I have just recently been looking into this. What would you normally reach for when doing templating?

HTML-based templating is toxic to a codebase, especially django templating. It is untyped, impossible to compile and trust, and it's horrible to maintain.

Use React and JSX (TSX, to be more specific). NextJS does good quality SSR, use that if you want an app that is also usable without JS.

Anybody not in that ecosystem /right now/ is going to be lagging behind by so much in velocity and capability, and will get eaten by competition.

This simply isn't true.

I see the velocity, but high magnitude doesn't mean that you're going the right direction.

Like jumping off a building and bragging about how fast you're going.

I agree that HTML templating is toxic. But there are other ways, like htpy or htmy etc. Basically server side HTML rendering. This is what makes me interested in focused frameworks like this.

Another ASGI web framework mimicking the Flask API: https://github.com/pallets/quart/

Quart has hidden bugs that you'll only discover in prod.

I'm building and maintaining Blazeio: https://github.com/anonyxbiz/Blazeio. Blazeio is designed to handle massive concurrency with low response times and high requests per second. It utilizes a perishable buffer, discarding chunks as they are received, and operates with a single task throughout the entire request/response cycle. In theory, Blazeio can scale to handle infinite concurrency. While Black Sheep crashes under heavy load, Blazeio continues to scale seamlessly and outperform it.

So much negativity here ... I like it very much. Browsing docs makes me want to code some backend in Python, which historically never been the case.

Are there any good alternatives to gunicorn out there that don't require async? We're not ready to migrate everything to async, but gunicorn's forking model is blowing up on macOS 15.

I’ve started using Granian[0] recently with good results.

[0] https://github.com/emmett-framework/granian

FastAPI uses uvicorn which is ASGI, but you can choose to implement endpoints as either async or sync. I have implemented servers using both styles. Very pleasant to work with, and everything is type hinted, which is a must for me in any serious Python project.

You don't want to use uvicorn with synchronous views though or you're limited to a single request in flight.

If for some reason you need to mix sync/async views (maybe during a migration) you can use uvicorn as a gunicorn worker type, and run multiple workers. But your async views will still scale much better.

Nobody seems to be asking why Python doesn't have the equivalent of Go's net/http.

I think Django is justified given how powerful it is, but these micro-frameworks are ridiculous.

It's not production ready but, Python has had http.server for a long, long, long time.

https://docs.python.org/3/library/http.server.html#module-ht...

How does this compare to Litestar?

https://litestar.dev

I was trying to see the value of this as well, but I don't know Python well enough. Maybe there is no ASGI for python?

And I assume Python cannot handle it's own HTTP server (using threads, similar to Javalin's virtual threads)? I always cringe when a programming language needs to find another solution/language to handling its processes. I understand why you will need a load balancer, but for small, simple projects, I like to contain things.

Python has had threaded, multiprocessing and such web servers for 20 years now e.g. in the form of Apache's mod_wsgi.

The async movement is recent, and optional in Python. There are benefits for async, but obvious downsides line coloured functions.

There is no true function colouring in Python. You can do `asyncio.run(async_function())` inside almost any sync function, or provide your own async shim.

"async def" is literally function colouring

> And I assume Python cannot handle it's own HTTP server (using threads, similar to Javalin's virtual threads)?

ASGI is an Interface standard, not an implementation in another language. The AGSI compliant servers that Blacksheep recommends are both written in Python.

Nitpick: If you're going to use ASGI with Flask, consider using Quart[1] instead[2], which aims to be Flask with better async.

1. https://quart.palletsprojects.com/en/latest/

2. https://flask.palletsprojects.com/en/stable/async-await/#asy...

There is plenty. FastAPI, Starlite and Flask are all ASGI.

Yes, Python has its own ASGI HTTP Servers, Uvicorn and Hypercorn are two most common.

I agree, I'm not sure what this project aims to fix over other more established projects.

It has dependency injection

Starlite rebranded to Litestar btw, to avoid confusion with Starlette. It’s really nice too.

ASGI, and WSGI before it are standard interfaces for python web traffic.

it allows you to write an application (or in this case a framework) and have it work with multiple application webservers. I don’t know if java has an equivalent, but imagine if you could switch from tomcat to something else without changing any application code.

it's been a while ( 25-30 years ) but i think that was the whole point of Java servlets. Tomcat was the reference implementation but there were other application servers out there with more features that, in theory, you just upload your war file to and the application runs. I think one was named Glassfish but it's been a while...

from the README:

> BlackSheep belongs to the category of ASGI web frameworks, so it requires an ASGI HTTP server to run, such as uvicorn, or hypercorn.

but uvicorn and hypercorn are both Python libraries

so no need to cringe

Feels like an in-between library that I'm not sure has a great fit in the current Python BE environment.

It's not as batteries-included as Django, primarily because Django's the incumbent and the ecosystem is vast.

It's not as modular and independent as Flask, which it's taking a lot of inspiration from.

It doesn't seem to bring enough to the table to be flat out better all-rounder than FastAPI.

I'm quite unsure where I'd use it instead of one of those 3.

From searching through the documentation and trying to find it out, the primary "secret sauce" seems to be Dependency Injection, quite a hard sell for a Python framework.

FastAPI also supports dependency injection.

Was quoting the library's docs.

I've actually used FastAPI's DI, which is a nice convenience. It didn't feel as a big selling point, again, due to this being Python. Wrapping up your own DI is near trivial, and barely feels like a pattern.

Thanks for pointing that out, I didn't even realize last night how weak of a selling point this is, even.

Yeah, you’re right that it’s not a strong sell. It’s not clear to me why I’d want to use this over any other more mature framework.

I must have missed the part where we decided there can only be three Python web frameworks...

For a start, this shouldn't be compared with Django at all. This is, as far as I can tell, a web framework, as advertised. Django is a complex CRUD-web-app framework that is commonly mistaken for a web framework (probably because it calls itself that).

This is important because while there isn't really room for many Djangos, there is room for many web frameworks. That's why we have lots: Flask, Bottle, FastAPI, Pyramid etc.

Django is like a complete house: it has everything you need for doing a very specific thing, namely building a CRUD web app. But if you want to add an extra room or something it's a struggle. You either rebuild the house or clumsily bolt on an extension.

This kind of thing fits into your own software architecture which you'll hopefully design to be simple and adaptable. The choice between FastAPI, Flask or this is but a tiny detail at the edge of your application, like the colour of the front door of your house. You don't build the house around the front door, you just choose the colour you like and if you change your mind later you get a new door.

Stuff like Django has convinced people that choice of web framework is a huge deal that will determine the entire future of your application. It shouldn't be like that. Choose modular components and don't write yourself into a corner.

what's the difference between fastapi?

I’m worried about the psychological health of people that make stuff like this. Why? Nobody uses these frameworks unless paid, you need an actual team of people to maintain it.

It's for the cv and getting hired through the tech stack. Most hope to become next fastapi

Well yeah, and there is no support. I've had this issue open for months:

https://github.com/Neoteroi/essentials-openapi/issues/47

...sometimes people build things for fun, or as proofs of concept for iterative improvement on existing tools (which can then go on to inspire changes in existing and new mainline tools).

What does that have to do with (negative) mental health?

No, it’s a pain in the ass to do this. It’s not fun at all. It’s more a kind of boosting that makes it fun. Just aimlessly coding is dumb to justify.

I like LiteStar for this reason. It's similar to FastAPI, but I like the breadth of leadership involved.

I built Blazeio ([https://github.com/anonyxbiz/Blazeio]) because aiohttp let me down in production. I needed a framework I could trust to support high-concurrency web apps, and rather than just complain, I decided to build it myself. It’s not about coding pointlessly, it’s about solving real problems. I update it for me, but since others have faced similar challenges, they can benefit from it too. I designed to be efficient, scalable, and lightweight, capable of handling hundreds of thousands of requests on a single server with minimal resources. Sometimes, creating something is motivated by necessity, not just by a paycheck.

Reply on news.ycombinator.com