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 <https://github.com/vertispan/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 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 > > <https://groups.google.com/d/msgid/google-web-toolkit/8fa7dc19-2a15-442d-93b2-adebb947046cn%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 google-web-toolkit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/a3cba2c8-a888-4889-bac6-db33b9598905n%40googlegroups.com.
