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.

Re: Is moving away from RPC a good idea?

[Cricri]

Finally I've decided to stick to RPC and use gwt-servlet-jakarta. We will
have a lot of applications (50+) to migrate to jakarta at some point, this
will be the fastest way.

Thanks all for your comments.

On Mon, 15 Jan 2024 at 11:26, 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/CABi7_98Pk%2BobtN2SiychHVx1sKpjqHW70-XH3pMXQ5pXgqTfQg%40mail.gmail.com.

Re: Is moving away from RPC a good idea?

[Jens]

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.

Re: Is moving away from RPC a good idea?

[Paul Robinson]

One thing I really like about using JSON for my message formats is that
they are human readable (YMMV).

If you're wondering whether a problem is client side or server side, or
when you just want to know exactly what information the client was given,
being able to read the content of messages can be very useful.

Paul

On Sat, 13 Jan 2024, 13:08 Alex Karg,  wrote:

> gwt-rpc is one of the parts I like the most about GWT and why we chose GWT
> to start with. Same DTOs on client and server and you don't have to care
> (too much) about de/serialization. Why do I care about JSON, or binary or
> whatever serialized format, as long as it is secure, performant and
> serialization is able to handle my object relation structures?
>
> Some mention "some annoying downsides" or "is imperfect in a lot of ways"
> regarding gwt-rpc. What are does? The only argument I understood so far, is
> that it may require you to have gwt-rpc *and* REST/RequestFactory
> client-server channels in parallel. We had that since the very beginning,
> because of OAuth, captcha, file download links etc.. I never saw any
> practical issues with that set up. For example with spring-security we can
> easily map both channels to the same user/roles/rights concept.
>
> On Wednesday, January 10, 2024 at 5:26:04 PM UTC+1 Christian Hebert wrote:
>
>> Hi guys, I've seen the changes in the new release regarding jakarta
>> servlets, which is great, it's a step toward jakarta but to this day,  GWT
>> is still based on the Servlet API 3.1.
>>
>> Prior of seeing that change, I tried to move away from RPC calls and use
>> http requests instead. I found a nice library called RestyGWT (
>> https://resty-gwt.github.io/) who can really simplify the process of
>> handling json data from/to a Rest API.
>>
>> So I converted my GWT remote servlets to a Rest API, made a few minor
>> changes in my client code and voilà, I was able to deploy it on a Jakarta
>> Application server since there is no GWT involved on the server side
>> anymore.
>>
>> The last version of RestyGWT has been release in 2020 so I'm not sure how
>> active this project is but from what I've seen it's enough for me.
>>
>> So, I would like to get your thoughts on that.  Would you go on that
>> road? stick to RPC calls and wait for a version of GWT based on Jakarta?
>> build your "own" GWT with the changes introduced in the vew version?
>>
> --
> 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/392768b6-58aa-4c71-b54f-cdb0d3aacf53n%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/CAGHNWN%2BHHwNkDxThecyGKDETUrskO%2BunCLbfGo5H21L94jZWcg%40mail.gmail.com.

Re: Is moving away from RPC a good idea?

[Alex Karg]

gwt-rpc is one of the parts I like the most about GWT and why we chose GWT 
to start with. Same DTOs on client and server and you don't have to care 
(too much) about de/serialization. Why do I care about JSON, or binary or 
whatever serialized format, as long as it is secure, performant and 
serialization is able to handle my object relation structures?

Some mention "some annoying downsides" or "is imperfect in a lot of ways" 
regarding gwt-rpc. What are does? The only argument I understood so far, is 
that it may require you to have gwt-rpc *and* REST/RequestFactory 
client-server channels in parallel. We had that since the very beginning, 
because of OAuth, captcha, file download links etc.. I never saw any 
practical issues with that set up. For example with spring-security we can 
easily map both channels to the same user/roles/rights concept.

On Wednesday, January 10, 2024 at 5:26:04 PM UTC+1 Christian Hebert wrote:

> Hi guys, I've seen the changes in the new release regarding jakarta 
> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
> is still based on the Servlet API 3.1. 
>
> Prior of seeing that change, I tried to move away from RPC calls and use 
> http requests instead. I found a nice library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of 
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor 
> changes in my client code and voilà, I was able to deploy it on a Jakarta 
> Application server since there is no GWT involved on the server side 
> anymore. 
>
> The last version of RestyGWT has been release in 2020 so I'm not sure how 
> active this project is but from what I've seen it's enough for me.
>
> So, I would like to get your thoughts on that.  Would you go on that road? 
> stick to RPC calls and wait for a version of GWT based on Jakarta? build 
> your "own" GWT with the changes introduced in the vew version?
>

-- 
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/392768b6-58aa-4c71-b54f-cdb0d3aacf53n%40googlegroups.com.

Re: Is moving away from RPC a good idea?

[Ed]

+1 nats.io

On Fri, Jan 12, 2024 at 10:33 AM Jens  wrote:

> If you do not have special needs I think GWT-RPC is still fine especially
> with a jakarta version now available. But while it is easy to use it also
> has some annoying downsides you have to live with.
>
> However there are quite some options:
> - JsInterop based DTOs + JSON.parse/stringify. However you loose
> inheritance or have to write some helper code to workaround it as needed
> - Use a json based library that solves the polymorphism problem for you
> - Use gRPC for the web (grpc-web) which requires a proxy in front of your
> server gRPC endpoint to transparently convert binary to json
> - Use websocket in either plain text mode or binary mode. If in binary
> mode you could use protobuf or similar to build the payload
>
> Personally I always wanted to explore using nats.io, which is a message
> broker that also supports a request-reply pattern out of the box. That
> means a message channel/topic acts like a service. Nats has a
> nats-websocket library which connects browsers to the message broker and
> you can use protobuf or similar to define/generate your binary messages.
> Because you now have a message broker between clients and servers it should
> be relatively easy to scale and you get things like broadcast a message to
> all clients (push) with little effort. Nats also has a distributed KV store
> integrated if needed.
>
> -- J.
>
> Christian Hebert schrieb am Mittwoch, 10. Januar 2024 um 17:26:04 UTC+1:
>
>> Hi guys, I've seen the changes in the new release regarding jakarta
>> servlets, which is great, it's a step toward jakarta but to this day,  GWT
>> is still based on the Servlet API 3.1.
>>
>> Prior of seeing that change, I tried to move away from RPC calls and use
>> http requests instead. I found a nice library called RestyGWT (
>> https://resty-gwt.github.io/) who can really simplify the process of
>> handling json data from/to a Rest API.
>>
>> So I converted my GWT remote servlets to a Rest API, made a few minor
>> changes in my client code and voilà, I was able to deploy it on a Jakarta
>> Application server since there is no GWT involved on the server side
>> anymore.
>>
>> The last version of RestyGWT has been release in 2020 so I'm not sure how
>> active this project is but from what I've seen it's enough for me.
>>
>> So, I would like to get your thoughts on that.  Would you go on that
>> road? stick to RPC calls and wait for a version of GWT based on Jakarta?
>> build your "own" GWT with the changes introduced in the vew version?
>>
> --
> 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/5aaec5f2-3d64-45fc-a3d6-63b0d310684fn%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/CAMgbRPtHjaDCDGztqRuwyAzH5kcfRZtY_U%3Dvx53ktXqkEiR%3DOg%40mail.gmail.com.

Re: Is moving away from RPC a good idea?

[Jens]

If you do not have special needs I think GWT-RPC is still fine especially 
with a jakarta version now available. But while it is easy to use it also 
has some annoying downsides you have to live with.

However there are quite some options:
- JsInterop based DTOs + JSON.parse/stringify. However you loose 
inheritance or have to write some helper code to workaround it as needed
- Use a json based library that solves the polymorphism problem for you
- Use gRPC for the web (grpc-web) which requires a proxy in front of your 
server gRPC endpoint to transparently convert binary to json
- Use websocket in either plain text mode or binary mode. If in binary mode 
you could use protobuf or similar to build the payload

Personally I always wanted to explore using nats.io, which is a message 
broker that also supports a request-reply pattern out of the box. That 
means a message channel/topic acts like a service. Nats has a 
nats-websocket library which connects browsers to the message broker and 
you can use protobuf or similar to define/generate your binary messages. 
Because you now have a message broker between clients and servers it should 
be relatively easy to scale and you get things like broadcast a message to 
all clients (push) with little effort. Nats also has a distributed KV store 
integrated if needed.

-- J.

Christian Hebert schrieb am Mittwoch, 10. Januar 2024 um 17:26:04 UTC+1:

> Hi guys, I've seen the changes in the new release regarding jakarta 
> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
> is still based on the Servlet API 3.1. 
>
> Prior of seeing that change, I tried to move away from RPC calls and use 
> http requests instead. I found a nice library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of 
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor 
> changes in my client code and voilà, I was able to deploy it on a Jakarta 
> Application server since there is no GWT involved on the server side 
> anymore. 
>
> The last version of RestyGWT has been release in 2020 so I'm not sure how 
> active this project is but from what I've seen it's enough for me.
>
> So, I would like to get your thoughts on that.  Would you go on that road? 
> stick to RPC calls and wait for a version of GWT based on Jakarta? build 
> your "own" GWT with the changes introduced in the vew version?
>

-- 
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/5aaec5f2-3d64-45fc-a3d6-63b0d310684fn%40googlegroups.com.

Re: Is moving away from RPC a good idea?

[Ralph Fiergolla]

Fully agree - and very much like the example!

Leon Pennings  schrieb am Fr. 12. Jan. 2024 um
14:59:

> I think moving away from gwt-rpc is a bad idea.
> A big advantage of GWT is that I can code everything in java and do not
> have to serialize anything to and from text.
> That to me is one of the usp's of GWT.
> Going from java -> json -> java (or gwt java), is like trying to have a
> complex conversation between 2 Dutch guys, but with a German translator in
> between.
>
>
>
>
> Op donderdag 11 januari 2024 om 16:20:32 UTC+1 schreef Vassilis Virvilis:
>
>> Hi Vegegoku,
>>
>> Thanks for clearing that up.
>>
>> At some point I will definitely try the domino-rest/jackson.
>>
>> For now I dread the time I will eventually be forced to port my current
>> setup.
>>
>>
>> On Thu, Jan 11, 2024 at 5:13 PM Vegegoku  wrote:
>>
>>> The annotation on the POJO is not required at all, Domino-rest will auto
>>> generate the json-mapping classes if the jax-rs/jakarata resource
>>> consumes/produces a json even if the annotation is missing, so you can keep
>>> the POJO clean or only have Jackson compatible annotations. ;-)
>>>
>>> On Thursday, January 11, 2024 at 11:35:05 AM UTC+3 Vassilis Virvilis
>>> wrote:
>>>
 First of all thanks for doing this work. It is hugely appreciated and
 required in order to avoid GWT and GWT projects look like zombies in a dead
 landscape.

 I am using RestyGWT and yes I also believe it uses Generators
 (GWT.create() ?). I am facing a problem there since RestyGWT is deadish
 itself.

 One of the reasons I abandoned GWT-RPC was Jsinterop. With Jsinterop
 you can include and link to js libraries in the client. Some of them
 require data from the backend e.g. datatables.net, d3 etc. GWT-RPC is
 not compatible with them so I would need to use RequestFactory, which I
 never liked or another framework. So why have two of them? Use one. Go to
 JSON. RestyGWT was the only viable choice at the time.

 With Resty-GWT I can have my POjOs *without annotations*, and I can
 share them between backend, frontend and other clients (non web). RestyGWT
 has 2 backends:
 - an older private jackson like (forked) implementation. That's the one
 I use.
 - a newer gwt-jackson based one. This one never worked for me.

 Furthermore I have invested in RestGWT and I have some custom patches
 so RestyGWT can transmit my generics.

 At this point domino-jackson and domino-rest looks like the way forward
 but from a quick look require annotations in the POJO and this is something
 that I would like to avoid.

 Just my 2 bits. Sorry if incoherent...




 On Wed, Jan 10, 2024 at 9:45 PM Michael Conrad 
 wrote:

> You should investigate the DominoKit project. They have a much more
> up-to-date JSON/Jackson-ish implementation.
>
> Ref: https://github.com/DominoKit/domino-rest
>
>
>
> On 1/10/24 11:26, Christian Hebert wrote:
>
> Hi guys, I've seen the changes in the new release regarding jakarta
> servlets, which is great, it's a step toward jakarta but to this day,  GWT
> is still based on the Servlet API 3.1.
>
> Prior of seeing that change, I tried to move away from RPC calls and
> use http requests instead. I found a nice library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor
> changes in my client code and voilà, I was able to deploy it on a Jakarta
> Application server since there is no GWT involved on the server side
> anymore.
>
> The last version of RestyGWT has been release in 2020 so I'm not sure
> how active this project is but from what I've seen it's enough for me.
>
> So, I would like to get your thoughts on that.  Would you go on that
> road? stick to RPC calls and wait for a version of GWT based on Jakarta?
> build your "own" GWT with the changes introduced in the vew version?
> --
> 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/8fa7dc19-2a15-442d-93b2-adebb947046cn%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-tool...@googlegroups.com.
>
 

Re: Is moving away from RPC a good idea?

[Leon Pennings]

I think moving away from gwt-rpc is a bad idea. 
A big advantage of GWT is that I can code everything in java and do not 
have to serialize anything to and from text.
That to me is one of the usp's of GWT.
Going from java -> json -> java (or gwt java), is like trying to have a 
complex conversation between 2 Dutch guys, but with a German translator in 
between. 




Op donderdag 11 januari 2024 om 16:20:32 UTC+1 schreef Vassilis Virvilis:

> Hi Vegegoku,
>
> Thanks for clearing that up.
>
> At some point I will definitely try the domino-rest/jackson.
>
> For now I dread the time I will eventually be forced to port my current 
> setup.
>
>
> On Thu, Jan 11, 2024 at 5:13 PM Vegegoku  wrote:
>
>> The annotation on the POJO is not required at all, Domino-rest will auto 
>> generate the json-mapping classes if the jax-rs/jakarata resource 
>> consumes/produces a json even if the annotation is missing, so you can keep 
>> the POJO clean or only have Jackson compatible annotations. ;-)
>>
>> On Thursday, January 11, 2024 at 11:35:05 AM UTC+3 Vassilis Virvilis 
>> wrote:
>>
>>> First of all thanks for doing this work. It is hugely appreciated and 
>>> required in order to avoid GWT and GWT projects look like zombies in a dead 
>>> landscape.
>>>
>>> I am using RestyGWT and yes I also believe it uses Generators 
>>> (GWT.create() ?). I am facing a problem there since RestyGWT is deadish 
>>> itself.
>>>
>>> One of the reasons I abandoned GWT-RPC was Jsinterop. With Jsinterop you 
>>> can include and link to js libraries in the client. Some of them require 
>>> data from the backend e.g. datatables.net, d3 etc. GWT-RPC is not 
>>> compatible with them so I would need to use RequestFactory, which I never 
>>> liked or another framework. So why have two of them? Use one. Go to JSON. 
>>> RestyGWT was the only viable choice at the time.
>>>
>>> With Resty-GWT I can have my POjOs *without annotations*, and I can 
>>> share them between backend, frontend and other clients (non web). RestyGWT 
>>> has 2 backends:
>>> - an older private jackson like (forked) implementation. That's the one 
>>> I use.
>>> - a newer gwt-jackson based one. This one never worked for me.
>>>
>>> Furthermore I have invested in RestGWT and I have some custom patches so 
>>> RestyGWT can transmit my generics.
>>>
>>> At this point domino-jackson and domino-rest looks like the way forward 
>>> but from a quick look require annotations in the POJO and this is something 
>>> that I would like to avoid.
>>>
>>> Just my 2 bits. Sorry if incoherent...
>>>
>>>
>>>
>>>
>>> On Wed, Jan 10, 2024 at 9:45 PM Michael Conrad  
>>> wrote:
>>>
 You should investigate the DominoKit project. They have a much more 
 up-to-date JSON/Jackson-ish implementation.

 Ref: https://github.com/DominoKit/domino-rest



 On 1/10/24 11:26, Christian Hebert wrote:

 Hi guys, I've seen the changes in the new release regarding jakarta 
 servlets, which is great, it's a step toward jakarta but to this day,  GWT 
 is still based on the Servlet API 3.1. 

 Prior of seeing that change, I tried to move away from RPC calls and 
 use http requests instead. I found a nice library called RestyGWT (
 https://resty-gwt.github.io/) who can really simplify the process of 
 handling json data from/to a Rest API.

 So I converted my GWT remote servlets to a Rest API, made a few minor 
 changes in my client code and voilà, I was able to deploy it on a Jakarta 
 Application server since there is no GWT involved on the server side 
 anymore. 

 The last version of RestyGWT has been release in 2020 so I'm not sure 
 how active this project is but from what I've seen it's enough for me.

 So, I would like to get your thoughts on that.  Would you go on that 
 road? stick to RPC calls and wait for a version of GWT based on Jakarta? 
 build your "own" GWT with the changes introduced in the vew version?
 -- 
 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/8fa7dc19-2a15-442d-93b2-adebb947046cn%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-tool...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/google-web-toolkit/156e77ff-25bd-4743-8798-0d0347d1866d%40newsrx.com
  
 

Re: Is moving away from RPC a good idea?

[Vassilis Virvilis]

Hi Vegegoku,

Thanks for clearing that up.

At some point I will definitely try the domino-rest/jackson.

For now I dread the time I will eventually be forced to port my current
setup.


On Thu, Jan 11, 2024 at 5:13 PM Vegegoku  wrote:

> The annotation on the POJO is not required at all, Domino-rest will auto
> generate the json-mapping classes if the jax-rs/jakarata resource
> consumes/produces a json even if the annotation is missing, so you can keep
> the POJO clean or only have Jackson compatible annotations. ;-)
>
> On Thursday, January 11, 2024 at 11:35:05 AM UTC+3 Vassilis Virvilis wrote:
>
>> First of all thanks for doing this work. It is hugely appreciated and
>> required in order to avoid GWT and GWT projects look like zombies in a dead
>> landscape.
>>
>> I am using RestyGWT and yes I also believe it uses Generators
>> (GWT.create() ?). I am facing a problem there since RestyGWT is deadish
>> itself.
>>
>> One of the reasons I abandoned GWT-RPC was Jsinterop. With Jsinterop you
>> can include and link to js libraries in the client. Some of them require
>> data from the backend e.g. datatables.net, d3 etc. GWT-RPC is not
>> compatible with them so I would need to use RequestFactory, which I never
>> liked or another framework. So why have two of them? Use one. Go to JSON.
>> RestyGWT was the only viable choice at the time.
>>
>> With Resty-GWT I can have my POjOs *without annotations*, and I can
>> share them between backend, frontend and other clients (non web). RestyGWT
>> has 2 backends:
>> - an older private jackson like (forked) implementation. That's the one I
>> use.
>> - a newer gwt-jackson based one. This one never worked for me.
>>
>> Furthermore I have invested in RestGWT and I have some custom patches so
>> RestyGWT can transmit my generics.
>>
>> At this point domino-jackson and domino-rest looks like the way forward
>> but from a quick look require annotations in the POJO and this is something
>> that I would like to avoid.
>>
>> Just my 2 bits. Sorry if incoherent...
>>
>>
>>
>>
>> On Wed, Jan 10, 2024 at 9:45 PM Michael Conrad  wrote:
>>
>>> You should investigate the DominoKit project. They have a much more
>>> up-to-date JSON/Jackson-ish implementation.
>>>
>>> Ref: https://github.com/DominoKit/domino-rest
>>>
>>>
>>>
>>> On 1/10/24 11:26, Christian Hebert wrote:
>>>
>>> Hi guys, I've seen the changes in the new release regarding jakarta
>>> servlets, which is great, it's a step toward jakarta but to this day,  GWT
>>> is still based on the Servlet API 3.1.
>>>
>>> Prior of seeing that change, I tried to move away from RPC calls and use
>>> http requests instead. I found a nice library called RestyGWT (
>>> https://resty-gwt.github.io/) who can really simplify the process of
>>> handling json data from/to a Rest API.
>>>
>>> So I converted my GWT remote servlets to a Rest API, made a few minor
>>> changes in my client code and voilà, I was able to deploy it on a Jakarta
>>> Application server since there is no GWT involved on the server side
>>> anymore.
>>>
>>> The last version of RestyGWT has been release in 2020 so I'm not sure
>>> how active this project is but from what I've seen it's enough for me.
>>>
>>> So, I would like to get your thoughts on that.  Would you go on that
>>> road? stick to RPC calls and wait for a version of GWT based on Jakarta?
>>> build your "own" GWT with the changes introduced in the vew version?
>>> --
>>> 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/8fa7dc19-2a15-442d-93b2-adebb947046cn%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-tool...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit/156e77ff-25bd-4743-8798-0d0347d1866d%40newsrx.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Vassilis Virvilis
>>
> --
> 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/4fc34b98-5504-4981-a942-ae633f4b77e9n%40googlegroups.com
> 

Re: Is moving away from RPC a good idea?

[Vegegoku]

The annotation on the POJO is not required at all, Domino-rest will auto 
generate the json-mapping classes if the jax-rs/jakarata resource 
consumes/produces a json even if the annotation is missing, so you can keep 
the POJO clean or only have Jackson compatible annotations. ;-)

On Thursday, January 11, 2024 at 11:35:05 AM UTC+3 Vassilis Virvilis wrote:

> First of all thanks for doing this work. It is hugely appreciated and 
> required in order to avoid GWT and GWT projects look like zombies in a dead 
> landscape.
>
> I am using RestyGWT and yes I also believe it uses Generators 
> (GWT.create() ?). I am facing a problem there since RestyGWT is deadish 
> itself.
>
> One of the reasons I abandoned GWT-RPC was Jsinterop. With Jsinterop you 
> can include and link to js libraries in the client. Some of them require 
> data from the backend e.g. datatables.net, d3 etc. GWT-RPC is not 
> compatible with them so I would need to use RequestFactory, which I never 
> liked or another framework. So why have two of them? Use one. Go to JSON. 
> RestyGWT was the only viable choice at the time.
>
> With Resty-GWT I can have my POjOs *without annotations*, and I can share 
> them between backend, frontend and other clients (non web). RestyGWT has 2 
> backends:
> - an older private jackson like (forked) implementation. That's the one I 
> use.
> - a newer gwt-jackson based one. This one never worked for me.
>
> Furthermore I have invested in RestGWT and I have some custom patches so 
> RestyGWT can transmit my generics.
>
> At this point domino-jackson and domino-rest looks like the way forward 
> but from a quick look require annotations in the POJO and this is something 
> that I would like to avoid.
>
> Just my 2 bits. Sorry if incoherent...
>
>
>
>
> On Wed, Jan 10, 2024 at 9:45 PM Michael Conrad  wrote:
>
>> You should investigate the DominoKit project. They have a much more 
>> up-to-date JSON/Jackson-ish implementation.
>>
>> Ref: https://github.com/DominoKit/domino-rest
>>
>>
>>
>> On 1/10/24 11:26, Christian Hebert wrote:
>>
>> Hi guys, I've seen the changes in the new release regarding jakarta 
>> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
>> is still based on the Servlet API 3.1. 
>>
>> Prior of seeing that change, I tried to move away from RPC calls and use 
>> http requests instead. I found a nice library called RestyGWT (
>> https://resty-gwt.github.io/) who can really simplify the process of 
>> handling json data from/to a Rest API.
>>
>> So I converted my GWT remote servlets to a Rest API, made a few minor 
>> changes in my client code and voilà, I was able to deploy it on a Jakarta 
>> Application server since there is no GWT involved on the server side 
>> anymore. 
>>
>> The last version of RestyGWT has been release in 2020 so I'm not sure how 
>> active this project is but from what I've seen it's enough for me.
>>
>> So, I would like to get your thoughts on that.  Would you go on that 
>> road? stick to RPC calls and wait for a version of GWT based on Jakarta? 
>> build your "own" GWT with the changes introduced in the vew version?
>> -- 
>> 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/8fa7dc19-2a15-442d-93b2-adebb947046cn%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-tool...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/156e77ff-25bd-4743-8798-0d0347d1866d%40newsrx.com
>>  
>> 
>> .
>>
>
>
> -- 
> Vassilis Virvilis
>

-- 
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/4fc34b98-5504-4981-a942-ae633f4b77e9n%40googlegroups.com.

Re: Is moving away from RPC a good idea?

[Vegegoku]

Domino-rest is up-to-date well documented and in our next release 
-Currently available in the HEAD-SNAPSHOT- we are moving to jakarta 
namespace.

Full documentation can be found in our website 
here https://dominokit.com/solutions/domino-rest/v1/docs/getting-started

On Wednesday, January 10, 2024 at 7:26:04 PM UTC+3 Christian Hebert wrote:

> Hi guys, I've seen the changes in the new release regarding jakarta 
> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
> is still based on the Servlet API 3.1. 
>
> Prior of seeing that change, I tried to move away from RPC calls and use 
> http requests instead. I found a nice library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of 
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor 
> changes in my client code and voilà, I was able to deploy it on a Jakarta 
> Application server since there is no GWT involved on the server side 
> anymore. 
>
> The last version of RestyGWT has been release in 2020 so I'm not sure how 
> active this project is but from what I've seen it's enough for me.
>
> So, I would like to get your thoughts on that.  Would you go on that road? 
> stick to RPC calls and wait for a version of GWT based on Jakarta? build 
> your "own" GWT with the changes introduced in the vew version?
>

-- 
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/b203501d-6b3c-4c77-ab6a-549be840a429n%40googlegroups.com.

Re: Is moving away from RPC a good idea?

['Frank Hossfeld' via GWT Users]

Using domino-rest, the POJO have usually only one annotation: @JSONMapper.

Vassilis Virvilis schrieb am Donnerstag, 11. Januar 2024 um 09:35:05 UTC+1:

> First of all thanks for doing this work. It is hugely appreciated and 
> required in order to avoid GWT and GWT projects look like zombies in a dead 
> landscape.
>
> I am using RestyGWT and yes I also believe it uses Generators 
> (GWT.create() ?). I am facing a problem there since RestyGWT is deadish 
> itself.
>
> One of the reasons I abandoned GWT-RPC was Jsinterop. With Jsinterop you 
> can include and link to js libraries in the client. Some of them require 
> data from the backend e.g. datatables.net, d3 etc. GWT-RPC is not 
> compatible with them so I would need to use RequestFactory, which I never 
> liked or another framework. So why have two of them? Use one. Go to JSON. 
> RestyGWT was the only viable choice at the time.
>
> With Resty-GWT I can have my POjOs *without annotations*, and I can share 
> them between backend, frontend and other clients (non web). RestyGWT has 2 
> backends:
> - an older private jackson like (forked) implementation. That's the one I 
> use.
> - a newer gwt-jackson based one. This one never worked for me.
>
> Furthermore I have invested in RestGWT and I have some custom patches so 
> RestyGWT can transmit my generics.
>
> At this point domino-jackson and domino-rest looks like the way forward 
> but from a quick look require annotations in the POJO and this is something 
> that I would like to avoid.
>
> Just my 2 bits. Sorry if incoherent...
>
>
>
>
> On Wed, Jan 10, 2024 at 9:45 PM Michael Conrad  wrote:
>
>> You should investigate the DominoKit project. They have a much more 
>> up-to-date JSON/Jackson-ish implementation.
>>
>> Ref: https://github.com/DominoKit/domino-rest
>>
>>
>>
>> On 1/10/24 11:26, Christian Hebert wrote:
>>
>> Hi guys, I've seen the changes in the new release regarding jakarta 
>> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
>> is still based on the Servlet API 3.1. 
>>
>> Prior of seeing that change, I tried to move away from RPC calls and use 
>> http requests instead. I found a nice library called RestyGWT (
>> https://resty-gwt.github.io/) who can really simplify the process of 
>> handling json data from/to a Rest API.
>>
>> So I converted my GWT remote servlets to a Rest API, made a few minor 
>> changes in my client code and voilà, I was able to deploy it on a Jakarta 
>> Application server since there is no GWT involved on the server side 
>> anymore. 
>>
>> The last version of RestyGWT has been release in 2020 so I'm not sure how 
>> active this project is but from what I've seen it's enough for me.
>>
>> So, I would like to get your thoughts on that.  Would you go on that 
>> road? stick to RPC calls and wait for a version of GWT based on Jakarta? 
>> build your "own" GWT with the changes introduced in the vew version?
>> -- 
>> 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/8fa7dc19-2a15-442d-93b2-adebb947046cn%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-tool...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/156e77ff-25bd-4743-8798-0d0347d1866d%40newsrx.com
>>  
>> 
>> .
>>
>
>
> -- 
> Vassilis Virvilis
>

-- 
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/1f442a59-8e19-427e-84c1-9a3914cfe08bn%40googlegroups.com.

Re: Is moving away from RPC a good idea?

[Vassilis Virvilis]

First of all thanks for doing this work. It is hugely appreciated and
required in order to avoid GWT and GWT projects look like zombies in a dead
landscape.

I am using RestyGWT and yes I also believe it uses Generators (GWT.create()
?). I am facing a problem there since RestyGWT is deadish itself.

One of the reasons I abandoned GWT-RPC was Jsinterop. With Jsinterop you
can include and link to js libraries in the client. Some of them require
data from the backend e.g. datatables.net, d3 etc. GWT-RPC is not
compatible with them so I would need to use RequestFactory, which I never
liked or another framework. So why have two of them? Use one. Go to JSON.
RestyGWT was the only viable choice at the time.

With Resty-GWT I can have my POjOs *without annotations*, and I can share
them between backend, frontend and other clients (non web). RestyGWT has 2
backends:
- an older private jackson like (forked) implementation. That's the one I
use.
- a newer gwt-jackson based one. This one never worked for me.

Furthermore I have invested in RestGWT and I have some custom patches so
RestyGWT can transmit my generics.

At this point domino-jackson and domino-rest looks like the way forward but
from a quick look require annotations in the POJO and this is something
that I would like to avoid.

Just my 2 bits. Sorry if incoherent...




On Wed, Jan 10, 2024 at 9:45 PM Michael Conrad  wrote:

> You should investigate the DominoKit project. They have a much more
> up-to-date JSON/Jackson-ish implementation.
>
> Ref: https://github.com/DominoKit/domino-rest
>
>
>
> On 1/10/24 11:26, Christian Hebert wrote:
>
> Hi guys, I've seen the changes in the new release regarding jakarta
> servlets, which is great, it's a step toward jakarta but to this day,  GWT
> is still based on the Servlet API 3.1.
>
> Prior of seeing that change, I tried to move away from RPC calls and use
> http requests instead. I found a nice library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor
> changes in my client code and voilà, I was able to deploy it on a Jakarta
> Application server since there is no GWT involved on the server side
> anymore.
>
> The last version of RestyGWT has been release in 2020 so I'm not sure how
> active this project is but from what I've seen it's enough for me.
>
> So, I would like to get your thoughts on that.  Would you go on that road?
> stick to RPC calls and wait for a version of GWT based on Jakarta? build
> your "own" GWT with the changes introduced in the vew version?
> --
> 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/8fa7dc19-2a15-442d-93b2-adebb947046cn%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/156e77ff-25bd-4743-8798-0d0347d1866d%40newsrx.com
> 
> .
>


-- 
Vassilis Virvilis

-- 
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/CAKbOjEy6q14UbmhrQYj-4CrTD6QjFwuygPxM757DjD4%3DkRs1dg%40mail.gmail.com.

Re: Is moving away from RPC a good idea?

[Colin Alworth]

With 2.11 released, GWT-RPC (and RequestFactory) work on jakarta.servlet. 
There are no specific improvements that I'm aware of that require updating 
beyond the Servlet API 5.0, which is what gwt-servlet-jakarta uses.

I _believe_ that RestyGWT relies on Generators, so might make an eventual 
move to J2CL difficult, if that happens to be on your radar.

My personal experience is that GWT-RPC is imperfect in a lot of ways, but 
for the kinds of things that GWT excels at, I still often find it to be 
better than the other options. It is explicitly for GWT clients, and it 
uses the shared DTO types as the source of truth for how to de/serialize, 
so it ensures a certain consistency that way. 

JSON-over-HTTP (whether actual REST or not) has me missing real object 
graphs, numerical precision (somehow JSON's spec allows for infinite 
precision for ints/floats, but forgot to add infinity/nan? and yet the JS 
runtime cuts off that precision to what fits in an IEEE754 64bit float...), 
no date/time support, and not terribly efficient for large payloads. It 
does a pretty great job of being okay in any language/runtime though, but 
it isnt hard to get subtle serialization differences, and end up needing 
not just a schema to share (openapi/swagger/etc can help with this), but 
also deciding what those conventions will be. JSON can also work well over 
other transports, such as websockets - same basic limitations as with HTTP, 
but depending on your use case could well be worth examining.

I've had a lot of close-up experiences with gRPC lately (protobufs, 
flatbufs, and Apache Arrow's Flight protocol in GWT), and I nearly like it, 
aside from the abysmal support for browser clients. gRPC offers some tools 
that at least REST doesn't - streaming data being the main one, and overt 
RPC calls rather than relying on consistent definitions of REST verbs 
(which is wonderful when done right, but most teams using "REST" are 
usually just "JSON-over-HTTP RPC"). This could be (and may yet be someday) 
a whole article by itself someday, but gRPC is outright incompatible with 
browsers without first translating to gRPC-web usually requiring a proxy 
between server and JS client), the default JS client can't do stream server 
data with binary formatting (only text formatting allowed), and the browser 
itself can't handle bidirection streaming at all. But you define your 
services and types outside of any language, each language gets bindings 
generated for it which will be consistent with all other languages, and, if 
used properly, clients/servers are forwards and backwards compatible with 
each other. Some niceties like subclasses, nullable collections and strings 
aren't available or at least hard to reproduce in a recognizable way. There 
is also no good code generation for GWT at this time, so we've been 
operating using generated jsinterop from the grpc and proto libraries and 
generated code, with decent success. If you are interested in pursuing 
gRPC, we have worked on a servlet (jakarta and javax) implementation of 
gRPC, and a servlet filter implementation that in-process handles the 
grpc-web translation. We also worked up a websocket implementation that 
behaves like an http2 transport, with multiple concurrent streams running 
on it, even over http/1.1.

One final note: we forked gwt-rpc  a 
few years ago to provide a binary wire format and built-in websocket 
support. The focus of our use case was on "struct-like" types, avoiding 
most collections and polymorphism, but the implementation can still handle 
most situations that regular GWT-RPC can deal with, but without writing to 
utf-8 strings (offering a significant performance improvement for large 
payloads), and allowing interop with non-GWT clients (JVM and android 
clients are provided, TeaVM works in our experiments, but hasn't been 
published, and there are closed source c++ and c# clients as well). I 
haven't updated this to use jakarta.servlet yet, but I imagine it would 
take less than a day to start and finish it.

On Wednesday, January 10, 2024 at 1:45:31 PM UTC-6 Michael Joyner wrote:

> You should investigate the DominoKit project. They have a much more 
> up-to-date JSON/Jackson-ish implementation.
>
> Ref: https://github.com/DominoKit/domino-rest
>
>
>
>
> On 1/10/24 11:26, Christian Hebert wrote:
>
> Hi guys, I've seen the changes in the new release regarding jakarta 
> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
> is still based on the Servlet API 3.1. 
>
> Prior of seeing that change, I tried to move away from RPC calls and use 
> http requests instead. I found a nice library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of 
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor 
> changes in my client code and voilà, I was able to deploy it on a Jakarta 
> Application 

Re: Is moving away from RPC a good idea?

[Michael Conrad]

You should investigate the DominoKit project. They have a much more 
up-to-date JSON/Jackson-ish implementation.


Ref: https://github.com/DominoKit/domino-rest



On 1/10/24 11:26, Christian Hebert wrote:
Hi guys, I've seen the changes in the new release regarding jakarta 
servlets, which is great, it's a step toward jakarta but to this day, 
 GWT is still based on the Servlet API 3.1.


Prior of seeing that change, I tried to move away from RPC calls and 
use http requests instead. I found a nice library called RestyGWT 
(https://resty-gwt.github.io/) who can really simplify the process of 
handling json data from/to a Rest API.


So I converted my GWT remote servlets to a Rest API, made a few minor 
changes in my client code and voilà, I was able to deploy it on a 
Jakarta Application server since there is no GWT involved on the 
server side anymore.


The last version of RestyGWT has been release in 2020 so I'm not sure 
how active this project is but from what I've seen it's enough for me.


So, I would like to get your thoughts on that.  Would you go on that 
road? stick to RPC calls and wait for a version of GWT based on 
Jakarta? build your "own" GWT with the changes introduced in the vew 
version?

--
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/8fa7dc19-2a15-442d-93b2-adebb947046cn%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/156e77ff-25bd-4743-8798-0d0347d1866d%40newsrx.com.

Is moving away from RPC a good idea?

[Christian Hebert]

Hi guys, I've seen the changes in the new release regarding jakarta 
servlets, which is great, it's a step toward jakarta but to this day,  GWT 
is still based on the Servlet API 3.1. 

Prior of seeing that change, I tried to move away from RPC calls and use 
http requests instead. I found a nice library called RestyGWT 
(https://resty-gwt.github.io/) who can really simplify the process of 
handling json data from/to a Rest API.

So I converted my GWT remote servlets to a Rest API, made a few minor 
changes in my client code and voilà, I was able to deploy it on a Jakarta 
Application server since there is no GWT involved on the server side 
anymore. 

The last version of RestyGWT has been release in 2020 so I'm not sure how 
active this project is but from what I've seen it's enough for me.

So, I would like to get your thoughts on that.  Would you go on that road? 
stick to RPC calls and wait for a version of GWT based on Jakarta? build 
your "own" GWT with the changes introduced in the vew version?

-- 
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/8fa7dc19-2a15-442d-93b2-adebb947046cn%40googlegroups.com.