Re: Front-end Driven Applications

On Wed, Oct 1, 2014 at 4:46 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

The way I read it, there are so many back-end APIs that you
could basically script your front-end to be the glue that ties all those
APIs together.

I think the article tried to emphasize "front-end first", meaning that
as much of the application is developed on the client side (which, for
the purposes of the article, seemed to be synonymous with "Web
browser") as possible. It's not so much that this "new" paradigm is
about gluing APIs together as it is about being decoupled from the
back end. I think that for a significant portion of applications, the
back end really consists of a database and nothing else.

So, where back-end (or all-encompassing) developers might add new
features by writing RPG programs or stored procedures, or creating new
views, etc. (in other words, customizing the back end) what the
article is saying is: If your application needs to store stuff in a
database, fine, you can hook one up, but it doesn't much matter which
it is as long as you can get to your data. None of the logic that is
specific to your application is going to live in the database; it's
all going to be in the client. (I think the author of the article
would be OK with allowing the front-end application to employ vanilla
SQL and relying on the database to provide an SQL engine. This
arrangement still allows a high degree of independence from any
particular database, and doesn't require *customization* on the back
end.)

If you wanted a dashboard for your executive types,
you'd call
get_stock_ticker('IBM')
get_weather('Rochester, MN')
get_customer_count('Northeast')

...and so on. Some of those APIs would be public (weather.gov,
nyse.com) and some would be built by your own company.

If you're in a position to be building APIs, then for the purposes of
the article, I think you count as a back-end developer.

John Y.