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 [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 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/b16fc448-0e51-4c16-a3b3-29b213140a25n%40googlegroups.com.
