CODEWITHSUNDEEP
google-app-enginerest
James Fassett
James Fassett

Reputation: 41044

Use REST interface for internal Google AppEngine queries

I have started writing a REST API for my Google AppEngine application. I read a good article on architecting REST applications that suggested I encapsulate my data services behind a REST api. Considering I'd like to be prepared to move to an architecture like Amazon Web Services if the prototype gains traction this level of encapsulation makes sense.

The idea is a request comes in for a web-page and the application server accepts the HTTP request. Then the application server itself makes a HTTP REST request to the database server instead of going directly through Datastore objects. In the case of Google AppEngine it is actually the same server but it would be easy to change what server (or cluster of servers) would actually respond to data requests.

For example:

  1. http://example.com/index.html
    • results in HTTP request handled by app server
  2. http://example.com/remote/data?filter=all
    • app server makes a call for data from remote server
  3. App server
    • parses remote response
    • inserts data into HTML template
    • returns result to client

Note: this doesn't include any caching I'd have.

This means that for a single client HTTP request I may end up making 4-5 additional HTTP requests to build a response. Is this an architectural pattern that will work well on Google AppEngine or in general? Does Google handle internal requests (appserver instance-appserver instance) in an efficient manner?

Upvotes: 4

Views: 1123

Answers (2)

Adam Crossland
Adam Crossland

Reputation: 14213

This pattern does not make a lot of sense for AppEngine.

Consider that there are fixed limits for some AppEngine resources, such as URLFetch that may be rapidly depleted. Also, resources that are billable, such as CPU Time, incoming bandwidth and outgoing bandwidth will all be used at a much faster rate than is reall necessary.

Moreover, it dramatically limits your AppEngine application's ability to scale. In fact, it is a negative feedback loop. As the number of external requests increases, the load on your application is going to go up very steeply. That is the antithesis of what you should be trying to achieve with your AppEngine application.

Finally, I'd suggest that this is a dubious architecture for an application on any platform, not just AppEngine. It is easy for software engineers to fall in love with abstraction, producing layers-upon-layers for the sake of values like modularity, portability, loose-coupling -- the list goes on-and-on. However, any decision made for an abstract reason that results in a very real and dramatic degradation in performance is a de facto anti-pattern.

Upvotes: 3

maximbr
maximbr

Reputation: 451

First architecture-wise it's OK to build a REST data access layer above a storage see Microsoft's Azure docs for example http://msdn.microsoft.com/en-us/library/dd179423.aspx

Naturally you will encounter some sort of performance hit when moving outside the app engine and making your queries via urlfetch. I would suggest comparing the billing on datastore vs urlfetch before making the move.

If you do create a DAL to make these REST calls to a remote DB, there is no reason to actually make urlfetches to you GAE datastore. Simply write an app engine provider that makes these DB call directly with DataStore API http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/datastore/package-summary.html

Upvotes: 1

Related Questions