Websockets data and App Connect update cycles

Hi @patrick. I would like to tell you about some of the problems associated with updating App Connect.

I created a messenger for a small company (about 50 users) and it worked well before the App Connect update. The websockets worked very well and stably. And since I have a messenger, almost everything there is built on websockets. A very large amount of information is transmitted/received from the server via websockets and this was done very well, the interface reacted to changes as if in the background without restarting connections. In the test version it looked like this:

This was the case before version 4.6.2 of the Wappler. Then I took a break from updates and just the other day I upgraded to version 4.9.0. I did notice some (very slight) acceleration in the interface at some points, but what I definitely noticed is that sockets began to work differently and this literally ruins the whole concept of web sockets and dynamic interfaces that are updated in the background (adding only new data and not reloading old ones). With the new App Connect, when the web socket is updated, the entire server action is updated, which makes the interface react as if a new download has occurred. In the test version, it began to look like this:

This does not seem critical when it comes to 1-2 users using the messenger at the same time. But when there are 10+ of them, all users have an interface that looks like a Christmas tree, constantly flashing and updating.

Also, after the update, a strange bug appeared that occurs when the limit of a paged request is increased. If the limit is increased more than there are records in the request, the following will happen:

Wappler 4.6.2

Wappler 4.9.0

There was already a bugfix posted here in the forum for your last problem, it will also be included with todays Wappler update.

Please test with that update, Wappler update will also be released in a few minutes so you could wait for that.

1 Like

It pleases, thank you! And what about web sockets, how difficult is it to fix their work so that they work as well as in the past, but in the new App Connect?

@George is it possible to make it possible to choose the old version of App Connect for the project? This would allow i to work in the new Wappler, but with the old App Connect in the project.

Now, due to the strange operation of websockets in new App Connect, the messenger has actually turned into an application that cannot be used. And I’ll have to roll back to the old App Connect anyway. At the same time, I don’t want to refuse the Wappler itself, because there are many excellent improvements in the new Wappler.

Being able to choose the App Connect version would be an ideal solution.

Do you have a bug report about the websockets? We aren’t aware of any issues.

And make sure you are running the latest Wappler with the latest app connect 1.14.1

I am using the latest App Connect version 1.14.1

I are not talking about the fact that there are some errors with websockets. There are no bugs. But in the new App Connect, the interface’s response to their update has been changed. If previously the connection to the server was not completely updated after new data came through the websockets (only the data that came via the websockets was updated), now there is a complete update of the elements on the pages that are connected to the server that received new data on the web socket. It looks like this:

It was before

It has become now

How is it being used, is it using a server connect with live reload?

To display the data of the chat, do you use a repeater with a key for that?

Do you mean “Live Refresh with Sockets”? If that’s what you’re talking about, then of course:
1

How can sockets work without this setting?

In terms of usage, nothing has changed. Small visual differences in the design (exclusively html/css) were made even before the App Connect update. And while the app was using App Connect version 1.12.3, everything worked fine. As shown in the first example. Then I updated the Wappler to version 4.9.0 and together with it App Connect was updated to 1.14.0 (now I have already updated to 1.14.1), after which the interface problems began, which are shown in the second example. In other words, the above examples of applications work differ only in the version of App Connect. Everything else is configured the same.

Both the first and second examples use the usual repeat setting that the Wappler offers (there is no key in it):
2

I just did a test. I replaced the App Connect file in the project folder with App Connect version 1.12.3, which I had in another project (which I haven’t updated yet). After that, the interface update worked perfectly again when using web sockets.

You now have something like dmx-repeat:repeat_chat="...", could you update that to dmx-repeat:repeat_chat.fast="..." in your code.

There was nothing updated in the repeat attribute or the sockets, so it is probably related to something else that was updated in App Connect. Will investigate it further.

Tested it. This did not solve the problem.

Can you check in devtools in the network tab how it gets the data, does it use the websockets or did it use fetch/xhr to get the data.

Everything is fine with this, all data is received via the websocket:

Can you send me the html of that specific page, it doesn’t seem to be a problem with the sockets but more with the rendering of the content.

@Mr.Rubi We have a messaging app which use WebSockets extensively. Updating to 1.14.x did not affect anything in our setup.
But, we did find another issue due to the new AppConnect version.
I would recommend to revisit the setup in parts and try to identify which part is failing with the new update.

Like Patrick has suggested, it could be a rendering issue - which is similar to the binding issue we experienced.
We have re-factored the code completely due to this, and are back to normal and a faster AppConnect.