Using the header as a status bar

[aranvir]

Hi, I'm using wave as a frontend for my web api and started with the navbar+header template to get the app set up.

I have some status data that I'd like to display to the user, for example, whether the background workers exposed by the api are available or not. Currently, I added a ui.markup component to my header items list and whenever the page changes or is refreshed, the status will be queried again and the markup component will be updated.

The two functions below take care of this, on_page() is called first whenever a page is loaded.

def get_worker_status():
    header_worker_status_template = '<h3 style="color: {color};">Worker mode: {mode}</h3>'
    success, mode = get_worker_mode()  # wrapped http request to API
    if success:
        return header_worker_status_template.format(color="white", mode=_mode)
    else:
        return header_worker_status_template.format(color="red", mode="none")

def on_page(q: Q, page: str, ignore: Optional[List[str]] = []):
    q.page['sidebar'].value = page
    q.page['header'].items = [ui.markup(name="markup", content=get_worker_status())]
    clear_cards(q, ignore)

Next better implementation would be to run this status check in the background and broadcast it to all users and clients. I'm not sure if and how this is possible with wave. I read the docs on realtime sync but it's my impression that mode="broadcast" applies to the whole page, right? So, I can't employ a "partial broadcast" to just push changes to the header.

The only other option I'd considered is to use an inline script to update the markup card. But I wanted to mention the issue here in case there are better solutions or in case this might be an interesting general feature to add.

[mturoci]

Hey @aranvir.

it's my impression that mode="broadcast" applies to the whole page

Correct. This wouldn't be suitable for yourcase.

The only other option I'd considered is to use an inline script to update the markup card

Hm.. not sure why inline script would be needed? You can update the header card directly from python (I am missing something probably).

I suggest reading this blog post to see how this problem is usually solved in general.

[aranvir]

Thanks! I'll have a look at it 👍

[aranvir]

Finally had a chance to look at it. Worked flawlessly. Thank you once again!

[aranvir]

Question

Hi @mturoci , I have a follow-up question since I'm running into some issues for my use case that are "probably" design mistakes on my side.

Is there a way for the app to be notified when a client is closed? I see the ui_drop message in the server log whenever I close a client but I don't see something similar in the log for the wave app. I'm asking this because I look for a way to stop the "refreshing future" once the client is closed.

Background

My idea was: The heartbeat of my API sends its current mode as message. The status header shall display this mode or "none" when no heartbeat is received. This works in principle, BUT when I open a new tab (ergo, new client) the status bar is not updated anymore. Only the original client gets the live updates. All others just keep the value of API_STATUS for when they where opened. Reloading the tab, reloads the new value, but there are now live updates.

I know that instead of globals I could also use q.app to share this information between clients but what I disliked about that is that this would only start the flow on first visit to the page (which is okay but I'd like it to run from the start of the app).

The issue in either case is that the "refreshing future" is only started for the first visitor. I went for this solution because:

• I had hoped to "broadcast" this update to any client connected
• I didn't want to create one future per client if I can't shut them down on client disconnect.

I tried to "hack" some broadcasting for this future but was unsuccessful. I assume the correct way to implement this feature would be to have one future per client but also requires "future clean-up" to not eventually have dozens of dead futures looping around.

Code

...

APP_INITIALIZED = False
API_STATUS = ""

async def update_worker_status(q: Q):
    """Update worker status if change occurred"""
    global API_STATUS
    logger.info("Starting worker status update...")
    if "API_HEARTBEAT" in os.environ:
        address = os.getenv("API_HEARTBEAT")
    else:
        address = "tcp://localhost:9000"
    subscriber = basic_sockets.AsyncSubscriber(address)  # convenience wrapper of a zmq SUB socket
    subscriber.connect()
    q.page['header'].items = [ui.markup(name="markup", content=_format_worker_status(API_STATUS))]

    while True:
        try:
            value = await subscriber.recv_without_cb()
        except Exception as e:
            logger.error("Unhandled error experienced for update_worker_status", exc_info=e)
        else:
            if value != API_STATUS:
                fmt_value = _format_worker_status(value)
                q.page['header'].items = [ui.markup(name="markup", content=fmt_value)]
                API_STATUS = value
                await q.page.save()

...

async def init(q: Q) -> None:
    ...
    q.page['header'] = ui.header_card(
        box='header', title='', subtitle='',
        secondary_items=[ui.textbox(name='search', icon='Search', width='400px', height='150px', placeholder='Search...')],
        items=[
            ui.markup(name="markup", content=_format_worker_status(API_STATUS))
        ]
    )
   
...

@app('/')
async def serve(q: Q):
    # Run only once per client connection.
    global APP_INITIALIZED
    if not q.client.initialized:
        q.client.cards = set()
        await init(q)
        q.client.initialized = True
    if not APP_INITIALIZED:
        q.client.future = asyncio.ensure_future(update_worker_status(q))
        APP_INITIALIZED = True
    # Handle routing.
    await handle_on(q)
    await q.page.save()

[mturoci]

Is there a way for the app to be notified when a client is closed?

Currently in nightly only. I hope to cut a release early next week. If you want to test it out though here is how it will work.

A few notes on how I would approach the problem:

• If you are building a dashboard - e.g. everyone sees the same data, go for a simple Wave script. Wave in this case broadcasts the changes for you.
• A more advanced scenario is when you want only a certain part of your app to display the same state for everyone and keep the rest on per-user basis (e.g. picking from dropdowns etc.). Ideally, this would be solved on Wave side, but it is currently not IIRC.
• 1 polling future per client is fine (and will even be possible in the next release) as long as you do not have thousands of concurrent clients - might DoS your own server. For more serious traffic I would go for observer pattern - have a single polling function that is subscriptable by clients. Each subscribed client (observer) is notified when new data arrive and can redraw its browser.

[aranvir]

Thanks for the quick reply! Yea my use case falls more in the advanced category.

Then I will wait for the next release and also look into the observer pattern.

[aranvir]

Implemented handling with '@system.client_disconnect'. Works great, thanks!