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 <
[email protected]> 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 <
> [email protected]> 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: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/web400
> or email: [email protected]
> 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: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/web400
> or email: [email protected]
> 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: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.