Erlang for web-developers
Tue Aug 29 06:05:51 CEST 2006
On Aug 29, 2006, at 10:55 AM, Andrés Valenciano wrote:
> Dmitrii Dimandt wrote:
>> I think that in order to sell Erlang to web developers, we need to
>> exactly on the things that can be "branched off". Because telecom
>> is interesting, but it also is scary. What else can we lure web
>> developers with?
> I am new guy in this Erlang block after years of Java, some Python
> and a
> year of Ruby ( and others before those 3).
> I am very interested in Erlang for web development but at this point
> some things are missing for me, those are the more "trivial" things
> PDF generation, charts, all these other features that some web
> applications needs that are not as interesting as all the Erlang
> strengths but some times needed.
This does add to the erlang sales pitch problem.
I think the best way to approach this issue is to think of erlang as
your central command and control center. You can spawn an external
process to handle non-erlang tools like full text search, image
manipulation, SMS gateway, etc... You can do this cheap and easy by
just spawning an external process (think of the CGI paradigm) or have
the extrenal process connect back to an erlang socket server and keep
the external resource alive (think FCGI). Once you see how easy it
is to create ad-hoc erlang socket servers to wrapper external tools,
I think your fears of not having feature X as a native erlang lib
The sales pitch for this structure is to say you can choose best of
breed for any feature you might encounter as opposed to being stuck
with the "Cold Fusion choice or much harder choice" for feature X.
I am taking this approach for my full text search needs by using
lucene (Java). I get the best of both tools with very little trouble
for using multiple technologies.
I am also using the erlang custom socket server approach for a custom
C++ server which needs to handle authentication and authorization.
My C++ deamon is a fast single threaded socket relay server which
could get its auth info via a call to MySQL which would be a shared
data source along with the erlang web app. Although relying on a
central db is a nice tried and true method for shared auth info, it
means that my simple C++ deamon must add threaded handlers for making
the MySQL calls...if not, my fast socket relay will bottleneck all
the existing packets for existing connections while it handles auth
for each new connection. My solution is to let the C++ deamon
connect to a custom auth server running in the same erlang vm as my
yaws web app. This gives me much faster access to the auth info than
making a SQL query and its a fast enough solution that I don't need
to introduce threading in my C++ deamon.
The reason for elaborating on this example is to show that any IT
solution which gets complex enough should make best of breed
choices. There exists a "one language must have it all" approach
which makes many decision makers feel comfortable. I think this
"comfort" is overstated and limits your horizon when adding
unforeseen new features.
> For example, I am in the starting process for a new project (in my day
> job), a web project, that has a SMS related service and I was really
> excited about it because I thought I could use Erlang there but then
> this other guy with Cold Fusion experience wants to use that
> product for
> the project, which gives the web server, the not-so-interesting things
> like PDF, Flash, etc and an SMPP implementation all in the same
> Is that one a lost battle in my case?
More information about the erlang-questions