Question

I recently watched several Google I/O videos where Google developers present GWT with respect to performance and security. In that video the speaker makes mention of several GWT-isms:

• Client-side request “batching”
• “Disposability”
• The pursuit of GWT app “statelessness”

With respect to “batching” it seems like GWT can be configured to queue-up server-side RPC calls and send them all at once (instead of many tiny, performance-hindering calls). Unfortunately, I’m just not seeing the forest through the trees here: doe GWT handle batching for you, or do you have to write the logic that performs this bundling/batching? If you have to do it, what kinds of calls can/should be bundled? How do you know when its time to fire the batch off?

In GWT lingo, what does it mean when someone says:

• “Clients and servers are disposable”; but
• “Views” are not disposable

How does this concept of “batching” and “disposability” relate to GWT app “statelessness”. By that, the speaker defined statelessness as:

• Browser embodies the session (?!?!)
• Server is stateless – except for caching (?!?!)
• Client never notices a restart (?!?!)

If someone could help give me concrete understanding of these 3 items and how they relate to each other I think I’ll start to “get gwt”. Thanks in advance!

Answer 1

doe GWT handle batching for you, or do you have to write the logic that performs this bundling/batching? If you have to do it, what kinds of calls can/should be bundled? How do you know when its time to fire the batch off?

GWT-RPC has no batching mechanism. You can (relatively) easily add some by queueing “commands” in a list and then sending the list as a single GWT-RPC call. Some projects should do that for you with minimal effort (GWT-Platform for example).

RequestFactory on the other hand has batching built-in: you create a RequestContext instance and batch calls to it until you fire() it.

“Clients and servers are disposable”; but “Views” are not disposable

The first is related to statelessness (and, for example, with AppEngine, you don’t control when a new server instance is created, shutdown or restarted: the server can disappear at any time, so don’t keep state in memory).
The second is about performance: everything related to the DOM in the browser is slow, so constructing a new view (widgets stacked together) is heavy-weight (less so with Cell widgets though). As a result, you don’t want to make them disposable, i.e. throw them away every now and then. You’ll rather want to keep one view instance around that you reuse for the lifetime of the app.
Not exactly the same notion of “disposability”.

Browser embodies the session (?!?!)

GWT is built of single-page apps. You can store state on the client simply in variables in your app; you don’t need cookies or whatever to have the state shared between pages.

Server is stateless – except for caching (?!?!)

Storing session state on the server has a cost (state must be persisted –particularly if the server is disposable–, shared between servers –when you have a cluster / run in the cloud–, etc. you’ll spend as many resources keeping existence of your session state as doing actual business logic).

Client never notices a restart (?!?!)

HTTP is a a disconnected protocol. If the server is restarted, the client won’t know about it, and it shouldn’t have to know about it.

If someone could help give me concrete understanding of these 3 items and how they relate to each other I think I’ll start to “get gwt”.

It’s not about getting GWT, it’s about getting the Web and getting single-page webapps, and how to scale them.
Whether they’re made with GWT or jQuery on the client-side, and Java or Python or .NET on the server-side doesn’t matter.

Read about REST, it sums it all.