[erlang-questions] web framework, db, architecture query, with requirements

Icarus Alive <>
Mon Feb 7 17:26:39 CET 2011


On Mon, Feb 7, 2011 at 8:11 PM, Alex Arnon <> wrote:
> A possibly off-topic question: why VoltDB, and while we're there, why are
> its requirements a problem?

Good question. The worry (not so much of a problem) is completely
non-technical :-).
64-bit requirement means that the AWS EC2 'Small Instance' can't be
used as the starting point, which is a 32-bit instance.
For how I intend to sell my ware eventually, this does impact my
ability to offer a competitive / attractive price.

> On Mon, Feb 7, 2011 at 4:01 PM, Icarus Alive <> wrote:
>>
>> Posted a question on Stackoverflow here: http://bit.ly/f3TIuo
>> but this isn't exactly a cross-post, rather an Erlang specific
>> extention of same :-) ... (to avoid any Erlang/Python religious wars,
>> although Stackoverflow is pretty good in preventing such wars, from
>> what I've seen).
>>
>> While my question there has a more generic question on which way I
>> should be heading, i.e. Erlang or Python, I admit that my limited
>> experience with Functional programming, and almost 12yrs history of
>> doing OO & Procedural programming in imperative languages, my
>> familiarity with Python is slightly higher, though love elegance of
>> Erlang. The challenge is in understanding slightly more involved /
>> complex constructs of Erlang. Anyhow, my query here to seek
>> community's view on what might be the ideal route using Erlang/OTP and
>> Erlang based Web-frameworks, given the following requirements.
>>
>> Here are my requirements --
>>
>> 1. Web2.0 (i.e. interactive AJAXy) service, but with a parallel access
>> via mobile web as well.
>> 2. Application will need to do things like initiate outbound
>> voice-calls, send/receive SMS (think Twilio) etc.
>> 3. Application will make lot of short .flv / .3gp videos (think vimio
>> mini), which are not mass-appeal videos (e.g. baby's 1st walk video
>> shared with grandparents, so 1 uploader, at max 3-4 diff viewers and
>> 3-4 views in all, so CDN is pointless -- I think).
>> 4. There will be some video/audio transcoding (mostly ffmpeg type)
>> 5. Application will need to show trendlines and some charts etc.
>> (think popularity alerts / ranks)
>> 6. Overall, should be easy to learn, easy to maintain, has good
>> community support -- documentation / tutorials / screencasts &
>> active-development
>> 7. While performance is not the top-most item on my priority-list, it
>> is definitely a parameter, including memory-footprint, as I plan to
>> run this on cloud-infra, and every MB counts.
>> 8. While many people tell me to think of scaling later, but I think if
>> one can spend a little time thinking about it early one, what's the
>> harm. Later changes are costly.
>>
>> The frameworks & key-components that I am considering after reading
>> various comparisons are:-
>>
>> Option-1::
>> 1) Backend comprising of :
>>    a) RESTful App-engine:
>>        (i) Webmachine (communicating data w/ FE via JSON), or
>>        (ii) Nitrogen
>>    b) Database engine:
>>        (i) some distributed/scalable/highly-reliable (cloud-friendly)
>> database engine (??), or
>>        (ii) VoltDB (though it's main memory requirement, 64-bit
>> requirement and official support for CentOS5.4 only, is a bit
>> worrying)
>> 2) Frontend based on: jQuery (for regular internet thick-client users)
>> / jQuery-mobile (for mobile-web users)
>>
>> That choice is driven by need to push rendering / non core-IP
>> computation to the browser as much as possible & lighten the load on
>> server, although I wonder how well it would work for the mobile-web
>> users!
>>
>> PS> Completely understand that the above is probably a
>> much-too-complex for an Erlang (& web-dev) newbie to target. But,
>> that's the ultimate target, I am happy to take the right approach,
>> right tools, right frameworks and keep taking baby-steps towards my
>> goal.
>>
>> Some advice / guidance on what choices & why, I could make.
>>
>> TIA,
>> ~i++


More information about the erlang-questions mailing list