▲ 106 points
back
26 comments
Similar project from pimoroni: phew!
https://github.com/pimoroni/phew
> Sometimes applications need to store data during the lifetime of a request, so that it can be shared between the before or after request handlers and the route function. The request object provides the g attribute for that purpose.
Eh I dont get it. "g" for globals?
`g` is short for "global", but it is global to that request only. This makes data available to hooks which can wrap request handlers before/after they execute
It's inspired by Flask's same functionality, though it's a part of the greater Application Context and Request Context in Flask, which Microdot apparently doesn't have:
https://flask.palletsprojects.com/en/2.3.x/appcontext/#stori...
I believe it's the same concept as `g` from flask.
Is this a Mission: Impossible III reference?
Nah, Lysergsäurediethylamid.
Heh, I never realized where the initialism came from. (I had always guessed LySergic acid Diethylamide, but I never felt like that made sense.)
As a german native speaker, this tidbit was actually one of the first bits of info I learnt about the substance.
it's an LSD reference
That's what I thought too, until I wikipedia'd microdot:
https://en.wikipedia.org/wiki/Microdot
Turns out microdot is a tiny format for communicating text/image which seems an apt name for this tiny webserver.
Probably what the LSD format was named after originally.
See also https://mikrodot.bandcamp.com/
It's actually a Phish reference[1]
Yeah, I'm old enough to recall "Purple Microdot" back in the `70s.
https://github.com/nggit/tremolo
Also may be of serious consideration to people looking at microdot, because:
* Pure asyncio only, zero dependencies.
* Ships its own ASGI server, like Sanic. (No juggling uvicorn and gunicorn dependencies).
* Tiny library, feels like Starlette from the glory days.
* streaming responses by default (return stuff, then do processing, return more stuff).
* handles streaming multipart form uploads / streaming downloads, without external dependencies.
* tons of safeguards built in (request/response size limits, bandwidth throttling!) No massive DoS exploit potential found in Starlette/Uvicorn/FastAPI lol.
* the intuitive Sanic-style @on_request + @on_response rather than the complex middleware system in Starlette nowadays
Only 2,500 lines, with IMHO, far more important features than Starlette/FastAPI already baked in.
Another one https://github.com/litestar-org/litestar
The interesting (for me) part about Microdot is it's tested with Micropython. AFAIK tremolo and litestar aren't.
Of serious consideration, eh?
Flask: 64,900 GitHub stars
Starlette: 8,800 GitHub stars
MicroDot: 847 GitHub stars
Tremolo: 6 GitHub stars
https://github.com/encode/starlette
Are we too afraid to consider features and source code now?
I remember when Starlette and FastAPI were both just starting in the double digits. IMO this is 100% a sleeper project based on the qualities above.
every open source project starts with the first star. (sorry for murdering the saying.)
may I remind you of https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/Sw...
> I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.
;)
Absolutely. And reliability and feature-set is not measured by project activity about which people on here seem obsessed.
Better to compare star velocity than total stars
zero yesterday, one today - infinite velocity!
Given the title I really wanted this to be a small and portable graphviz reimplementation...
haha, that's trippy.
But why?
To serve small apps from mycropython compatible microcontrollers, like an ESP32 or an RP2040.
I wast just checking this for creating a small web management interface for an ESP32 light controller and some other sensors.
It’s a no for me dawg