Re: Front-end Driven Applications

On 10/3/2014 4:03 PM, Booth Martin wrote:

This discussion is interesting and is broadening my understanding, which
I do appreciate.

However I do not understand how a front-end can be expected to ignore
the capabilities and requirements of the back-end? I am missing a piece
of that puzzle. If the front-end displays today's temperature in London
then connecting it to a back-end of shipping dates is not going to
work. To my thinking, that front-end has to establish that it desires
to know the temperature in London and the back-end has to furnish that
information for the process to be useful.

My own guess would be that for success, the back-end has to establish
the rules of the exchange, or the front-end must own and dictate the
back-end?

It's important to read John's response without leaning heavily on any
words in particular. Here it is:

On 10/3/2014 9:40 AM, John Yeung wrote:

... But again, that's a back-end-oriented view.
While you may not have increased the degree to which the back end is
shaped by the front, the fact that the front end is now relying on
your SP means that the front end is now molded a little more tightly
to your specific back end and is a little less portable to other back
ends.

Imagine a utopia where a front end could have a few changes in some
.properties files and instead of using Google's APIs, it's now using
Facebook's. Or Yahoo's. You wouldn't be tied to one API 'supplier' any
more than you are tied to one brand of tires for your car. That's the
ideal, and we may never quite see it, but the computing principle is
sound. Loosely-coupled is almost always better than tightly-coupled,
whether we're talking about RPG subprocedures or UIs.

An example of tight coupling is RPG record level access. If you wanted
to insert ZIP4 in between ZIP and PHONE in a traditional RLA file, you'd
have to re-compile each and every RPG program that reads the file. Very
tight coupling - the programs all know the nitty gritty details of the
database.

A looser coupling is an SQL FETCH. Go ahead and add that new column
right in the middle of existing columns, none of the existing FETCHes
will care. But you still have to tell SQL what columns to pull from
what table in what order.

Looser still is a subprocedure where the caller asks for a list of
customers and has absolutely no idea what the database looks like. You
can now completely redesign your database and not touch a single program
outside of the API.

Looser still is an API that wrappers the API call. This SP can be
invoked from any modern language, allowing the caller to be on many
platforms from Android to Windows.

Now wrap that stored procedure in a web interface like REST, return the
results as JSON and your customer information is available on pretty
much anything with an IP address, anywhere in the world. If it turns
out that there's only one front end in the world that wants that
information, and only one back end that can provide it, well, that's a
coupling which can't be avoided. On the other hand, if the back end API
is generic enough, then someone else could consume your customer list
and make a UI of her own without having to know pretty much anything
about how the tables are arranged.

Baby steps :-)
--buck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.