If you define a non-existent html cache and/or update your server early in the morning or late in the evening you will not have a problem. All browser clients will reload the latest version. Fallback is to show a warning in the GWT client that the browser needs a cache clearing when you get a serialization error. The serialization error is a handy tool for making sure no outdated client connects to a newer backend. Unless you made no GWT changes with the new backend, then no-one will notice anyway.
I would not be one to choose for a dual version in production. It'll turn into a bit of a mess when you have DB changes or domain logic changes. On Fri, Feb 9, 2024 at 4:36 PM Alex Karg <[email protected]> wrote: > Thanks for that answer Jens. Makes perfect sense. > > Regarding point 1, I am thinking about a more seamless upgrade process > that minimizes client interruption. Such that old clients can remain > working on "old" server versions for a while, while new clients work on new > servers in parallel, until all old clients are migrated in a controlled > process. Once no old clients are connected any more, the old servers are > shut down and the upgrade process is completed. > > Is there any suggested standard approach (e.g. Load Balancer Setups, > Client-Server Interface Versioning) to achieve this? Anyone doing this > successfully? > > Freundliche Grüsse, > Alexander Karg > > > > On Mon, Jan 15, 2024 at 5:26 PM Jens <[email protected]> wrote: > >> >> Some mention "some annoying downsides" or "is imperfect in a lot of ways" >> regarding gwt-rpc. What are does? >> >> >> 1. Client and server always need to be in sync because of serialization >> policy. So a user must reload the web app if you redeploy your application >> and have modified shared classes. >> 2. If you want to use J2CL in the future you should not use it. >> 3. You can only use it with GWT clients unless you reimplement the wire >> format in other languages / applications. Only unofficial information about >> the wire format exists. >> 4. No async servlet support >> 5. Command pattern doesn't work well with GWT-RPC because you cannot code >> split the client side serialization data. So your initial or leftover >> fragment contains everything that goes over the wire. Code splitting only >> works well if you have one GWT-RPC service per code split condition. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "GWT Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit/cc4b2a17-a072-4685-b138-34f31e46cc5fn%40googlegroups.com >> <https://groups.google.com/d/msgid/google-web-toolkit/cc4b2a17-a072-4685-b138-34f31e46cc5fn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "GWT Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-web-toolkit/ggDdh0rb6eM/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit/CAHcNM3K8e4KTDhB04yDDKPpP%3Dmp1C7776dPJSdR4%2B5wemXdUww%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit/CAHcNM3K8e4KTDhB04yDDKPpP%3Dmp1C7776dPJSdR4%2B5wemXdUww%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7QQ33UQqjfvkHGZRS%3DrQoZ78KQ3r2_6YfFHXBwdnZZm_Q%40mail.gmail.com.
