Proxy Your Requests With Grunt

Probably you’re already using grunt to serve your local frontend code. Everything is fine, but if you’re developing your backend with something different than JavaScript (Being a Java developer I heard that might happen), you will have problems accessing this backend while running grunt server.
With grunt-connect-proxy there exists a grunt module to help you out. It basically delegates requests that match a given URL to a different backend of your choice. Unfortunately I found it rather difficult to configure, if you are unaware of the connect middleware concept.

Basically you just need to add two things to your Gruntfile.js file:

Firstly add the connect server configuration to your config JSON inside of grunt.initConfig. This example delegates all requests to http://localhost:8000/services to http://localhost:8090/services – keep in mind the grunt server is running on port 8000 and the backend on port 8090:

Secondly register your grunt server task:

then you can call your grunt server with the configured proxy via :
grunt server
from the command line.


Using Google App Engine as Backend for Android

If you’re looking for a way to create a backend for your Android application, Google App Engine looks like the perfect choice: You can use Java as you can do for Android and you don’t need to think too much about hosting, as it is all stored in the cloud.

Another benefit is that you can reuse your transfer objects on the client and on server side. But as it is often there are some problems doing this in practice. So you don’t have the same ones I had, I am glad to share my experiences with you.

So first question is what libraries are to use for the client/server communication. At start I tried Restlet 2.0. Looked like a great choice as there are special editions for App Engine and for Android available. In practice it is not very useful as the libraries are to big for Android and I also very much disliked that fully serialized java objects are transfered.

Best approach I found so far is to use Jersey 1.6: It is easy to use and implements the JAX-RS (JSR 311) standard. To set it up on the App Engine, please consult these blog posts from me: Using real POJOs (without JAXB Annotations) as transfer objects with JAX-RS and Storing large images RESTful in the cloud using Google App Engine.

Ok, so far about the server side. To keep things small and simple on the Android side, I mainly created the following wrapper class for the HttpClient to handle the HTTP requests:

This implementation is far from perfect, especially exception handling and passing parameters need to be improved, but it works so far :)

Using this class it is easy to store a file using the FileServerResource from my former blog post. Just call:

Also it is easy to store a transfer object using the doPut method. Note that is is using the ObjectMapper class from Jackson, the same JSON processor that is also used by Jersey.
Jackson is therefore the only additional library that you need on the Android side which keeps the executable small. If you use the same version of Jackson on the client side as on the server side you’re also ensured that the (un-)marshalling process of your transfer objects works flawlessly on both sides.

Hope you liked this approach – feel free to discuss here further ideas.