[erlang-questions] newbie web-development advice / guidance

Icarus Alive <>
Wed Aug 3 20:40:20 CEST 2011


On Wed, Aug 3, 2011 at 9:50 PM, OvermindDL1 <> wrote:
>
> I am curious, how is ChicagoBoss compared to Nitrogen?

Haven't experienced Nitrogen long enough to make a good objective
comparison. Just that there was something about Nitrogen Records, that
seemed -- verbose and intimidating. Also, found it somewhat difficult
to imagine how that syntax maps to the generated HTML. On the
contrary, I found ErlyDTL very simple, once I saw the CB
video-tutorials on youtube. Also the MVC constructs were a bit easier
for me to follow in case of ChicagoBoss. The admin-interface was
dead-simple. Finally, I found the tutorial for ChicagoBoss to be
short, to-the-point, very simple/lucid and achieved something concrete
I understood. The documentation get me functional quite quickly, and
in fact, there wasn't very much to read. While it might take a lot
more to become an expert, I felt that I could get up-n-running (from
zero) with CB much sooner.

> On Aug 2, 2011 11:31 PM, "Icarus Alive" <> wrote:
>> On Wed, Aug 3, 2011 at 3:54 AM, Benson Wong <> wrote:
>>> Hi,
>>> My background is a web developer (~15 years), done PHP for about 11
>>> years.
>>> So I know it pretty well.
>>> Just starting to learn Erlang. Done lots of javascript (jQuery, node.js,
>>> etc). So a PHP developer, in the Erlang pool here :)
>>> I think an imperative language like PHP would be a lot easier (and more
>>> agile) to build the web app in than Erlang. I would choose erlang if I
>>> need
>>> long lived connections (web sockets, long-poll, etc). Frameworks like
>>> Django
>>> (Python)/Rails (ruby) would also make life easier.
>>> If you want scalability/reliability/performance, add more PHP processes /
>>> servers.
>>> PHP is shared nothing, so it is easy to scale. Just add more. Using Nginx
>>> +
>>> PHP-FPM. Solves a lot of slow request issues.
>>> Put them behind an HTTP load balancer, HAProxy is a very popular choice.
>>> Performance is usually database bound than it is app server bound.
>>> On Fri, Jul 29, 2011 at 6:16 AM, Icarus Alive <>
>>> wrote:
>>>>
>>>> Would appreciate if my thread wasn't hijacked :-)... although gotta
>>>> agree that our scenarios are quite similar.
>>>>
>>>> On Fri, Jul 29, 2011 at 6:31 PM, Banibrata Dutta
>>>> <> wrote:
>>>> > Thanks @Marc, for taking time to reply this this mail.
>>>> > On Fri, Jul 29, 2011 at 5:38 PM, Marc Worrell <> wrote:
>>>> >>
>>>> >> It mostly depends on what kind of web development you want to do.
>>>> >>
>>>> >> Is it more of a mobile application than a publishing web site?
>>>>
>>>> In my case, content characteristics are:
>>>> 1. Always originating from single source
>>>> 2. Always consumed by single user
>>>> 3. Content has short lifetime - once consumed, will be archived
>>>> 4. Each user has several hundreds of content display to her in "newest
>>>> first" fashion
>>>>
>>>> >>
>>>> >> Does is have specific authentication schemes?
>>>> >> Etc. Etc.
>>>> >
>>>> > Honestly, haven't given this enough thought. One of the requirements
>>>> > is
>>>> > to
>>>> > ensure privacy of user data, and that of the interaction. I'm yet to
>>>> > figure
>>>> > out the "how" part.
>>>
>>> Security/Privacy, this is more of an operation and application design
>>> than
>>> it is a Erlang/OTP vs PHP/Ruby/Python+framework.
>>> Generally you'd want to:
>>> * firewalls, no SSH access, web servers are only web servers, ie: only
>>> port
>>> 443 open.
>>> * use cookie based sessions. Don't use HTTP basic authentication.
>>> * Server has controls all access based on the cookie.
>>> * Use HTTPS. Always.
>>> * There are lots of other techniques:
>>> -- use bcrypt for passwords
>>> -- sessions can be limited to one IP address at a time
>>> -- sessions have short expire times (controlled on the server)
>>> -- etc.
>>>
>>>>
>>>> Well in my case it has to be some strong authentication. Storage,
>>>> archival and access has to conform to HIPAA compliance. So we know we
>>>> are dealing with EMR type content.
>>
>> Hi Benson,
>>
>> Really appreciate your descriptive & informative response, especially
>> so for the part on security.
>>
>> My inclination towards Erlang stems from the fact that I was intending
>> to do much of the backend in Erlang as well. The backend does lot of
>> other things than just bridging between FE client request/responses
>> and a DB, s.a. converting content format, managing archival policies,
>> do some data analysis for reporting etc. Maybe some of that via ports.
>>
>> I wish I'd seen your mail few days back, because having tried both
>> Nitrogen and Zotonic, which are I am sure excellent products, I think
>> I've found peace in settling for ChicagoBoss. I found it lot easier to
>> work with, as a beginner, maybe because the FP guts are almost hidden
>> away from sight, and much of the developer/user coding is done in an
>> imperative fashion. Also, I found it's documentation (although quite
>> light) to be simple & just-enough to get me started and get me going.
>>
>> However, I might have to come back to PHP unless I am able to train my
>> team on Erlang. Being a beginner, I find it hard to imagine being a
>> good teacher / coach for rest of the team.
>>
>> Thanks again, everyone, for responding on this thread.
>>



More information about the erlang-questions mailing list