[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 19:56, Benoît Minisini a écrit :

Le 07/08/2026 à 00:05, alarch@xxxxxxxxx a écrit :

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.
I think that implementing an HTTP server in Gambas can be a great project to do. 

Note that you already have the 'gb.httpd' component that transforms
your project into an HTTP server as soon as you check it.


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. 

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



As all these things an internal API of your HTTP server or an external
one? I mean: is the application logic implemented inside the HTTP
server by extending it, or by external processes?
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. 

Its name is 'gb.web.gui', and I admit it's a curious implementation of
web applications that I have never seen anywhere else. But I think it
makes its job.
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. 



I'm not sure to understand what you mean. But 'gb.highlight'
implements syntax highlighging by transforming a syntax description
file into a Gambas component that is loaded dynamically, and that is
JIT optimized.
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 Benoît,

Thank you very much, this is extremely helpful.
I wasn't aware of gb.httpd at all — I'll look into its documentation before going any further, since it might already solve the transport layer I was planning to build from scratch. That could save me a lot of work, or at least clarify what's already handled versus what would still need to be designed on top of it.
To answer your question: I was thinking of an internal architecture — the application logic would run inside the same process as the HTTP server, by implementing a stable interface (Request in, Response out) rather than being dispatched to external processes. My use case is a small personal application (not a multi-tenant platform), so a single process handling both the server and the application logic seemed the simplest and most maintainable approach, with horizontal scaling (if ever needed) handled by running multiple identical processes behind a reverse proxy rather than splitting server and application logic into separate processes.
Regarding gb.highlight: that's a very interesting pointer, thank you. If I understand correctly, it generates a full Gambas component from a syntax description file and loads it dynamically, benefiting from JIT optimization at that point. I'll try to look at how it generates that component internally — it might be a usable (if heavier than a simple eval) path for compiling templates into something faster than a pure interpreted tree-walker, even if it's clearly not designed for that use case originally.
I'll report back once I've had a chance to look at gb.httpd — this changes my plan quite a bit and I'd rather understand what's already there before designing anything new. 

Best regards,
Marc