How to work with Front-end and back-end in Google App Engine

Posted by in Programming

A new entrance about Google App Engine, and this time let’s see their components. In the next image you can see the architecture of Google App Engine, since a request starts, and what happend in miliseconds for the user.

Google App Engine

Google App Engine

One of the characteristics of using GAE is using Google infraestructure, that is, using their datacenters, and this is a really good advantage for you and for your application, because users receive their request from the closest datacenter, where Google Front End ask to Edge Cache (this is the ‘key’ technology inside Googles quick response. You have more information here).

App Master

App Master

Google Front End fron one datacenter comunicates with App Engine Front End of the datacenter where the app is located, and its role is to communicate with the instance of your application, managed by App Master.

the second characteristics you must know is static servers, who’s mission is to serve only static content and all defined as static in app.yaml, also in static_dir or static_files. That’s very important because that’s what accelerates responses!

App Engine front-end

One of the advantages of front-end in GAE is that the work needed to the machine is about 10% of the volume, basically because the app defines static content, and instances are created and deleted dinamically. That’s the clue to quick responses, and of course, this happend because of Google (because the user cannot configure anything!).

App Engine Back-end

The back-end part of App Engine let you execute batch processes, and other tasks.

App Master

Maybe it’s the least known, but the truth is that App Master manages everything, the static content of static servers, the App Engine Front End, and the App Server, apart from instances to the application (depending on the demand of requests).

The application instances can be defined as virtual machines because they provide the environment to the execution of the app, dedicated memory (of course, all under control, but users don’t have to bother of this issue, becuase it’s Google mission: operating system of a instance, management, updates, security, … the best engineer of the world are working for you!) at your service.

Front end instances

They are the ones that are more limited, because any application that has only 60 seconds per request. Every application has a queue of requests, managed by the app instances. When the queue is full, they are generated Front-end instances to respond very quickly to this demand. You must set two properties for queues: queue latency, and idle instances, which is the number of instances that have active, where you can set a minimum and a maximum.

Back-end instances

The back-end part is statically created and deleted, which means a higher cost, but in return, it is highly desirable to perform batch procesoss, including cron programming tasks,

The response time is key in all of this for instance management. When time is exceeded, a new instance representing the load libraries, etc, etc before starting to provide service starts. Typically, the response time is less than a second, but if you have to load too many libraries, this response time may be extended to 30 or 60 seconds, depending on the needs of the application.

And last ….

All you have read hear can be seen as too complext for a developer, but it’s good to know the basement of Google App Engine. Here you have a PDF file with more information, and here another document with even more.

It’s not easy, I know …. but I have to tell you!