Re: [EXTERNAL] Re: Rise of Node

Yes, I think we agree mostly, and I have appreciated your contributions to
this and other discussions.

I don't know if we've influenced others to deploy database related logic to
the same address space as the DBMS and forgo the geeky urge to migrate that
type of processing away from IBM i. Perhaps time will tell.

I'm intrigued by Node.js and I see a place for it. But I'd definitely steer
clear of migrating database-related logic there.


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

"While our implementation strategies may differ, I think there is a good
case to be made for keeping database-related logic in the same address
space as the DBMS. Keep it separate from logic that is controlling the user
interface."

I think we agree mostly don't we?

"Who knows if the async-await keywords that were added to Node.js are the
final landing point as far as syntax is concerned. Maybe all of that logic
will need to be replaced 1 year from now."

Async/await is based on promises, which I think are part of the language
spec now anyway, but you're right to be suspicious! All of the async stuff
in Angular 1 was promise-based and it took a little while before we were
comfortable with it, especially as we didn't have a great deal of async
coding under our belts at that time. Then came Angular 2 and all of a
sudden, promises were out and observables were the new kid on the block! To
be fair, observables are incredibly powerful and can be converted to
promises and vice versa, but they are also quite tricky to get your head
around at first, they are based on an idea called the Observer pattern and
reactive programming which is a completely different way of doing things
and it meant a whole new learning exercise, however, it is well worth
investing some time in studying ReactiveX. I wouldn't be surprised to see
an observable based API emerge in future and even if it doesn't, it's worth
knowing that async/await isn't the be all and end all of async programming.