App Engine - RequestFactory vs. Servlets vs. Other Approaches

Question

Our team is working on an Android application ending with App Engine. We have a certain difference of opinion regarding the implementation of client-server communication. On the one hand, App Engine offers a RequestFactory approach, which (as Google says)

provides a solid foundation for automatic batching and caching of requests in the future

and light-weighed

But we find this approach a little "awkward." On the other hand, we can use the usual servlet approach, which we know well and feel more comfortable with. We really want an easier , faster, and scalable message, but in what proportion does RequestFactory really provide them? What else can we gain and lose from both approaches.

[Moreover, we read about parameters such as GWT-RPC (an older version of RequestFactory) and RestyGWT. But we know little about these approaches and are not sure whether they fit our cause.]

I found here some similar questions that I did not answer. Therefore, I suggest that this may be a useful discussion for many.

Answer 1

A few notes:

• RequestFactory is not part of AppEngine (see here ), but it is an add-on provided by the latest Android Eclipse plugin. RequestFactory was originally created for GWT.

• The RequestFactory surface is something that works easily with GWT and Android.

• The disadvantage is that it is not cross-platform, i.e. not available for iPhone etc.

• It is not clear how the RequestFactory version is. If your application is large and evolving, you must have two or more versions of the RPC APIs serving the clients. GWT clients can easily be forced to use the latest API (= page reload), rather than Android. AFAIK, there is no way to have two RequestFactory endpoints. With REST, you can simply have multiple URLs for different versions of the API.

• Mixing public / private APIs. Since there are no RequestFactory endpoints, you cannot easily divide them into public (without authorization) and private / secure (= auth required). With REST (and GWT-RPC), you can simply have two servlets (private and public) and set security restrictions in web.xml (or have your own servlet filter).

• RequestFactory does not support java.util.Map . This greatly limits the ability to have objects with dynamic properties - there are workarounds for this, but they are IMO - an unnecessary kludge (for example, the presence of two lists, one for keys and the other for values).

Solution: this is the solution that I use in my projects:

• Create a service level that returns POJO domain objects.

• Create an RPC layer that invokes the service layer. You can use multiple RPC technologies for the same level of service. Usually I have GWT-RPC and REST.

• Using POJO-only domain objects is sometimes impossible (also due to JPA / JDO), which forces you to create a DTO. DTO is a pain to maintain, and I try to avoid them if possible. In most cases, you can use domain objects with some workarounds: on AppEngine you can get a lot of help using Objectify instead of low-level / JPA / JDO. It supports GWT-RPC . With REST, I suggest you use Jackson, where you can perform all kinds of custom conversions .