Re: [EXTERNAL] Re: Rise of Node

FYI

async and await is an ES8 ECMA standard so it is not likely to go away.

https://tc39.github.io/ecma262/#sec-async-generator-function-definitions

But it may be superseeded by better ways to do things like async/await
superseeded promises but that is only because javascript keep on adding
new exiting features to the language

On Tue, Mar 20, 2018 at 10:40 PM, Tim Fathers <X700-IX2J@xxxxxxxxxxx> wrote:

..you're welcome, I've likewise learned a lot from your various posts and
blogs etc. I've been stalking this group for ages and it's sometimes been a
little disappointing to see how few people post so it's been nice to have
decent modernisation discussion.

"Maybe now is the time with the insanely rich Javascript clients being
worked on."
I think you're right, the SPA was a game changer for me, I never liked any
of that messy server-side rendering done by the likes of JSPs and PHP etc.
it always looked a complete mess of UI code entangled with SQL spaghetti
business logic and I thought it was hideous. When I was first introduced to
Angular and the SPA concept with clean RESTful APIs I loved it immediately,
to me it's exactly how modern web apps should be and as Angular now
supports developing progressive web applications out of the box it's even
more exciting because they can be installed onto any platform as a
native-like app with practically zero additional programming to enable it.

"If you had DB2 available as a REST server, and could obfuscate/compile
your..."
I'll always believe that the "real" code belongs on the server 😊


________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Aaron Bartell <
aaronbartell@xxxxxxxxx>
Sent: 20 March 2018 18:47
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] [EXTERNAL] Re: Rise of Node

Hi Tim,

Thanks for the very thorough response.

I guess you already know this, but SPs are just C programs under the

covers, so the ordinary debugger can be used to step through the SQL code
or the underlying C code

I didn't know that (Aaron looks down in shame). Learned something new
today!

One thing I've always been intrigued by is the possibility to turn DB2 for
i into a feature-rich http-db server. We created a product named DB2 Web
Service Enabler many years ago but it didn't take off. I like to think it
was before its time. Maybe now is the time with the insanely rich
Javascript clients being worked on.

If you had DB2 available as a REST server, and could obfuscate/compile your
Angular/Typescript/Javascript code (to keep logic from prying eyes), I'd
imagine that would allow for some streamlined app development because you
could remove the need for much of the server-side code/routing (i.e.
Node.js, Ruby, Python, RPG, etc).

Anyways, thanks again for posting a full response. It gives me some things
to ponder.

Aaron Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces


On Tue, Mar 20, 2018 at 12:02 PM, Tim Fathers <X700-IX2J@xxxxxxxxxxx>
wrote:

"I'd be curious to learn what you end up with concerning deploying of
compiled RPG objects."
I hadn't got round to tackling that one yet, I was hoping that the RPM
announcement might help in that respect, so that it might be possible to
package source and binaries up in RPM. The client I'm looking at this for
has no change management whatsoever except what I've done for then in
BitBucket and does everything by hand so even having an automated build
that created a save file they could transfer to their live machine by

hand

would be a considerable help!

"Could you post an example of how you do this?"
So, first off I'm referring to business logic in the sense of basic
interactive "CRUD+" stuff, not batch processes and, in the applications

we

most frequently do, the business logic is usually making calculations

over

sets of data or enforcing business rules so it's nothing fancy or clever
and mostly stuff that can be done in a single SQL statement. The CRUDdy
parts are broken out into individual stored procedures, plus usually an
additional one for the paged queries and any that make sense as

standalone

APIs, like CUST_SP_Block(...), CUST_SP_UnBlock(...),
CUST_SP_AddAddress(...) etc., etc.. So each SP is usually quite compact,
any shared logic, like validation is written as a separate SP and called
from where it's needed (like insert, update or just on its own if the
client wants to validate etc.). Our webservice simply executes the stored
procedure POSTed to (after authority checking of course!) and passes the
parameters in the request body, for example:
/web-service/CUST_SP_Query --> executes call CUST_SP_Query(PAGE => 1,
PAGE_SIZE => 15, SEARCH_CRITERA => "Smith")
/web-service/CUST_SP_Add --> executes call CUST_SP_Add(....)
/web-service/CUST_SP_Delete....etc.
/web-service/CUST_SP_Block
/web-service/CUST_SP_AddAddress

The webservice does nothing more than provide an interface between the
RESTful(ish!) API and the stored procedures and the request body always

has

the same format {"inputParms": {"PAGE": 1, "PAGE_SIZE": 15,
"SEARCH_CRITERA": "Smith"}}, where the input parameters match those of

the

stored procedure. The output is also always the same structure, basic

data

about the SP called, the input and output parameters and then an array of
result sets, each containing the column meta-data and the rows

themselves.

This makes life very easy for the client, because you always know what
shape the data will be so you can often make quite generic code to
manipulate and display it. It also makes it very easy to add new web
services, just write a SP and it's automatically available. as an API
endpoint.

We consider that the client of the API is dumb and shouldn't manipulate
the data other than for presentation purposes. This means, for example,

if

the database contains a net and VAT amount, then the SQL will calculate

the

gross amount if it's needed, rather than have the *script client do this.
Similarly, if the client needs subtotalling then this is also done in SQL
not by the client summing the data themselves. Also, most interpretation

of

the data is done concretely in the server side SQL, so if "older than 30
days" means overdue, then the SQL will look up the definition of overdue
and provide a flag in the data that the UI will use.

When it comes to updating/inserting/deleting rows in the database, this

is

again encapsulated into a stored procedure which uses the "begin atomic"
statement to make sure that multiple updates are encapsulated and done
safely.

Where I've written "client" above, you could read "server" if your server
was a RESTful NodeJs application, for example, firing basic SQL queries

at

the database. I would argue that the NodeJs server side code should not
manipulate the data at all either but the SQL should do it. Therefore

each

RESTful endpoint in NodeJs just executes a stored procedure, which if you
boil that down further you come to the approach above because you might

as

make it generic then.

Another advantage I see with this way is that it is more secure. If your
server can fire arbitrary SQLs at the database then it has to have
sufficient authority to the database and thus any compromise of the

server

gives a free reign to the intruder. By encapsulating all of the logic in
stored procedures and securing the stored procedures correctly the user

id

under which the web service is running only has to have *USE rights to

the

SPs and nothing else, the SPs can run under *OWNER, meaning you never

have

to give the webservice access to the raw database.

"I wouldn't have such a distaste for this approach if SQL stored
procs were easier to debug. I am a big fan of step debuggers."
I guess you already know this, but SPs are just C programs under the
covers, so the ordinary debugger can be used to step through the SQL code
or the underlying C code, you have to use a service job though. In any
case, I always develop and test my SQL components interactively before
pasting them into the SP body, which cuts down on the debugging effort in
the first place, I can't remember the last time I actually had to debug a
SP.

So far our applications haven't required us to use RPG stored procedures
for the backend, apart from in the encrypting and decrypting of user
tokens, which uses the system APIs. In terms of complicated business

logic

that you would see as being problematic done in SQL, give me an example

and

I'll try to explain how I'd deal with it (or suddenly realise I never
thought it it 😲!)

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://nam01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%
2Fweb400&data=02%7C01%7C%7C74191cc1aedb41de71b908d58e8acef4%
7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636571649182018494&sdata=%
2FmhKJg1UfZymuGJ1B3wHF5MH1VQDt1qnkjHZNzaJrvM%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://nam01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%
7C74191cc1aedb41de71b908d58e8acef4%7C84df9e7fe9f640afb435aaaaaaaa
aaaa%7C1%7C0%7C636571649182018494&sdata=ye3C7bfkF6HSaqfcPgUvSjDSAQYSrB
uVGZCpmeGgA4g%3D&reserved=0.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.