Release: serverino - please destroy it.

[Andrea Fontana]

On Tuesday, 10 May 2022 at 08:32:15 UTC, Sebastiaan Koppe wrote:
> On Monday, 9 May 2022 at 20:37:50 UTC, Andrea Fontana wrote:
>> On Monday, 9 May 2022 at 20:08:38 UTC, Sebastiaan Koppe wrote:
>>> As an example, how many requests per second can you manage if 
>>> all requests have to wait 100 msecs?
>>>
>>> For non critical workload you will probably still hit good 
>>> enough performance though.
>>
>> Firstly, it depends on how many workers you have.
>>
>> Then you should consider that a lot of (most?) websites use 
>> php-fpm, that works using the same approach (but php is much 
>> slower than D). The same goes for cgi/fastcgi/scgi and so on.
>>
>> Let's say you have just 20 workers. 100msecs for each request 
>> (a lot of time for my standards, I would say). That means 
>> 20*10 = 200 webpages/s = 720k pages/h. I don't think your 
>> website has so much traffic...
>>
>> And I hope not every request will take 100msecs!
>
> 100msecs is on the upper end for sure, but if you add a 
> database, external service call, etc. it is not uncommon to 
> reach that.

And you can still handle 700k/views per hour with 20 workers!

> The point however, is that the architecture breaks down because 
> it is unable to do work concurrently. Every requests blocks a 
> worker from start to finish.
>
> Unless it is CPU heavy the system will be under utilized. That 
> is not necessarily bad though. The simplicity has something 
> going for it, but it is definitely a tradeoff that you should 
> consider highlighting.

Every server has its own target. BTW, I'm not developing 
serverino to use it as a building block of a CDN.

In real-life projects, I think you can use it without any problem 
for not-huge projects.

You can also put it under a reverse proxy (f.e. nginx), to handle 
just the requests you need to write in D.

> The difference is that with the route uda you can *only* map 
> routes 1:1 exhaustively. With your approach it is up to the 
> programmer to avoid errors. It is also hard to reason about the 
> flow of requests through all those functions, and you have to 
> look at the body of them to determine what will happen.

Sorry I don't follow you: I don't know which framework you're 
using, but if you're using UDA with matches (something like: 
@matchUri("/main") void renderMain(...) { ... }) you still have 
to check all the functions if a request is not handled correctly. 
Or am I missing something?

Using my approach if you want to check which functions escape 
from routing you can just add a catch-all endpoint with low 
priority.

```
@priority(-1000) @endpoint
void wtf(Request r, Output o)
{
       fatal("Request NOT HANDLED: ", r.dump());
}
```

And if a request doesn't match your UDA constraint, how do you 
debug what's wrong with it? I think it's easier to add a 
checkpoint/log on the first lines of your functions body to guess 
why the function is skipped.

In any case if you want to use a different routing strategy it's 
quite easy. I really don't like libraries that force you to use 
their own style/way.

So you can even drop my UDAs and write the app like this. It 
still works:

```
mixin ServerinoMain;

void entry(Request r, Output o)
{
     // Use your routing strategy here
     // ...
     // YourRouter router;
     // router.do(r, "/hello/world", &yourFunction);
     // router.do(r, "/bla", &hello);
}
```

Andrea