Update README.md #82
Update README.md #82
Conversation
I was confused of what are the 2 artefacts, so updated the documentation
tbroyer
left a comment
tbroyer
left a comment
There was a problem hiding this comment.
While I don't disagree about adding a quick description of "modular-webapp uses GWT RPC", this is going a bit too far.
At this point in time I'm not quite ready to make any change here more than a handful words.
README.md
Outdated
| in their client-server communication approach: | ||
|
|
||
| - `modular-webapp`: Uses traditional GWT RPC (Remote Procedure Call) | ||
| - Client communicates via RemoteService interface with @RemoteServiceRelativePath |
There was a problem hiding this comment.
This sublist is not needed IMO, that's more or less the definition of GWT RPC.
README.md
Outdated
| - More modern, supports data validation and has better performance for complex data models | ||
|
|
||
| Both create modular multi-module Maven projects with client, server, and shared modules, but RequestFactory is the newer, | ||
| more efficient approach for GWT applications. |
There was a problem hiding this comment.
I disagree with that characterization. RF implementation is complex and hard to maintain, and is today unmaintained in practice.
A "modern" approach would likely use web APIs with JSON (so called "REST APIs"), but otherwise I'd recommend RPC over RF nowadays.
That said, I don't want to be prescriptive other than about the client/shared/server separation.
There was a problem hiding this comment.
Totally hear you! Thanks for providing your point of view.
I am returning back to GWT projects after being into other platforms for quite some time - hence my confusion over the RF approach. The only reason I added this info is just the research I made - which is def not extensive.
I'll remove the section.
Question though. You say:
I don't want to be prescriptive other than about the client/shared/server separation.
but it looks like client/shared/server separation is pretty much the same between RPC vs RF? Do you mind providing more info?
There was a problem hiding this comment.
Question though. You say:
I don't want to be prescriptive other than about the client/shared/server separation.
but it looks like client/shared/server separation is pretty much the same between RPC vs RF? Do you mind providing more info?
Well this is actually exactly my point: the archetypes are there for that client/shared/server separation, whichever flavor you choose, and I don't want to tell anyone which one to pick (the raison d'être of the RF archetype is that it has specific needs, otherwise there'd only be one archetype)
There was a problem hiding this comment.
@tbroyer let me confirm I understand everything correctly:
Because of the differences how RF and RPC are implemented, there are 2 different artifacts. Engineers who already know which approach they want - know what artifact to select.
I guess we still need the minimal info to help engineers who are not overly familiar with both PRC and RF to select the archetypeArtifactId option? I mean people like me :-)
There was a problem hiding this comment.
https://gwtproject.org is where that information lives (or should)
|
I totally onboard with what you say. I'll shorten the info into a smaller section |
2 participants
I was confused of what are the 2 artefacts, so updated the documentation a little.