[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feasibility of an async HTTP server engine in Gambas (uvicorn-style) + question about JIT

Le 07.08.2026 10:12, Claus Dietrich a écrit :

Dear Marc

I didn't understand all of your requirements, never needed an async
concept and I don't know uvicorn but like to inform you about my
status:

I developed a flatbed scanner app, which can optionally be remote
controlled through a web interface (must be activated in a GUI
dialog). I realized this with Gambas by writing a gb.net socket based
micro HTTP server. The server is actually encapsulated in a class
(HttpServer.class) while the handling of HTTP request is coordinated
in a module.

To test the possible range of applications with this mini server
concept I wrote an additional demonstrator which hosts a complete
webpage. Both applications can be downloaded here:

https://magentacloud.de/s/XsSZemWSgeagkPG

I already thought about breaking this HTTP server concept down into
layers respectively further objects/methods but I hesitated to do this
because I didn't know what would really be needed/reasonable/efficient
for that. It would be great if someone with more web experience could
provide an according advanced concept for the Gambas community and
wraps all needed functionalities (including log-in/auth, cookies etc.)
in a class or component.

Best regards

Claus

Am 07.08.26 um 00:05 schrieb alarch@xxxxxxxxx:

Hello everyone,
I've been using Gambas for years for internal tools and server administration scripts, and I'm currently thinking about a project idea I'd like your opinion on.
Many Gambas users (myself included) end up relying on PHP for anything web-related, mostly by default rather than by choice. I was wondering whether it would be feasible to build a Gambas-native equivalent of Python's uvicorn — i.e. a standalone application server capable of handling HTTP connections directly (not through CGI/FastCGI), using an event-driven model built on gb.net's Socket class and its ReadyForRead/ReadyForWrite events. 

The rough architecture I have in mind has three layers:
1. Transport layer: a Socket-based listener handling multiple connections, doing HTTP/1.1 parsing (request line, headers, Content-Length/chunked body, keep-alive) by hand. This is clearly the hardest part to get right, and the one I'd want to validate first.
2. Application contract: a stable interface (Request/Response objects) that application code implements — something like a minimal ASGI/WSGI equivalent, so that once it's defined, application developers don't need to touch the transport layer at all.
3. Routing + middleware: routes table, static file serving, basic logging/auth hooks — the layer that would make it feel like an actual framework rather than a raw socket server.
For concurrency, my current thinking is a single event-loop process per core (à la Node.js/asyncio single worker), with multiple processes behind a reverse proxy (HAProxy/nginx) for multi-core scaling, since Gambas doesn't have true lightweight coroutines.
Before going further, I have two questions for people more familiar with the internals:
Has anyone already attempted something like this (a persistent event-driven HTTP server in pure Gambas, not CGI-based)? I know gb.web exists but as far as I understand it's oriented towards the CGI/FastCGI model rather than a standalone server process.
About JIT compilation: I recall reading that Benoît implemented some form of JIT in the Gambas runtime. Is this JIT exposed or usable from application code at all, specifically, is there any way to generate and execute code dynamically at runtime (similar to what Smarty/Jinja2 do when compiling templates into native code)?
Or is it strictly an internal optimization of gbx3, with no way to leverage it for dynamic codegen from a Gambas application?
If dynamic execution isn't possible, I'll go with a classic interpreted template engine (walking a parsed node tree), which works fine but is obviously slower.
Any feedback — even "this is a bad idea because X" — would be very welcome. I'd rather know the real constraints now than discover them halfway through. 

Thanks in advance,

Marc




Dear Claus,

Thank you again for sharing this.
I went through the HttpServer.class in detail and I'm impressed by how much ground it already covers (language negotiation, cookies, MIME type detection for a dozen formats...). That's a lot of tedious groundwork already done correctly.
I tried to think through how this concept would extend to my own use case: a small personal ERP/monitoring tool, potentially with several browser tabs open at once, and pages backed by a database with credentials. That led me to a few open design questions rather than anything wrong with your code, more "what would need to change for a different use case" than a review:
1. Since request data (GetURL, cookies, POST parameters...) is stored on the server instance itself, I wonder what would happen with two near-simultaneous requests from different clients (or even two tabs from the same browser): would there be a risk of one request's data overwriting another's before the response is sent? I started sketching a version where each connection gets its own small Request object instead, but I'm not sure if that's overengineering for typical use cases or a real necessity.
2. For serving files directly from $GetURL (like the CSS/image/JS branches), since the URL comes straight from the client, I was wondering whether it's worth restricting it to a fixed subdirectory (something like rejecting any URL containing ".."). Mostly thinking of cases where the app also has, say, a config file with credentials sitting nearby.
2. I noticed Content-Length isn't sent in the response headers, and the connection always closes afterwards. I assume this was a deliberate simplification given HTTP/1.0-style behavior? I ask because I think it would make asset-heavy pages (many small CSS/JS/image requests) noticeably slower over a real network compared to keep-alive, so I'm curious whether that's already on your radar as a possible next step.
I'd genuinely like to try building a small proof-of-concept on top of your work, addressing these three points (isolated per-connection request objects, restricted file serving path, optional keep-alive), and share it back with the list so we can compare approaches. Would that be alright with you, or would you rather handle it differently? 

Best regards,
Marc