While I tend to respect and agree with most of what Nathan A. writes, I must disagree with his analysis of stateless applications.
Stateless applications are not new to IBM i.
Oracle JD Edwards (both E1-web and World green screen) and SAP are both examples of robust ERP class systems with thousands of tables and often many thousands of users. Both of which are mostly stateless. Those systems have been around for 30 years.
For example, if you inquire on an item in JD Edwards World on a 5250 green screen using "Item Master Information", the records associated with the item are not locked. A user could inquire on an item, then 15 minutes later return to the screen and make a change without re-inquiring. The initial "state" of the data is stored in the RPG program's memory. JD Edwards verifies on changes that the state has not changed (i.e., another user modified the item during the 15 minute pause) and issues an error message if it has, otherwise updating the database. The E1 web version is similar, except that state is stored in browser/local storage.
SAP uses similar methods, as do many custom IBM i applications.
In fact, stateless may be the best model for many types of interfaces.
Statelessness is a requirement for Progressive Web Apps (PWAs). Every day new PWAs are created by large enterprises - app.Starbucks.com for example.
The PWA design paradigm could easily become the de facto standard for all web apps.
On Thursday, December 24, 2020, 2:21:51 PM GMT-3, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
I know my inquiry is rather vague. Unfortunately, I haven't been given
clear direction. My best guess is they want something to allow
self-described "400 programmers" to write modern web front-ends with
backend RPG. No small task there.
Think about the scope and types of applications you want to deploy and the
types of users you want support because that can have a profound impact on
what tools and interfaces might work best for you.
In regard to types of applications:
- An e-commerce web site?
- A technical support portal?
- A dashboard that shows the results of queries and summaries using
charts and graphs?
Those types of applications tend to be fairly simple, don't require much if
any maintenance of end-user state. Even social networking sites are
relatively small in scope.
Contrast that with ERP-class systems that entail hundreds or thousands of
database tables. Interfaces that apply extensive data validation and
referential integrity checks. Interfaces that support and navigate within
hierarchical and sibling relationships between database tables. Interfaces
that apply access rights and authorizations across many types of users. In
that case you would do well to consider tools and interfaces that help you
deploy hundreds or thousands of database maintenance, transaction
processing, inquiry and reporting applications quickly. Perhaps interfaces
that support a community look and feel across many types of applications.
If your primary focus is on "400 programmers", you're probably tempted to
prioritize open-access interfaces that preserve the display-file write-read
paradigm. Those interfaces deploy a JavaScript applet that effectively
implements a display-file emulator in a browser. I urge caution about that
because that type of interface is terribly constraining in comparison to
the more common request-response cycle that truly robust user interfaces
require.
From my experience, it is best for "400 developers" to write applications
that implement a cycle where RPG programs receive requests from browsers
and return formatted responses (whether HTML, XML, or JSON). Allow the UI
to invoke any kind of request at any time and triggered by any client event
as opposed to programs that write records to a client then read prescribed
records from the client.
Applications that implement a request-response cycle can also be compared
and contrasted with the traditional CGI interface, which is similar to
stored procedure interfaces, in which "programs" are "called" by browsers.
One problem with traditional CGI is that the interfaces are stateless,
where your program may be running simultaneously in many HTTP CGI Jobs.
Stateless interfaces don't really support robust user interfaces, which are
more common in ERP-class systems. Consider implementing stateful
interfaces, which "400 programmers" can definitely relate to.
Food for thought.
Nathan.
midrange.com
