Use the REST interface for internal Google AppEngine queries.

Question

I started writing a REST API for my Google AppEngine application. I read a good article on the architecture of REST applications, which suggested that I encapsulate my data services with a REST api. Given that I would like to be ready to move on to an architecture such as Amazon Web Services, if the prototype gets traction, this level of encapsulation makes sense.

The idea is a request to a web page, and the application server accepts the HTTP request. Then, the application server itself makes an REST HTTP request to the database server instead of directly accessing the Datastore objects. In the case of Google AppEngine, this is actually the same server, but it would be easy to change which server (or server cluster) will respond to data requests.

For instance:

• http://example.com/index.html
  • results in an HTTP request processed by the application server.
• http://example.com/remote/data?filter=all
  • The application server calls data from a remote server.
• Apps server
  • parses a remote response
  • inserts data into an HTML template
  • returns the result to the client

Note. This does not apply to the caching that I would have.

This means that for a single client HTTP request, I can create 4-5 additional HTTP requests to create a response. Is this an architectural template that will work well on Google AppEngine or in general? Does Google develop internal queries (instance of application instance instance) in an efficient manner?

Answer 1

This template does not make much sense for AppEngine.

Note that there are fixed restrictions for some AppEngine resources, such as URLFetch, that can be quickly exhausted. In addition, resources that can be paid, such as processor time, inbound bandwidth, and outbound bandwidth, will be used at a much higher speed than required.

In addition, it severely limits the scalability of the AppEngine application. In fact, this is a feedback loop. As the number of external requests increases, the load on your application will grow very steeply. This is the opposite of what you should try to achieve with the AppEngine app.

Finally, I would suggest that this is a dubious architecture for an application on any platform, not just AppEngine. Software engineers easily fall in love with abstraction, creating layers on layers for the sake of values ​​such as modularity, portability, decoupling - the list goes at the same time. However, any decision made for an abstract reason that results in a very real and dramatic performance degradation is a de facto anti-pattern.

Answer 2

Primarily with architecture, to create a REST data access layer above the repository, see Microsoft Azure docs, for example http://msdn.microsoft.com/en-us/library/dd179423.aspx

Naturally, you will encounter some kind of effect when you move beyond the application mechanism and make your requests through urlfetch. I would suggest comparing data warehouse billing versus urlfetch before making a move.

If you create a DAL to make these REST calls to a remote database, there is no reason to really do urlfetches for your GAE data store. Just write an application provider that makes these DB calls directly with the DataStore API http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/datastore/package-summary.html