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:
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.
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:
Do you mean “Live Refresh with Sockets”? If that’s what you’re talking about, then of course:
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):
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.
@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.
