Re: [EXTERNAL] Re: Rise of Node

[Nathan Andelin <nandelin@xxxxxxxxx>]

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.