[erlang-questions] Erlang http servers
Tue Oct 2 20:09:38 CEST 2012
I would even go so far as to propose that almost every single Erlang
project, for the foreseeable future will want an HTTP service. I would
even extend this to "most project in any realm in any language."
Reason: Even if you're not providing an external service, having a
web-status console, admin or REST-based health/monitoring/whatever port has
a whole lot of value.
Right now, if you want external services you have to meld
server+protocol+client. The HTTP's strongest suit is that, just like
and it's easy.
Would I prefer a world built on client-side(browser!) Erlang, a
length-prefixed binary protocol and real sockets (instead of websocket
silliness)? Hell yes. But we don't have that, and likely won't anytime
Having too many options is a Bad Thing<tm>, IMO. Erlang is already enough
of a 'big scary monster in the dark' for a lot of people. If we had a
unified, documented, packaged and turnkey solution withing the stdlib so
that users could 'drop in and go' it would increase uptake as people at
least explored it. The are more web-coders than ever, many with just
enough knowledge to be dangerous. Apple vs PC back in the day --- snag all
of the low-hanging cheap fruit of PC clones instead of insisting on the
white-ivory-tower and then achieve market dominance (which is then yours to
lose/squander at your leisure... :)
On Tue, Oct 2, 2012 at 10:37 AM, Loïc Hoguin <> wrote:
> 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.
> It doesn't!
> > 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?
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions