Question

I’m trying to understand how one should design middlewares for EWGI compatibility. Given that there is no EWGI compliant web server yet, I can only ask for your opinion.

If I understand the spec. correctly, a middleware receives an #ewgi_context{} record as input, and returns another record of the same type.

Question is, is the middleware going to be called twice as in django, or is it supposed to call the rest of the middlewares on its own recursively?

Also, is there any proposed way for a middleware to notify the rest of the middlewares that its result is supposedly the final response? (e.g. the file-serving middleware hit a file, so there is no point calling the view middleware). As the result of my view is a context record, how should the rest of the middlewares (or the server) figure out it is the final response?

Answer 1

Given that there is no EWGI compliant web server yet, I can only ask for your opinion

There’s no need EWGI compliant web server to exist because it’s the EWGI’s role to unify the access to and from different web server. That’s the core idea of EWGI.

On the other hand if you meant “EWGI compliant web framework”, there actually are two (or more?) web frameworks that supports EWGI. These are Erlang Web and BeepBeep.

or is it supposed to call the rest of the middlewares on its own recursively?

The middlewares are supposed to call each other in a recursive manner, so it’s the middleware’s role to decide what to do next.

Also, is there any proposed way for a middleware to notify the rest of the middlewares that its result is supposedly the final response

To answer your last question, I think that because middlewares call each other recursively the simplest way to achieve this would be not to call other middlewares if the answer is final, and return #ewgi_context{} record to the ewgi layer.