Re: [IBMiOSS] Ports and routes needed to replace very large numbers of green screens

Hi Kelly,

My company specialises in helping companies implement restful-based enterprise systems on IBMi. i also sent this email directly t you email address. i have provided a reasonably long reply but i have taken some time and hopefully provided a bit of useful info around your questions.

if you are evaluating options on IBM i please consider looking at this:

www.rest4i.com/lxr
www.rest4i.com/demos

it is a framework developed specially for IBMi REST applications, and has fundamentally changed the way our clients are using and evolving their IBMi applications. everything you have asked about is covered in various parts of its implementation and usage at sites worldwide. IBM have just done a case study that is being published in the next few weeks.

LXR lets you run REST API microservices natively IBMi, with requests made directly via the built-in apache server. most of our clients are large scale banks, insurance, retail and logistics companies with large scale applications on IBMi who need scalability with structured routing and architecture across department/divisions. By serving REST API services natively and directly from IBMi it is possible to simplify the routing, security and infrastructure requirements even for large, high volume applications. no middleware and millisecond responses even on large scale data transactions. you get to use the native job control of IBMi to scale for large volumes/peak periods

having spent the last 20 years rebuilding large IBMi systems to various architectures - more recently rest backend mobile/cloud ui, there are many many possibilities that drive what is commonly called API infrastructure architecture and app design. I would strongly advise against any routing done in the UI/.Net it creates rigidity in specific a layer which can cause significant problems when scaling or making infrastructure changes later on. Where possible you should try and call the Api directly, this increases performance and simplifies testing and debugging.

the right balance of servers/ports depends primarily on three things:
independence of department/business units/owners. if a departments/divisions app changes are fairly frequent and fast evolving, having an independent infrastructure to cope with changes helps drive and mange costs, analytics of usage and also data analytics in independent workloads.
range of scale for peak loads. some divisions/departments need heavy scalable work loads during certain periods, you want to be able to manage load balancing automatically and effectively without degradation of service
security/authentication/scoping considerations for varying and evolving data channels. you may use SSL, OAUth/JWT and various authentication mechanisms as the application evolves.

so as a starting point using a general rule of thumb, and reading what you have (which is representative of what most of our clients have) my advice would be for you to consider the following:

to start consider managing each department using a single Apache server on IBMi with a single port number and make REST requests directly to the rest resource. within each http server instance on IBMi you can route requests different underlying IBMi library/object structures where the micro service is running. This can be done using regex patterns in the apache config instance, or using the land balancing built into apache. so for example you can use one path www.apis.dotfoods.com/orders/ can point to the orders library. you can add multiple libraries in a single http server instance, and mu;tipple servers instances can point to the same library of necessary. Our LXR framework also has some AI components that can automatically deduce patch using rules engine you configure using RPG
high volume services/apis can be singled out and given their own apache server instance as necessary. the routing for this can be handled in many different ways, but for large scale implementations you should seriously consider a gateway that manages traffic between client/web requests and the back end micro services.
if you have a large volume of services and apps i would strongly advise considering implementing API gateway/routing solution. For large enterprises, an almost explicit trend has been to move to and even start with, implementing a gateway using something such as nGinx(open source) and something like Kong (community edition). these are open source solutions relatively easy to configure and scale(used by very small sites up to some of the largest global banks/cloud apps). these keep the routing out of the application backend IBMI(or whatever other rest servers you server data from) and the front end. it keeps development cleaner and much more productive and allows scaling and security in a much more organised manner. all modern gateways use configuration based on API specs using swagger/OAS3 to handle pattern-based deployment and rules based routing options. our LXR framework builds APIs from SWAGGER and generates swagger from APIs to make this process mostly automated
with regards to your questions about SPA’s for many screens and menu options, here are a couple of ideas to consider: if your menus are “soft” menus whereby data that populate set menu is served from a backend (possibly IBMi) server, then and SPA per menu might suffice but could become very overloaded many layers down. also you may wish to have mobile versions or apps and so be careful not to over engineer BIG menus into large objects. are you deploying your .Net via cloud? are you using .net exclusively? i ask because our own apps and some from clients use hybrid implementations, where we use REACT.JS components for menus(driven by REST APIs on IBMi and other backed servers) and .Net or other js framework UI implementations for application data. The point being that separating menus(context navigation) from application UI help reuse, response time and security. especially if you implement multiple device types in your apps. if the menus are mostly static then this sort of data can be cached in the gateway fro performance 0 the gateways can specify refresh and shelf life for cached assets. so you have the best of both worlds.
Our own framework LXR combines openstack/source, latest, industry standards and best practices with components to help manage routing, securing, deployment, documentation and building of REST APIs to optimise evolution and scaling.

A last point is that we offer an API Quick Step process for companies starting out on this journey. we take many years of experience across hundreds of application implementations and distill it into short intense pilot. we provide training and advice on technology, architecture and strategy using a real world example on your system. happy to share some free advice and ideas in the meantime.

regards,

Stuart Milligan
Cell SA: +27 61 651 7074
Dir SA: +27 (0)21 012 5078
Dir NA: +1 917 267 7523
UK: +44 (0)238 097 1176
stuartm@xxxxxxxxxx