× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



None of the logic that is specific to your application is going to live in the database<
That just does not sound right to me; but I don't remember ever disagreeing with John,
so I'm maybe I'm very much mistaken (happens all the time).
However, being a total DB bigot, I would say as much of the application as possible
should be developed in the database if the goal is data integrity.
Otherwise, just use Evernote ?


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Yeung
Sent: Wednesday, October 01, 2014 3:47 PM
To: Midrange Systems Technical Discussion
Subject: 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.
--
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.