Multiple clients from one browser

[ed2050]

Update

Parts of this post about client id may be somewhat inaccurate. See next post below.

Original post

I'm currently figuring out the best way to handle multiple clients to the same page from the same web browser with separate state. Nicegui doesn't do this by default. Since this is a general issue for many web apps, I'm posting my approach here. Maybe others will benefit or suggest an alternative.

Issue

I'm trying to match my app model with nicegui's architecture. Nicegui is different from typical client-side web apps where user data is remote but most app state is maintained in the client wepage. New tab = new client with separate state. User data is same, UI state is separate.

Nicegui doesn't distinguish multiple tabs to same page from same client (or maybe it does, but I haven't found it yet). The server doesn't support running several copies of the same page in parallel from one browser. This is something my users need, similar to opening multiple tabs with different google searches, or linkedin, or amazon, .... The way most web apps work.

Nicegui's server-side architecture plays a role in this approach, as does its async execution model. A forking or threaded server that spawned a new fork / thread for each connection would maintain separate state for each connected websocket by default. But nicegui runs everything in one process because async's all the rage somehow. And it treats every (browser, url) pair like one monolithic page for some reason. So we have to deal with those architectural decisions.

Solution

I'm figuring out how to distinguish multiple clients to same page from same browser. The little-documented client id nicegui.Client.id could work for this purpose. But I'm concerned about involuntary socket disconnections forcing a page reload, which happens regularly with nicegui doc site. This seems to generate a new client id, meaning user loses their current state and their progress if client id were used as session key.

Cookies and local storage don't work because those are per browser. Each tab to my app accesses the same cookie and storage values. You could index those by client id, but when client id is regenerated on reload, how do you know which previous id to retrieve from? I don't think you can.

My current plan is to use query parameters:

• on first page load, user goes to naked url myapp.int/foo
• app detects naked url and generates new query id 12345
• app redirects client to myapp.int/foo?id=12345
• on second access, app finds id param in query and proceeds as normal
• client state is preserved against any disconnects or page reloads by id in url
• to start another tab, user goes to myapp.int/foo again and a new id is generated

Pros and Cons

This is actually more robust than current CGI app, which loses state when page is reloaded (but this rarely happens). Whether that's a good or bad thing depends on the users.

Copying and linking the url with query id is a no-no, as every visit to the link will see the same state. Bookmarking also preserves state (as long as server is not reloaded), which can be confusing. So users need to remove the id in these cases.

My app will always present naked urls to create a fresh page. But I can't control what users do when bookmarking or sharing links. We'll see how it goes, if support incidents rise or not.

Code sample

To illustrate, no promises this code runs as is.

# ------------------------------------------------
@ui.page ('/foo', title = pagetitle)
async \
def foopage (client : nicegui.Client , qid = none) :

    # --- generate unique query id
    # redirect BEFORE client.connected or you'll be hosed

    if qid is none :
        digits = random.choices ('abcdef1234567890', k = 8)
        qid = ''.join (digits)

        newurl = f'/foo?qid={ qid }'
        log (f'redirecting to : { newurl }')
        return Redirect (newurl)

Yes there's a chance of collisions in my query id. It's fine for my purposes. Adjust as needed.

[ed2050]

Update

When running into this issue, I switched from global/shared pages (which nicegui calls auto-index) to local pages (which they call private). I think my issues had to do with leftover state outside page scope being carried over from one page to the next.

Anyway I tested with query id as described below. Reloading page still wipes page data even when query id is the same. Preserving state across reloads / changes to client id needs more than just a url invariant. Still have to manually pack / unpack state with a mechanism that persists across reloads, like cookies or storage.

There's still a use for query id parameters, so below post is still relevant. It just takes a bit more work.

[rodja]

Anyway I tested with query id as described below. Reloading page still wipes page data even when query id is the same. Preserving state across reloads / changes to client id needs more than just a url invariant

NiceGUI now provides several storage options. And we are working on two more: #2820, #2837

[natankeddem]

Couldn't this user state use app.storage.user? Or is that what you found was unreliable because it uses nicegui.Client.id? I haven't looked much into these storage options outside of the docs TBH.

[ed2050]

The docs on app.storage.user say this:

Stored server-side, each dictionary is associated with a unique identifier held in a browser session cookie. Unique to each user, this storage is accessible across all their browser tabs. app.storage.browser['id'] is used to identify the user.

I interpret "accessible across all their browser tabs" to mean this storage is unique per browser not per tab. Like cookies (which this storage apparently uses). Indeed my tests show that's the case. I need unique state per tab so one user can run multiple tabs in parallel.

app.storage.general is useless because it stores data for the entire app. Same as having a global variable. Not sure what the point of it is.

Whats needed

1. Storage per tab
2. Survival across disconnections / forced reloads

That can be accomplished with a unique key that survives across page reloads. Ok that's challenging with a stateless protocol, but doable. Unfortunately nicegui makes it harder than necessary:

1. NG provides identifiers per-page (client.id) and per-browser (app.storage.browser['id']). In a normal web app that's enough: when state is stored client-side, disconnections and reconnections are easy to cope with (just wait and try connecting again). Server-side state can't handle reconnections so seamlessly. User has to roll their own identifier that survives (hence query id above). Better support would be nice, but I can live with this part of it.

2. NG makes identifiers needlessly difficult to access. This is the real killer. From a @ui.page decorated function, it's easy: get Client and Request params, read any ids you want. When you're in functions several layers down the stack, it's quite difficult. Where's the function to access client id from anywhere in the call stack? Where's the function to access requested url and query params from anywhere in the stack? They don't exist. Nicegui creates all this magic context and hides it away where you can't access it, buried in undocumented internals with no public interface.

Most web frameworks provide any easy way to get the request parameters at any point in the call stack, such as this. Apparently FastAPI and starlette don't provide that basic functionality for some reason. Users have to roll their own solution. To me that's a sign of a broken framework.

Code examples

Here's what this means in terms of code. NG / FastAPI / Starlette only provide the request object at a single point in your code: the @page decorated function. So instead of being able to do something simple like this:

def func1 ()  :  
    request = nicegui.context.request   # or nicegui.get_context () .request, doesn't matter
    qid = request.query ['qid']
    return data [qid]

def func2 ()  :
    return func1 ()

def func3 ()  :
    return func2 ()

@ui.page ('/foo')
def mypage () :
    obj = func3 ()
    # do something with obj

With NG / FastAPI / Starlette you have to do this:

def func1 (request)  :  
    qid = request.query ['qid']
    return data [qid]

def func2 (request)  :
    return func1 (request)

def func3 (request)  :
    return func2 (request)

@ui.page ('/foo')
def mypage (request : Request) :
    obj = func3 (request)
    # do something with obj

Issues

1. It pollutes the namespace. func1 and func2 don't need to know or care about the request object which they don't use. It forces every function in the chain to pass parameters needlessly.
2. It increases dependencies exponentially, making changes much harder. Say func1 originally doesn't need to access request. So func1, func2, func3 don't have request parameter. Now func1 changes and needs to access request. You have to go back and alter 1) every function def in the call chain from my page to func1 and 2) every call to those functions, just to pass request object from mypage all the way down to func1.

Above code is a very simple example. Real functions will be a lot more complex and messier to update: multiple params, calls from many places, etc. Cascading changes mean your code is fragile and not properly isolated. It's bad practice. Imagine if every ui.element () call had to accept and pass-through the dozen parameters that ui.run () takes.

This mostly isn't NG's fault. Fastapi and Starlette seem to suffer from the same problem - so much so that a number of users ran into it and rolled their own plugin solution. However, by picking fastapi / starlette as their base, we have to deal with the consequences.

[natankeddem]

My apologies, I misunderstood the scope of what you were trying to share data between. If you think there is no "clean" way to write the type of functionality you are trying to achieve I think a working example of this "dirty" code might go a long way toward getting any sort of traction here. It sounds like you don't like the syntax provided so perhaps there is some way to make it better structured and documented.

[rodja]

Hu? So much text and hard to figure out the core. While reading the initial text I had the feeling that there is something strange in your assumptions drawn from some tests you made. Which you confirm with

I think my issues had to do with leftover state outside page scope being carried over from one page to the next.

If you use a page-generator, every visitor (speak every tab) becomes it's own context (stored in the client class). If you use global variables in a page-generator these will obviously not be different for each user.
Regarding your concern of automatic page-reloads where the browser tab looses state: this will only happen if the connection to the server is lost for longer than reconnect_timeout which can be configured as a parameter in ui.run.

[ed2050]

@rodja -
As I try do more with NG, I find that NG is lacking several things, mostly in documentation. NG does a lot of magic behind the scenes. When you develop a multi-user web app, you quickly run into walls. Casual users don't have these issues: put a button on a page, single user global namespace, everything works ok.

1. Documentation of the execution model is missing

• Normal web app: UI state executes in client, server stores most persistent data, client requests data as needed.
• Server side web framework: server handles incoming page requests, provides isolation (separate processes or threads) per request, support for contextual data structures.
• NG / FastAPI: server manages state somehow? Not made clear. Executes page functions when exactly? Not made clear. Stores state between events on a page? Not made clear. The execution model is a mystery not explained anywhere.

Perhaps this is all documented elsewhere, in FastAPI or starlette or such, and you don't want to repeat that info in NG. Ok fine - but here's the disconnect: making non-trivial apps with NG requires knowing those things. All the NG docs say "we do this magic, you don't have to worry about any of it". When it should say "We do this magic, for many uses you don't need to worry about it. But if you do need to know, here's where to find more info on what really happens behind the scenes: link, link, ....."

2. Methods to access current context are lacking

• Need to access url and query params outside a decorated page function? Sorry no simple calls like nicegui.get_context (). Instead you have to send a request to the client (!) to run a javascript call (!) and wait for the answer (that's the advice I saw in discussion forum). How inefficient and error-prone is that?
• Need to access the root element of the current page? Sorry, no way to do that! Maybe you can get the Client object (but only in a page decorated function!) and access client.page_container (completely undocumented) and find the root there, but... sorry you're on you're own.
• Want to access lots of other useful stuff, like request.scope, request.cookies, request.session, client.elements, client.environ, and more? Sorry, we don't tell you that stuff even exists, much less where to find info on it (links to relevant FastAPI docs, Starlette docs, etc).

I'm really struggling to figure out what nicegui does behind the scenes. Is it info that casual users who just make clicky-clicky shouldn't have to worry about? Yes asbolutely. NG made a great decision to hide this complexity for basic usage. But when you need to go beyond that, where is the info?

[rodja]

To sumarize your post: NiceGUI could do a better job of documenting thing. And provide even more nice APIs to do stuff. We completely agree. But it takes time and effort. This is the downside when building a framework which is very easy to start with but still allows to go very deep. There will always be things not yet documented or more tricky to access than you would wish in a particular situation. Let's improve gradually. With pull requests and discussions about specific features.

[ed2050]

That's mostly accurate. I know time etc are limited. You guys have done a great job getting this far. Now let's fill in the rough edges and take NG to the next level.

Documentation

On documentation, you guys have done a lot very well. The components are shown with examples of various features. For intermediate usage, it's very useful. What's missing are 1) a beginner guide to explain the basics, as we already discussed & started on; and 2) a more advanced guide to explain hidden components: slots, context, etc. At least the basics of what they are and how to access them when you run into walls.

How to improve

You must have internal documentation on much of this stuff : if nothing else, docstrings and comments in the code. Can you autogenerate and publish an API index for every public-facing module? Client and request objects contain so much data that's undocumented. A guide explaining these things can be a long term goal and I'm happy to contribute to that. Until then, a generated API reference is a great start. Beyond just the visible UI components that you already cover.

Features

On missing features, it's not like these are advanced things. I'm not suggesting a calendar component or such. Of course those take time. I'm talking about basic features every web framework should have. How to get the root node of current page. How to change page title dynamically. How to access http request from any point.

How to improve

Look at http.server and BaseHTTPRequestHandler for what a minimal server-side web app interface should provide. Look at how flask gives access to the current context. Some of these things NG already provides. Some may not be relevant (rfile, wfile). What about the rest? Are there things like context that NG can expose via a simple get_x () call? Hiding complexity is good - until that complexity is needed.

There's a lot in client.environ, client.page, request.scope that apps would benefit from accessing. Root node, current node context, http request, etc. Probably more useful stuff in nicegui.functions, ng.slot, ng.page, ng.helpers, etc.

I'm keeping a list of issues I run into. Will share when ready. Thanks for discussing.

[ed2050]

Thanks Natan, appreciate the suggestions. If I reach a point where I'm stuck then I'll definitely post code. For now I just wanted to see if others already solved the same general issues.

…

On Sun, Nov 26, 2023 at 9:10 PM Natan Keddem ***@***.***> wrote: My apologies, I misunderstood the scope of what you were trying to share data between. If you think there is no "clean" way to write the type of functionality you are trying to achieve I think a working example of this "dirty" code might go a long way toward getting any sort of traction here. It sounds like you don't like the syntax provided so perhaps there is some way to make it better structured and documented. — Reply to this email directly, view it on GitHub <#2082 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIKNAODY72BBEGCIYIKXVGLYGOV2RAVCNFSM6AAAAAA72DICGWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMNZUG4ZDI> . You are receiving this because you authored the thread.Message ID: ***@***.***>