BinaryMuse

This post is part of the “ITworks Design Journal” series.

In a prior post, I mused about the advantages and disadvantages of using GWT’s RPC implementaion for server-side communication versus something like another server-side technology with JSON. I went and found some folks more experienced with GWT than I, did some reading, talked with some fellow programmers, and generally just absorbed information.

One thing someone advised me that really stuck in my mind was the following (keep in mind I use GXT’s widget library for GWT):

With GWT you give up the flexibility and the instant “make-change-hit-refresh” development workflow of dynamic languages like PHP and JavaScript in exchange for Java’s static type checking, reliable code refactoring, mature IDE support, and end-to-end debugging. If you aren’t going to benefit from Java on the server and GWT RPC functionality then you might be better off sticking to PHP and straight Ext JS. If you are using GWT just for GXT’s sake then you should definitely consider this.

Emphasis mine.

One of the things I don’t like about creating rich web apps is figuring out how the server will talk to the client. Everything has to be serialized, one way or another, and sent to the client, where it is reassembled. JSON is a popular choice because it is a subset of JavaScript, and thus the response can be eval()’d on the client-side for quick deserialization. GWT RPC does all this for you.

So, I decided to do a bit of tweaking to find out how hard it would be to implement my existing server-side technologies in Java, using RPC for communication. It didn’t take long to get LDAP authentication working, and SQL connectivity was quite easy (though I’m looking into additional libraries now).

I really like the way RPC feels. GWT handles all the serialization for me; I just call a function, pass a callback, and I get the data I want back. It’s quite nice. After some consideration, I decided to use Java for my server-side technology and use RPC for client-server communication. This will also give me an opportunity to learn more about Java and other projects (like Spring) for it.

As a comparison, here is some pseudocode for my user authentication script, before and after.

Before (JSON)

Client side

1. Get a new RequestBuilder
2. Quote username, password, and domain parameters
3. Add username, password, and domain parameters to the request
4. Create a new callback that does the following:
   1. Check the status code of the response
   2. On "200", parse the response text:
      1. Check that the JSON is valid
      2. Retrive the keys "auth", "name", "access" in the case of a successful login
      3. Retrieve the keys "auth", "message" in the case of an unsuccessful login
   3. On other statuses or exceptions, create an "error response"
   4. Send the right event to the controllers responsible for handling login responses
5. Send the request to the server

Server side

1. Connect to LDAP source, find user, gather information, etc
2. Build a set of data with this information
3. Transform data into valid JSON

After (RPC)

Client side

1. Create an instance of the authentication RPC class
2. Create a callback that does the following:
   1. Set appropriate data based on the User object returned from the RPC method
   2. Send the right event to the controllers responsible for handling login responses
3. Call the method on the RPC class and pass in my current User object, receiving a modified User object in return

Server side

1. Create plumbing interfaces, classes, and methods for the remote service
2. In the server-side method, connect to LDAP source, find user, gather information, etc
3. Put this data into a User object the client already uderstands and return it

GWT has it’s own small set of hoops. For every service, you need (1) an interface MyService that extends RemoteService that defines your methods for your remote service, (2) an interface MyServiceAsync that has a method that takes a second parameter AsyncCallback<MyReturnType> for the actual RPC call itself, and (3) MyServiceImpl, which is the actual server-side implementation of your service. However, the hoops really are pretty small. Here are examples of my code:

AuthenticationService.java

@RemoteServiceRelativePath("authenticateUser")
public interface AuthenticationService extends RemoteService {
    User authenticateUser(User user);
}

AuthenticationServiceAsync.java

public interface AuthenticationServiceAsync {
    void authenticateUser(User user, AsyncCallback<User> callback);
}

AuthenticationServiceImpl.java

public class AuthenticationServiceImpl extends RemoteServiceServlet implements AuthenticationService
{
    @Override
    public User authenticateUser(User user)
    {
        // Actual implementation here
    }
}

When you use GWT RPC, your server-side code is Java–so you also get (very large) debugging benefits. For example, I use Eclipse as my IDE of choice and I debug my code using GWT’s HostedMode (which runs an internal Jetty server to serve up your server-side Java). I can add breakpoints at any point in my client or server-code and debug it right from the IDE (this was actually a huge help when learning to connect to LDAP from Java).

I’m excited about learning more about Java and frameworks like Spring (which I think I will use for my database connectivity). More to come later!