Re: What forum is best for a Tope and Node question?

anyone contemplating that would also contemplate moving away from the IBM

i altogether

Every technology should be required to prove itself on a continual basis.
That's why RPG is being replaced. I can't say the same for DB2 on IBM i;
having a rock solid database is a big deal. I've had a number of customer
engagements where adopting Node.js and SQL is being done so they have
options in a decade. Sometimes mitigating risk is having just the right
amount of vendor lock in.

millions invested in their existing code-base and they simply don't have

the appetite or the will to rewrite swathes of it in some new language

In all of my strategy engagements I highly recommend the incremental
approach which includes Node.js making use of existing RPG logic as a
stepping stone.

This also has the advantage of separating the UI from the business logic

in a stepped way, such that later, if we decided to rewrite parts of the
backend in Typescript or Node, we could present the same API to the UI (or
at least be sympathetic to the existing API) thus giving us a migration
path, should we wish to take it, from RPG to the more modern languages.

Exactly.​



Aaron Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces


On Fri, Mar 16, 2018 at 1:24 PM, Tim Fathers <X700-IX2J@xxxxxxxxxxx> wrote:

...ah, you beat me to it with the RPM tweet!

"Lots of shops are seeing the writing on the wall with RPG and are moving
away from it(n1) and selecting their next generation language. They could
go with the solid PHP, but then they'd be picking a language that's not on
the rise. They could go with Ruby (not extensively adopted on IBM i,
though very popular everywhere else). They could go with Python (another
solid general purpose language, and seeing more adoption on IBM i than
Ruby). Or they could go with the newer kid on the block that offers
something none of the others can, a single language for client and server."

Of course, I agree in principle, but in my experience most places have
millions invested in their existing code-base and they simply don't have
the appetite or the will to rewrite swathes of it in some new language
which they have little or no existing experience in. In any case, such
projects have a very high failure rate and I fear, here in Europe at least,
anyone contemplating that would also contemplate moving away from the IBM i
altogether 😞
Obviously there are many ways to skin the Web Application cat, ranging
from the complete rewrite to scraping the green screen (ewww!) and various
shades in between. We asked ourselves how we could give our users a
"proper" native web application (so not some awful screen scraped UI) but
without having to completely bin the old code or make everyone learn a new
programming universe. Our solution was the one I have mentioned, by
providing a web service to execute stored procedures we could provide a
consistent API to and from the IBM i, the backend business logic code could
still be developed in the current language of choice (RPG and SQL at the
moment) and, even though it can require some significant re-architecting,
much of the code can be reused. The front end(s) are single page web apps,
written in Angular which simply talk to the stored procedures via the web
API, clearly this does require a completely new skill set, but this can
start with a small team of developers at first and doesn't require the big
bang approach that rewriting does and nor does it put the core business
logic at risk.

This also has the advantage of separating the UI from the business logic
in a stepped way, such that later, if we decided to rewrite parts of the
backend in Typescript or Node, we could present the same API to the UI (or
at least be sympathetic to the existing API) thus giving us a migration
path, should we wish to take it, from RPG to the more modern languages.

Of course, there's no right or wrong way I guess, but the above is the
though process we went thought and why we chose out particular way. :-)