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 message 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:
Is there really a case to be made for Node doing it all?
In my mind, yes.
Say you have an application with a form that prompts for eight (8) fields,
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%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636569448746574789&sdata=SdDGkDZilAJr4w2Ky9DPR0WgCqTpbPB6XNkhVDYKVhI%3D&reserved=0.
midrange.com
