Hi guys - Got an issue here… I am trying to make a “universal demo” page. As in, anyone can go to a link (my weweb page) and it starts a new 'chat" session.
Anyways, I am using multiple queries to pull from URL parameters for each session, as each URL contains the parameters to run the session. But whats occurring, is that it seems that the page “query” continually gets over-written by a user who go to the same BASE URL with new parameters. AS in, its only allowing 1 user at any time to use it… Why does Weweb not start its own session with that page when new person trying that page out has different URL parameters…
Note: This page does not have or need auth or anything like that- its simple web-page that anyone can go to
How can I accomplish not over-writing the query parameters for each person using the site? Thanks Jon!
ok update here… From my trial and erro (i think im onto something), that static variables or just variables are “stored” in cache for the general visit to a site?
And a query type variable (even though they are in the url), dynamically over-writes every time to base URL parameters, meaning anyone using a site at that time sees the same updates.
Thus, I think it might be necessary to write some things into static variables (stored) quicker in my workflow… Will test and post back…
Would be possibly a good idea to add more information into the docuemntation on “query” type variables - specifically that they overwrite every single time so in my case, I cant use them for long in my workflow lol
UPDATE: This did not work… back to the drawing board
Anyone have any tips here?? Ive toyed around for 3 days on this here…
Let me further refine this so its easier to understand…
I have a make a URL for people upon request to try out a chatbot… So, here is the URL i make - Samurai
Firstly, does this look right?
The main issue is that, if multiple people go to that, we all see the messages (like its a chat stream)… This is NOT the intended use. Its supposed to be based upon that particular users session.
I do NOT want to have users log-in and verify etc, and thats the point, a free/open go to the link, start a new chat.
Sooo, what seems to be happeing, is that when a “session” id created as a value at that site, it doesnt change, meaning all users who go to that page dont trigger a new session. Is there a way to “detect” that its a new window on the users side and push to their own local storage for that variable and store the session that way?
This way the session value is unique to the person in the window?
Im a bit a loss here so any help in what I want to do is greatly appreciated…
Ok… UPDATE Here -Sorry lol! Let me distill it down here even more… Looks like what I want to clarify is this:
If a variable is “saved to local storage” but NOT “preserve on navigation” and the user is not authenticated or anything (no log in etc., just a regular old webpage I made with some URL parameters), (See Below), if they refresh the page, the variable is still saved in that users local storage only right??
If another unauthenticated user, goes to that page and resets, it doesn globally refresh in anyone elses local storage right? Thus, isolating that each persons local storage hold the session information?
Lastly, what happens if we “reset” that value in a workflow in general - does that refresh everyones local storage?
It essentially, a website anyone can visit yet I want to retain teh session ID value in the users local storage only…
Okay, so the issue actually was, that WeWeb is subscribing to the tables (entire tables) that are Realtime enabled by default “on init” of the page. This was causing that the Realtime listened to the whole table, instead of respecting the filters that @Jonny set up.
We ended “debugging” this by removing the realtime entirely, as Johny was able to tell when both messages from his chatbot, and also from the app itself were happenning, so he could and was already refetching the collection anyway on each change.
An alternative approach to this, would be turning off the WeWeb plugin’s Realtime (in the plugin settings in WeWeb, while letting it turned on in Supabase), and subscribing/unsubscribing - thus manipulating the realtime manually via JavaScript, I did this on a realtime chat app in WeWeb, and it’s possible.
@Alexis might be a suggestion for you, but I think I already mentioned this before, when I was experiencing this same issue.
Yes I echo @Broberto on this one. Actually did not know that the real time updating was causing issues in other spots in my app as well so yes that would be an awesome feature add
Yes we are not happy at all with the current realtime behavior and automatic collections update. We want to remove/disable this feature and make it doable manually by users so they can choose when it makes sense or not and take care of respecting their own filters for example.
Making the change while not breaking existing apps is one of the many challenges with the supabase revamp!
I’d say, keep it this way, but let the users create new Subscribe channels? You keep the old dependencies alive, but give us the ability to create our own realtime subscription channels? That’s the power of the v2, you make “channels” you subscribe to.
An idea of a flow would be:
Let the users make subscriptions and trigger workflows with callbacks, this way you can append your data to an array for example, or basically do whatever with the payload.
That’s basically the plan for the new channels features. We have to implement plugin triggers for that first.
Handling the legacy behavior is a little bit more though as its not tied to the realtime toggle, we perform the collection update even if you did not toggled on realtime.
When you perform an insert action for example, If realtime is enabled we will let the listeners update the collection, if realtime is not enabled we will do it ourself with the data returned by the insert action.
We also want to change a lot of default behaviour, an insert action will not return data anymore, so if you have this auto update remaining and you toggeled off the data returned or make it minimal it will not perform as expected.
So we need to figure out how to make the transition smooth. One option could be to generate a global workflow on every project, the workflow would handle what was previously handled under the hood by the plugin. Another option would be to simply have a toggle at the plugin level to enable/disable old behavior. I personally prefer to avoid making tech debt as much as I can, its how you keep the future updates sustainable in the long run, and why we’re still evaluation every options!
hopefully this reply saves more time to others.