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

[Claus Dietrich <claus.dietrich@xxxxxxxxxx>]

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