Web Application on Erlang: So Far, So Good, …
As a quick recap, I’m building a lightweight server side custom framework which focuses mainly on handling JSON service requests. This, combined with Mnesia, is our MC stack (Model - Controller). The client browser will be fully in charge of the ‘V’iew layer of the app.
(See our post Why Erlang ? for more information).
A stable version of the core has been finished a week ago. In brief, a request hits the server, Nginx proxies it to Mochiweb which starts a new process.
At this point the framework converts the posted data (JSON) to a native Erlang structure. We check if the request contains one or more services and, based on their name (=:= module), we spawn processes accordingly.
As you may have noticed, in order to save some http requests and to use the full power of our server, the client can ask for an array of services.
i.e. : Let’s imagine you are building a screen which is divided into multiple small independent functional parts : your preferences, your status, your personal info, whatever …, you have the choice to wrap all those service calls into one JSON and the framework will happily process those in parallel … fine isn’t?
At this stage of development, and provided that the DB is not fully populated, if I make a comparison with other developments I’ve done using other languages/architectures, my global feeling is : SPEED.
Whenever I find myself in the situation of using a ‘map’ function and depending on the computation weight on each element, I’m parallelizing the operation (pmap).
Coupled with PURE for the rendering at the client side, we aim to end up with a highly responsive application.
The job now is to continue on that track and make the whole thing even more flexible.
One of my concern when choosing Erlang was the lack of libraries compared to other languages such as Ruby. However, I found relatively easy to develop, from scratch, a mail module responsible to dynamically build messages to be send to one or more addresses (via Postfix) and a ‘captcha’ system.
Soon, I will say a little bit more about those two points and will also describe how to quickly set up an Ubuntu server running Erlang and friends.
Stay tuned
Have you taken a look at CouchDB? That project is also written Erlang, and parses/stores data in JSON.
Any particular reason not to use erlyweb? If so, could you please share it
@Tapwater
We had a close look at CouchDB a few months ago. The project seemed really appealing but was only at an early alpha stage at that time.
The API is entirely based on http REST (which is a good idea, IMO), but when using Erlang, having the possibility to natively speak with Mnesia (structure) is a real plus.
We have thought our model with care and ended up with a kind of ‘hybrid’ relational-document architecture. Anyway, we’ll still keep a eye on CouchDB.
@Abhijith
Regarding Erlyweb, to be honest, I didn’t really try it. The explanation is simple : I was not looking for a full features framework à la Rails-Django.
In Ruby I would certainly have chosen Merb, probably Webpy in Python, and in Erlang I found the Mochiweb toolset really handy to start with a simple and efficient app server.
Here is a brief extract of our decision-making process - We consider that the client browser has an active role to play in a distributed system (… did I mention Google Chrome ? …) : in our case, to be entirely responsible for the ‘View’ part of the app. The direct consequence : we don’t need (99%) to transform HTML at server level and thus we can eliminate this requirement of our list when looking for a solution. -
Having said that, I’m sure Erlyweb has a lot to offer when it comes to web development and represents a solid alternative to Rails and Co.
CouchDB should have a native Erlang API. In fact, there’s some discussion in their mailing list about it today. For now, you can just call some couch_http functions to get native speak.
That being said, Couch didn’t work for me because of the filtering that I needed done. Currently, it’s difficult to have dynamic queries sent to Couch and have its views handle them efficiently. Mnesia is proving to be a bit more adept at this task. Couch is perfect for the amorphous data that needs to be stored, though, so I’m torn… Probably staying with Mnesia for now, with one eye still on CouchDB.
Mochiweb behind Nginx indeed kicks ass. It’s scary fast.
What json lib are you using? There’s one I found in ecouch that’s kind of a pain, but the strings are in binary, which is nice.
I will take a look at Pure, but Dojo with Django-like templates is working now.
Good luck, guys. Sounds like you’re on a great path.
Cheers,
BA
Guys, guys, guys… What the hell is this fabulous world of “clouds”, “erlangs”, “rubies” and elf-like nomenclature? I remember those days of crude ASP pages for some Insight and Expenses applications. And what about the spaghetti javascript for the “gastos” VISA – really done from scratch? Wasn’t all invented with the eventing JS objects plugged with XSL thing + XML services?????? Oh là là! Ça avance, quoi!
Hughes: this is really cool! (Let’s have some beers some day to discuss more about SciTE and great rare movies!)
Greetings from Valencia!
Luis
@boorad
We are using the mochijson2 (Mochiweb) module decode and encode functions to convert the data in and out.
The module is optimized and the json data is decoded into a structure where keys and values are binaries.
In order to ease the use of this structure I’ve developed some useful functions like the usual set_, get_ and delete_value(Path, Struct) but also extend(S, Structs) and withdraw(S, Structs).
Those two, respectively, extend(update + add) or withdraw(delete key pairs) one structure with one or more other(s), returning a new modified struct.
@Luis
Great to ear from you Luis
Indeed, the Web is moving, waving, swelling, exploding, erupting, … it’s alive.
(speak to you really soon)
[...] Unobtrusive JavaScript Template Engine for HTMLRating: ★ ★ ★ ★ ★ Web Application on Erlang: So Far, So Good, … | BeeBuzzWe are building our web application BeeLit (SaaS) on Erlang and so far, the adventure runs [...]