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?
midrange.com
