|
The short answer is that you'd either have a WS API to validate each
field, or roll it all into one which is able to validate individual fields,
sets of fields or the whole lot. For example:
/my-web-service/validate_customer_name {name: 'Martin', surname: 'Gore'}
/my-web-service/validate_customer_address {addressLine1: '1 Basildon
Lane'...}
or
/my-web-service/validate_customer {name: 'Martin', surname: 'Gore',
addressLine1: '1 Basildon Lane'...}
In my framework, these APIs are just stored procedures that you can
implement in SQL or RPG or whatever else you wish. They just do the same
thing you'd do in your original RPG (with some caveats - see below), in
Node you'd have to implement that
functionality in Javascript/Typescript and SQL (as the database I/O is
asynchronous, you wouldn't end up blocking the Node thread so there would
not be an issue in that respect). The result would be either an HTTP status
code of 200 OK or 4xx to indicate an error, and in the body of the response
you would provide details of the error(s) that occurred so that the front
end can display something nice to the user. Of course, this sounds slow,
and in relative terms it is (and that's without thinking about some of the
other overheads involved I mention below), but in reality we get average
round trip times in the low 10s of milliseconds for such requests which is
quite incredible when you think about what is going on. Even if it were
slower it wouldn't matter that much because you could have your web app
fire off the validation when the input field loses focus, that way the user
can carry on filling the form and when the validation result comes back you
can display the resulting m
essage and highlight the field etc. This still gives near instant
validation as the user moves through the form, which is a big improvement
over the green screen.
On paper, things look a lot worse than you might imagine from a
performance perspective. Because of the stateless nature of RESTful web
services you incur a fair bit of overhead with every web service call that
you typically wouldn't have in a green screen application. For example,
figuring out who the user is that's executing the call (by decrypting some
sort of token), determining what the user's rights are to the API and
perhaps to the data too, validating the inputs (on every call because you
can't trust the client), dealing with optimistic locking (because you
cannot lock rows for update), dealing with paging etc. etc. In practice
however, as I mentioned, it's extremely fast, even the paging queries we
use take no more than a couple of hundred milliseconds to run over a file
with the right indexes.
________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Nathan Andelin <
nandelin@xxxxxxxxx>
Sent: 18 March 2018 05:40
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Rise of Node
On Sat, Mar 17, 2018 at 7:09 AM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:
Say you have an application with a form that prompts for eight (8) fields,Is there really a case to be made for Node doing it all?
In my mind, yes.
each of which is a surrogate key reference to eight separate tables.
Validating the form requires the application to ensure that the eight
values submitted on the form must exist in eight separate tables. What
would the JavaScript look like? How would it perform? How long would the
user be waiting for a response saying that the input was successful?
Frankly, I'm skeptical about Node handling that type of validation and
returning appropriate (sensible) messages to users.
--
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://eur03.safelinks.protection.outlook.com/?url=
https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%
2Fweb400&data=02%7C01%7C%7Cda25a31ed4a44f0399af08d58c8a7b12%
7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636569448746574789&sdata=
yBtYxZ36WYmH2wYakMOZxC8gujnyornPM4JerjkJhdE%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://eur03.safelinks.protection.outlook.com/?url=
https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%
7Cda25a31ed4a44f0399af08d58c8a7b12%7C84df9e7fe9f640afb435aaaaaaaa
aaaa%7C1%7C0%7C636569448746574789&sdata=SdDGkDZilAJr4w2Ky9DPR0WgCqTpbP
B6XNkhVDYKVhI%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://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7Cf0eb46cac6264017f4e708d58ce52a2c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636569838231596745&sdata=NQPMN63BImPzhTzf4Ap0QyLEE5vnYqH3Sguuj8b1RYo%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%7Cf0eb46cac6264017f4e708d58ce52a2c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636569838231596745&sdata=cjBs0cEmDbnVFxe1jGsWYpcAK%2FC4HF%2Fkg2zSd1uWKNw%3D&reserved=0.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
