Re: Is moving away from RPC a good idea?

[Colin Alworth]

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  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 

Re: Is moving away from RPC a good idea?

[Leon]

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  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  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+unsubscr...@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+unsubscr...@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+unsubscr...@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.

Re: Is moving away from RPC a good idea?

[Alex Karg]

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  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+unsubscr...@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+unsubscr...@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.