Re: Is moving away from RPC a good idea?

Point 1 is a potentially a serious concern for basically any tooling that decouples through interprocess communication, including grpc+protobuf (with ostensibly "perfect backwards/forwards compatibility") - in tooling that doesn't explicitly force compatibility as GWT-RPC does, you have to implicitly handle the edge cases, like versioning each method/type in some way, or established rules like "reject messages that have new fields or old fields" (which includes never fully deleting fields), and never change the meaning of fields "oh, as of 3.1.2 we trim whitespace, sorry that was significant for you"). GWT-RPC is a lot grumpier about it - change fields of any one type used by any one method in your service, and the entire service is invalid. Poof, you know instantly that something is invalid, and should update to continue.

A disciplined approach like what gRPC forces, where fields added must always be safe to skip and fields removed must never change the meaning of the message ends up requiring design-time work to enforce, and those notions can apply to other tools as well. Only add service calls, version the service when any DTO/message type changes, and keep backwards compatiblity for old versions for a release or two. As long as you upgrade your servers past these breaking points slightly less often than the intervals over which clients get updates, this can't go wrong (and applies cleanly for gwt-rpc as well). Among other projects, the envoy proxy's XDS service is very aggressive about this - it works, and ensures you can aggressively evolve the services, but it sure is a pain for XDS clients to keep up with.

 In the middle somewhere is to do what most teams do, and take a "eh, this probably isn't _that_ important to miss" approach, and a few calls/cases may fail from time to time.

Going back to envoy briefly, XDS makes it possible for the proxy to change endpoints it supports on the fly based on service calls to update the cluster configuration. For long-running streams it can make sense to simply say "Add new cluster member Y, and when you are done with all active connections to instance X, don't allow future connections to it". GWT-RPC isn't streaming out of the box (our GWT-RPC fork is, and is intended to be j2cl/jvm/android/etc compatible), so you need to introduce "sessions" somehow into the vocabulary, or add metadata to responses ("X-FooSoft-Version: 4" means if you speak version 3, time to upgrade, or "X-Deprecated: true" means you're out of date and should update soon, etc) that the client should always check, and assume that rotation can happen over some range of hours or days.

On Friday, February 9, 2024 at 9:36:37 AM UTC-6 alex...@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.ne...@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-tool...@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 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/b16fc448-0e51-4c16-a3b3-29b213140a25n%40googlegroups.com.