As a Developer I want the app to push changes in booking status to the UI when they occur (rather than have the UI poll the db every ten seconds) so we don't accrue an unnecessarily high number of daily db reads.

[nopivnick]

it looks like one way to approach this is to use a Realtime Database rather than Cloud Firestore but it looks like the former is an older technology and Google seems to encourage the use of the later.

[nopivnick]

https://www.youtube.com/watch?v=6NegFl9p_sE&list=PLl-K7zZEsYLluG5MCVEzXAQ7ACZBCuZgZ&index=3

specifically:

https://youtu.be/6NegFl9p_sE?feature=shared&t=174

where there's mention of setting up a "listener".

[lucia-gomez]

even if we use that i think we'll still have an additional problem to solve, which is pushing data from nextjs server/API endpoint to frontend. Usually I would use websockets for that, so the server pushes data to the frontend via a websocket, but I've read that GAE doesn't like that. Riho would know better about if that's true or not

Unless we want to have our UI directly listen to these firestore changes... but I'd rather keep that behavior serverside unless that's not how things work in nextjs land

[lucia-gomez]

also i believe the initial reason we implemented the 10s polling was because auto approval status updates were taking so long with Google Sheets that we had to refresh the page to see if a booking we just made was indeed auto approved. But those seem to happen much faster now so this isn't a big issue anymore. Might not be worth sinking time into investigating this right now

[rlho]

@nopivnick GAE's design primarily assumes stateless, short-term request processing, so it doesn't natively support Web Sockets which maintain long-term connections. Implementing this would require new middleware like Cloud Pub/Sub, which would also increase database access and costs. This issue is about preventing loss of user experience when users happen to select the same room booked at the same time. I think this case doesn't occur very often, so the implementation and management costs might not be worth it for now. How about we lower the priority for now and tackle it more thoroughly later?

[nopivnick]

@rlho

This issue is about preventing loss of user experience when users happen to select the same room booked at the same time.

my concern is actually less about the above scenario than it is not wanting PAs (and Admins) to have to constantly refresh the Bookings table to get the latest status info.

regardless, we need to optimize our db reads. the number of daily reads is excessive and it's only the three of us touching the app!