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

[Benoît Minisini <benoit.minisini@xxxxxxxxxxxxxxxx>]

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

--
Benoît Minisini.