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.