Re: Web dev tools

Greg,

Thanks for your detailed response. It sounds like I should explain why I
think stateful server jobs support more robust user interfaces. I also
think most "400 programmers" can relate to this because of their experience
with 5250 interfaces. I've worked with RPG developers who have struggled
transitioning from display files to CGI programming in that stateless CGI
interfaces require that they must decide which program data needs to be
tracked from one request to the next, to write code to associate it with a
session ID, to save relevant session data after completing requests, and to
restore it before responding to another request. It was so convenient under
the traditional display file paradigm for each session to be associated
with its own Job and avoid the whole process of keeping track of relevant
state using module-level code. Really robust applications are often built
from dozens or even hundreds of *PGM and *SRVPGM objects that are bound by
program and procedure calls where individual modules are not only required
to keep track of state that's relevant to that module, but also be aware
not to overwrite stateful data that might be relevant to other bound
programs and procedures. The more complex program bindings in your
applications, the more difficult the task of keeping track of relevant
state data. Stateful server jobs in 5250 interfaces free programmers from
repositioning record pointers, re-executing SQL queries in order to
implement database logic. With stateful server Jobs, open files and result
sets retain their values and contents across end-user interactions.

I posted a link to a PDF that included screen-shots of a couple of our web
applications, one of which was titled "School Navigation", which included
about 30 tabs on the surface. In that application, tab clicks activate
programs, which in turn may expose additional tabs, which activate more
programs, such that as users navigate and drill down to additional related
functionality, a couple hundred database tables and SQL cursors may become
active in the Job. However since each Job is servicing an individual
session, developers are not required to manage state in their minds, nor in
their code.

When users click on menu items in our Web portal, in most cases the portal
submits IBM i Jobs for each menu item selected then redirects individual
browsers the Job that pertains to that session. Users may launch many Jobs
that support many sessions if they want or need. When users click the
"Exit" link, or a session times out due to inactivity, the Job is ended and
all of its resources are freed. Contrast that with stateless CGI, which
never frees resources that become allocated in Jobs, until someone shuts
down the entire HTTP server. Over time that acts like a memory leak as HTTP
request dispatching causes every resource to become active in every CGI Job.

Our web portal instances and all Jobs that are launched by users clicking
menu items run separately and independently from HTTP server instances, and
actually run in separate IBM i subsystems too, so that any faulty code that
may cause applications to end abnormally, has no impact on HTTP server Jobs.

Stateless interfaces require CPU and database I/O in order to save and
restore relevant state data, re-execute SQL queries, restore record
positions, which may seem small from one request to the next. But it adds
up on servers that support thousands or tens of thousands of concurrent
sessions. All across the globe, you find web application developers moving
more code off servers, to clients because their server interfaces get so
hammered. They find that their server interfaces are weak links in the
chain. I see developers scaling back application functionality all the time
under stateless server paradigms, which you don't see under say the 5250
paradigm.

Hope that clarifies, a little.

Nathan.









On Mon, Dec 28, 2020 at 12:46 PM Greg Alston via WEB400 <
web400@xxxxxxxxxxxxxxxxxx> wrote:

Nathan,

I should have been more clear. Server jobs communicating with PWAs should
be stateless.
Obviously as soon as the PWA writes a cookie, local/session storage, or
indexedDB it has state (for that matter, pretty much as soon as the DOM is
created if you access say an input element via javascript or a form submit
were the input has an initial value).
But your objection (or pointing out a possible issue) was with traditional
CGI interfaces where a program may be running simultaneously under many
HTTP CGI jobs. Any ILE program that is called via Apache will run under a
CGI job. I agree that visibility can be a bit fuzzy since all jobs for a
specific Apache server will run under the same user id. Just create a
quickie log file procedure and link it when you need to debug and you can
get everything you need to know.

It is also true that non-persistent CGI needs to be stateless. Although
persistent CGI can be stateful (have not played with that in many years).

I guess my objection really has to do with your statement that "Stateless
interfaces don't really support robust user interfaces".

I also disagree that most AS400 programmers would be more comfortable with
stateful interfaces.
Keeping SQL cursors in memory might be nice in certain cases, but with the
current level of IBM hardware and SQL improvements keeping any data for a
user in memory versus getting that data from a few tables and records when
a program starts is imperceptible to the user and for that matter to the
server.
Users initiate web applications via a browser, navigating to a URL via
HTTP. Since you eschew CGI you must be using socket programming, a special
module attached to Apache, or node.js to initiate your programs that
process the users' requests. The user will probably be then asked to sign
on unless you are using SSO, in which case your program will have received
the token info. So after validating the user, you have session info,
which you store in memory, but I would guess that you are writing it to a
table as well. You are probably then stamping that information to any
transactions/updates a user might process.

I would think that if you listed the code to your stateful interface most
AS400 programmers wouldn't have a clue about what you were doing.

Of course stateless server programs will need to know some metadata about
what they're getting from the browser. That can be as simple as a session
id. So, the state of the client's session is therefore stored on the
client and needs to be communicated to the stateless server programs. You
can use the sessionStorage js api for that, each tab in the browser is a
session. While the client stores the session id, the IBM i needs to
actually hold the session's information. The client will also need a
little bit of js to redirect to a login page (or unhide a login div, show a
login modal, etc, etc) if there is no session open. You could alternately
use a cookie if a session is to include multiple browser tabs. So, the
stateless apps get the session, validate, then error or continue based on
the results. Just moving some code from the server to the client. Pretty
much less than 2ms to get session and user info from a couple of tables.

We as IBM i developers have a myriad of choices now for web programming
now. Well structured Apache HTML, js, and CGI is by far the simplest,
fastest time to delivery, fastest processing, and most reliable choice for
web programming there is. And it's FREE. I would not recommend CGIDEV2 as
other people have suggested simply because the CGI apis are so simple...
get the info the browser sent, parse what was sent, write some stuff back
to the browser. And as far as I know CGIDEV2 has some limits that are
smaller than documented by IBM for CGI.

But what we should really be doing is making it all server agnostic....
motl
Cheers and Happy New Year to anyone that got this far in email








On Thursday, December 24, 2020, 5:48:11 PM GMT-3, Nathan Andelin <
nandelin@xxxxxxxxx> wrote:

>

Statelessness is a requirement for Progressive Web Apps (PWAs).

Greg, I wonder if you might clarify one point. When referring to PWAs,
aren't you actually implementing stateful interfaces in the browser? If so,
then aren't we in agreement that there are good reasons for implementing
stateful interfaces? In regard to maintaining in-memory state, isn't it
more of a question on whether to implement it in the client, or on the
server, or both?

I agree that there are valid use cases for maintaining state in browser
memory, or cookies, or some client-based implementation. But what I don't
get, is why the server side would need to be stateless? For example, you
might want to maintain the state of SQL cursors and other database
interfaces in memory for individual sessions, for individual users, for
ease of coding and for improved performance. I think traditional "400
programmers" can relate to this.

In regard to a discussion about tools, isn't the question more about
whether the tool channels developers into one particular type of
implementation or another, as opposed to having the flexibility of choosing
the best interface for the application in question?
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.