Re: Rise of Node

Arr, but you can do both and reuse the code because it is done in
javascript - you just have to
store your validation functions in an object and then you can use it field
by field in the client
and batch when data is send to your REST service.

On Mon, Mar 19, 2018 at 4:51 PM, Mark Murphy <jmarkmurphy@xxxxxxxxx> wrote:

Because basic web security practices say you must always validate client
input on the server. You can still do validation on the client to provide a
better experience, but you must validate input on the server because the
client can return anything the user wishes, and if the server just assumes
it is valid, then you are in for a rude awakening when someone decides to
see just what happens when they send an invalid input.

On Sun, Mar 18, 2018 at 11:29 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Tim

why not just let the client validate simple field values?

On Sun, Mar 18, 2018 at 4:24 PM, Tim Fathers <X700-IX2J@xxxxxxxxxxx>
wrote:

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:

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%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://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.

--
Regards,
Henrik Rützou

http://powerEXT.org <http://powerext.org/>
--
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.

--
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.