Re: Is moving away from RPC a good idea?

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 <alexkarg7@gmail.com> 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 <jens.nehlmeier@gmail.com> 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 google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/cc4b2a17-a072-4685-b138-34f31e46cc5fn%40googlegroups.com.

--
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 google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CAHcNM3K8e4KTDhB04yDDKPpP%3Dmp1C7776dPJSdR4%2B5wemXdUww%40mail.gmail.com.

--
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 google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7QQ33UQqjfvkHGZRS%3DrQoZ78KQ3r2_6YfFHXBwdnZZm_Q%40mail.gmail.com.