RESTful Services with Erlang and Yaws

March 31st, 2008  |  Published in erlang, REST, services, yaws  |  7 Comments  |  Bookmark on

Today published a new article I’ve written entitled “RESTful Services with Erlang and Yaws.” Stefan Tilkov recently asked me if I had anything to contribute to InfoQ, and I thought an article on that topic might be interesting, as I hadn’t before seen anything covering REST and Erlang together.

I think it’s one of those articles that could be much, much longer and far more detailed if space (and time) permitted, but hopefully there’s enough there to whet your appetite if you’re considering developing RESTful web services in Erlang. I really can’t say enough good things about using Erlang and Yaws for this purpose — it’s quite a solid platform.

I’ll be giving a talk on the same topic at both JAOO Brisbane and JAOO Sydney at the end of May and beginning of June, respectively.


  1. David Greco says:

    April 1st, 2008 at 2:42 am (#)

    Very nice and helpful article, a good opportunity for me for increasing my Erlang knowledge.
    Thanks Steve.

    P.S. I’m interested in knowing also your opinion on the Scala language, it seems to me an interesting language trying to get the best from the functional and the OO world.

  2. James Abley says:

    April 1st, 2008 at 10:07 am (#)


    Nice article. As per Sam Ruby’s comment about ETag support; is it worth a follow-up article to cover that?

  3. steve says:

    April 1st, 2008 at 10:25 am (#)

    James: thanks.

    Regarding Sam Ruby’s Etags comment, the issue, as always, comes down to article detail and length. It just can’t cover everything. For example, I didn’t cover handling POST data, either. Rather than publishing a new article for such things, I’ll probably just follow up here on my blog.

  4. Darach says:

    April 1st, 2008 at 3:16 pm (#)

    Sweet article Steve. But how does the memory footprint, CPU utilization, and so on compare to, say, RESTful services deployed on other RESTful stacks? It would be interesting to see this benchmark reproduced and compared with other environments deployed on the same infrastructure.

  5. steve says:

    April 2nd, 2008 at 12:11 am (#)

    Darach: thanks. As for memory, CPU, etc., since the article instructs you on how to build such services, why not build some and measure for yourself? ;-)

    In all seriousness, what you’re asking about really depends on what you’re building. Getting the details you’re asking about would require building the services multiple ways, presumably in different languages with different frameworks, to be able to compare everything, and I don’t have time to do that. I did some benchmarking awhile back based on the particulars of my application that proved this is the best direction for me, but YMMV.

  6. Darach says:

    April 2nd, 2008 at 7:56 am (#)

    I might have to do just that Steve! In my case, I suspect Yaws will be lighter-weight than apache for my application. Of course, I never leave a suspicion/hunch unmeasured! :)

    The Apache vs Yaws results are impressive and show Erlang/Yaws to be resilient under very hostile conditions. But IMHO, the results are incomplete. The practical utility of this impressive scalability/resilience is latency limited. From my quick measurements: 800KB/s with 80K sessions is 10 bytes per second per session. So, latency degrades considerably as load increases and is the limiting factor w.r.t utility here.

    This blog entry (~20KB now) would take 30 minutes to display under these conditions.

    The benchmark results would be much more widely acceptable and quotable if this and other practical limitations were documented. As it stands they can easily be misinterpreted.

  7. steve says:

    April 2nd, 2008 at 8:04 am (#)

    Darach: yes, fully agreed. That’s why my article mentions the “Apache vs. Yaws” graphs more as a curiosity than anything else. It would be nice if there were a more rigorous and complete set of tests, better documented as well, that showed the strengths and weaknesses of each web server in more detail.