[Laszlo-dev] For your review: Laszlo Database API spec

[Max Carlson]

Hi Duc,

Thank you for your reply.  Let me say that I share your concerns - I 
have also been the victim of tightly coupled web applications.  It's no 
fun maintaining an app where the presentation layer, model and 
controller are intertwined.  I'll try and address your concerns.  Tell
me how I do!

First, OpenLaszlo provides a nice separation of model and view with the
data binding APIs.  This makes it easy to keep the presentation separate
from the underlying data model.  This mechanism provides one degree of
separation.

Since Laszlo applications are stateful, it's possible to put most of the
controller in the OpenLaszlo application.  For example, a shopping cart
can be entirely maintained on the client, only requiring a connection to
the server for checkout and credit-card validation steps.  This blurs
the separation between model and controller.

Currently, developers have to spec and build their own REST APIs from
scratch.  A common need developers have is to communicate with a SQL
database.  The simplest way to do this is to generate SQL in the client
and send it to a lightweight service that converts the database query
results into XML.  This is bad because any changes to the database
schema will require changes to the client application - there is no
clean separation.  As you know, writing a good, generalized API can be a
lot of work.

To contrast with this approach, the database API does not execute SQL
directly.  All SQL queries are generated by the server, based on
abstract method calls and commands sent from the client.  The server API
provides access control and hooks for business logic such as validation.
  This is very different from talking directly to the database, and as 
such provides a clean separation.

The database API spec is inspired by the recent rise of frameworks that
are built around the Active Record pattern, in particular.Ruby on Rails
and Cake for PHP.  It is a very thin layer, where many assumptions are
made based on convention.  This approach required minimal effort on the
part of the developer, while still providing a clean separation of MVC
layers.

The long-term goal is to create a special dataset that automatically and
transparently communicates changes to the back end.  A developer will be
able to install the server-side component, specify access control, and
program their application in Laszlo without worrying about the
underlying details of the REST protocol.  Because it's using REST, it
will work with SOLO deployments.

Here are some links related to the ActiveRecord pattern, and Ruby, Java 
and PHP implementations:
http://www.martinfowler.com/eaaCatalog/activeRecord.html
http://ar.rubyonrails.com/
http://www.castleproject.org/index.php/ActiveRecord
http://cakephp.org/

This blog entry's comments provide a good read about ActiveRecord vs. 
alternative methods:
http://www.37signals.com/svn/archives/000606.php

The comments here are also make for an interesting read:
http://digg.com/programming/CakePHP_-_A_PHP_Rails_competitor

I'll update the spec with more of this background info when I get a 
chance.  Let me know what you think!

Regards,
Max Carlson
OpenLaszlo

phuduc nguyen wrote:
> Hi Max,
> 
> It seems like you've put quite a bit of thought and
> work into this spec. However, I think providing such
> an API is a step in the wrong direction. Forgive me if
> this sounds pompous, but I strongly disagree with
> making DB dips from the GUI. 
> 
> This reminds me of my first job as a web developer
> where I had to maintain a preexisting webapp. All the
> code existed in one layer. The HTML was mixed with
> Perl/CGI and SQL. All the business logic,
> persistence/DB access, connection pooling, and GUI was
> woven together. It was a nightmare to maintain and add
> new functionality. 
> 
> If I've read the spec correctly, then you're proposing
> an API that would enable DB access from the GUI. This
> means you're putting GUI, business logic, and DB
> access into one layer. This is effectively a 2 tiered
> application where the 2nd tier would be some form of
> remote data source (DB for example). From an
> architectural and design perspective, 2 tiered apps do
> not provide enough layers of separation to promote
> flexibility and evolution of an application. What
> happens when you want to change just the look and feel
> of the app? You'll increase your chances of
> introducing bugs and changes to the business logic
> because the layers have not been separated with clear
> lines of responsibilities. 
> 
> These days, most commercial webapps have at least 3
> tiers if not 5 or 6. I'm not talking about blogs or
> homepages where you show your family, your dog Fido
> and then talk about what you did last Tuesday. This is
> in the context of real world apps that are critical to
> the success of an organization. Could you imagine
> trying to maintain a webapp the size of an amazon.com
> with a 2-tiered architecture? It just doesn't make a
> lot of sense. I'd love to see OpenLaszlo gain more
> momentum and acceptance among the developer community,
> but such API's would not add progression to the
> platform. 
> 
> 
> thanks,
> Duc
> 
> 
> 
> 
> --- Max Carlson <max at laszlosystems.com> wrote:
> 
> 
>>Hi,
>>
>>I'd like your feedback on the attached spec.  The
>>notion is to have a 
>>common REST API for Laszlo to read form and
>>communicate changes to 
>>remote data sources.  The plan is to create a
>>special Laszlo dataset 
>>that knows how to speak this protocol and can
>>automatically sync with 
>>the back-end.  The first implementation will likely
>>be in PHP and 
>>support SQL databases such as MySQL.  Later
>>implementations could be 
>>built on other platforms - I'd love to see one built
>>on Rails.  It's 
>>important to note that the protocol is designed to
>>be general enough to 
>>work with any data source that has sets of records -
>>it's not 
>>necessarily tied to SQL databases.  I look forward
>>to hearing your 
>>thoughts and feedback!
>>
>>Regards,
>>Max Carlson
>>OpenLaszlo
>>
>>>_______________________________________________
>>
>>Laszlo-dev mailing list
>>Laszlo-dev at openlaszlo.org
>>
> 
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>