tags:

views:

346

answers:

3

I have a Rails webapp [deployed on Heroku] which makes a series of HTTP calls to other sites on a repeated basis, using Heroku's rake:cron feature. The current situation isn't ideal; the rake:cron process is executed in a single thread, which means HTTP calls are made sequentially; which means in turn that there's a long time between calls to the same site [typically 2 mins].

I'd like to execute this process in parallel, and reduce the time between calls to 10 secs. Having seen Kevin Smith's 'Erlang in Practice' I'm sold on the idea of using Erlang as a replacement backend. What I'm trying to figure out [given Damien Katz's comments], is whether I should a) re-write the entire webapp in Erlang, front end and all or b) maintain a split structure, with a Rails frontend / Erlang backend.

I like the idea of using a 100% Erlang stack for the project; I'll need to use some kind of Erlang web framework [Nitrogen ? Erlyweb ?]; I'm concerned they're not mature enough and I'll spend my time bogged down on the web part of the project with them.

Anyone any views ? Thanks.

+1  A: 

What's the actual impact on your visitors (of the two-minute interval between HTTP backend calls)?

If there isn't much of a difference, I'd say this sounds like premature optimization and that you'd be much better off skipping Erlang for now.

fig
The app is a stock trading app. With a two- minute interval it works, but it's more 'interesting' than real utility. Real utility == interval inside 10 secs. So maybe I should rephrase the question: I *need* to rewrite the backend in Erlang for it to work; should I redo the front in Erlang or keep it in Rails ?
Justin
Hmm, gotcha. I'd leave the front-end in Rails. You get access to so many useful gems/plugins, in addition to all the goodness of Rails itself. Erlang's great but I don't think it competes yet with all the ease-of-development gains you get with Rails.
fig
A: 

It depends. How much Erlang do you know? How much code have you already written? How much project experience do you have? Is this for work or for fun?

Rewriting projects from scratch is often a recipe for disaster, especially if you are trying to learn a new language along the way. It seems to me like you would not be asking this question if you were already fluent in both languages, in which case I would recommend that you just stick to Ruby if it's a work project.

I disagree with the above poster that changing the language is a premature optimization, if it is necessary. Changing the language is a big deal. It can't be done at the last minute. However, I would probably not change the language at all for the reason you outlined. If you don't have any other reasons than performance for switching, you should probably just look at multi-threading in Ruby or some other optimization.

Jørgen Fogh
I didn't say changing the language is always premature optimization. lol. So you're saying the same thing as I did, which is that *in this case* it sounds like prem. optimization. :D
fig
+1  A: 

The two previous posters have pretty much covered they philosophical aspects of your question. So I'll answer the framework maturity/getting bogged down part of your question.

In the event that you decide you do want to rewrite the webapp in erlang for whatever reason then I wouldn't be too concerned about the framework slowing you down. Both erlyweb and nitrogen are already feature complete enough that you can work pretty quickly with them. I've developed a fairly complex agile project management app in nitrogen and found it to be quite intuitive and not really lacking in features that I needed. A few hours in the evenings and a few weeks later and I had a working app up and running.

As to which one to use that depends on the type of app you want to build.

Nitrogen's target is extremely dyamic web applications. Most of the page is rendered using javascript and it is highly event driven.

ErlyWeb is more suited to a site where the content is the primary focus less so than a rich client type of application. It uses the MVC style of architecure.

Good luck on whatever you decide.

Jeremy Wall