From: Lawrence Statton <lawre...@cluon.com>
To: beginners@perl.org
Sent: Saturday, September 17, 2011 2:10 PM
Subject: Re: website vs web app

On 09/16/2011 06:10 PM, Rajeev Prasad wrote:
> why do i need a web app? becuase of size of my project? I mean if it is going 
> to be  a very big website with lot of pages and tables etc. should i have a 
> webapp?
>   apache and cgi wont cut it? (alongwith other technologies used commonly in 
>websites)

What do you mean by "web app"?  The most common definition of that concept is 
an "application with an exposed HTTP interface" - and you need one if you 
choose to offer one.  If you don't want to offer an app over the web, you don't 
need one.

Now -- I have one client who chooses to offer two different "aspects" of the 
same back end data -- a "website" variant designed for humans using browsers, 
and a "webapp" variant tailored to developers who want a more "machine 
friendly" source of the data, and, in fact, the "website" instance of Apache 
uses the same "webapp" server that outside clients use.

This has a certain architectural charm - and most importantly allows to totally 
disjoint teams to maintain the two disparate code bases ( the backend is all 
DBIx::Class and XML::LibXML, while the front-end is more LibXML and a bunch of 
Mason - having been converted from a giant mess of java and XSLT)

================================
 
choosing to reply to Statton's email:
 
"web app services" does make a whole lot more sense then just saying web-app. I 
have seen many people/perl-website for catalyst/books on this subject, just 
calling it web app, rather then web app services. (I think IBM call theirs web 
services, which is more meaningful term).
 
so once the distinction is set, original question is not very useful. as some 
people may be wanting to deal with a website's data dished out as services over 
HTTP (API which uses HTTP), rather than scraping the web-page for information.
 
if we have data in database and we can process it using sql why cant we just 
offer access to that data directly - with all security and business logic 
builtin? is this not the age old issue of how to store and offer data, for 
which databases were invented? are we just re-inventing the wheel? adding 
another complex code on top of many layers of code?
 
have i totally missed the point here?
thx.

Reply via email to