[erlang-questions] Erlang http servers
Tue Oct 2 19:37:14 CEST 2012
On 10/02/2012 05:52 PM, Serge Aleynikov wrote:
> I agree with Joe that having a design of the HTTP server architecture
> included in OTP that would offer standardized internal API and allow
> developers to either replace selected functionality via providing
> callback modules or swap the HTTP servers easily would be a great plus.
This wouldn't have helped Cowboy, as one of the biggest difference is
the use of binary instead of strings.
There's another solution, which is to write wrappers for other APIs, for
example mochicow allows Mochiweb applications to use Cowboy under the
hood without having to change their code. This means that the switch can
be progressive instead of being brutal like a direct code switch.
> Diversity is good, but at some point it creates a burden for the user
> who needs to make a selection of an HTTP server for his project.
> Instead of solving the application-related problem, now the task becomes
> studying several implementations to see which one offers a feature-set
> best suited for the problem being solved, and the answer to that
> question is not always straightforward.
Erlang is wonderful in that it allows you to write your application 100%
HTTP-free, and then write another application for the HTTP layer that
will be a thin layer running alongside your application. The
communication layer can be separate from the business logic.
If you go that way then your application's code isn't dependent on the
transports used at all, and you can easily switch servers, change
protocols, serialization formats or anything in your HTTP layer without
this impacting your application in any way.
For example, when SPDY support will be added to Cowboy, only the HTTP
layer will require a change to make use of it (start_http, which only
does HTTP, can be replaced by start_spdy, which does SPDY or HTTP
depending on client capabilities). The application behind it shouldn't
have to care about that.
> Perhaps a good initiative from the OTP team would be to spec out the
> open architecture of an HTTP server and welcome feedback from authors of
> current http libraries, so that the successor of inets would be flexible
> enough to accommodate building light-weight and heavy-weight HTTP
> servers based on the supported code base included in OTP? This would
> also open a possibility of diversity for library writers
> replacing/enhancing parts to suit their needs.
More importantly, do people actually want that?
More information about the erlang-questions