0

I'm using Google App Engine with Java runtime. I'm not too clear about the routing policy Google is enforcing. And web searches have only yielded misleading and discordant results in my case. According to Google documentation:

App Engine runs multiple instances of your application, each instance has its own web server for handling requests. Any request can be routed to any instance, so consecutive requests from the same user are not necessarily sent to the same instance. The number of instances can be adjusted automatically as traffic changes.

That's pretty clear. And it lets me think that URL rewriting I define in my development server will be applied after this higher level routing, meaning when a request actually reaches one of the many potentially available app server instances. However, I then stumbled upon a thread in which it's argued that URL rewrite using the Tuckey's URL Rewrite plugin is troublesome in that it cuts out Google's content delivery network for so-called static files.

So my questions are: - Given that the request gets to the server after being routed, what's the matter of rewriting the URL? Server level rewriting shouldn't have any impact on the top level Google's routing. - Google says that static files are stored in different servers having nothing to do with the real application, so you basically don't know there they are. Does this means that if a request for one of these static files comes in, the actual resource is requested to one of these reserved servers and only other requests (including missing resources and invalid URLs coming from pushstate) actually reaches my app's server instances?

It all this was true, I wouldn't see any real performance risk in rewriting URLs at server instance level.

Community
  • 1
  • 1
Luca Poddigue
  • 1,023
  • 2
  • 10
  • 20
  • 1
    That thread you refer too, hi-lights the only area of re-writing your probably want to avoid, and that is for static resources. There is no problem mapping various urls that should resolve to your application code. So its refering to static images/js/css – Tim Hoffman Feb 13 '16 at 08:06
  • But html pages are also static resources. My use case is managing pushstate requests, whose URLs are invalid per se. Provided that what I said above is true, I would conclude the CDN is cut out only for invalid URLs like pushstate requests, but other stuff like you say shouldn't be affected. – Luca Poddigue Feb 13 '16 at 08:46
  • No idea what your trying to do. I think you need actually explain what it is attempting to achieve. A html page could be static or dynamically generated. In appengine you would typically use a static handler for a static html page, but that means it can't be updated without deploying a new version. If you want to server static pages through a URL handler then do it that way, it just means you consume more resources to serve the resource. I do that with images from the datastore for instance or I could manage them via static resource deployments. – Tim Hoffman Feb 13 '16 at 08:59
  • Got it. What I'm trying to do is supporting HTML5 mode in an AngularJS application. To open a specific page (which for SPAs is actually a view embedded in the app's single page), the issued request comes from URLs like `http://my-site.com/my-view`, but _my-view_ does not exist. It's Angular itself that loads the required static resources to render the view. In these cases, the server should be told to return the index page, so that Angular can then manage the rest. This typically comes in handy when you refresh a page in the browser, or when crawlers try to directly access one of these pages. – Luca Poddigue Feb 13 '16 at 09:28
  • Interesting that even though i got zero upvotes on that answer it is being referenced. Anyway, the point the answer attempts to make (and seems to fail in doing so) is that someone entering your website with a URL like that is an uncommon case because it only happens when someone enters the site initially, therefor it might be quite okay to have little bit of latency there which is caused by the server request. – konqi Feb 14 '16 at 12:36

1 Answers1

0

There's nothing wrong with doing server side rewrites.

Google serves static files (as configured in appengine-web.xml) using google front end, which is a low latency, edge cached cdn, so you should always prefer to have it serve static content for you, rather than generated or served from your war. It's faster, cheaper and doesn't have the drawbacks of instance scaling (I.e users waiting for spin-up)

In your case (an index.html for angular), you don't need a rewrite, you can map the same servlet/resource to all paths, e.g. /*

Tucky rewrite comes into play when the possible web.xml path rules are not flexible enough to map your routes to servlets. But there's no problem using it if needed.

Nick
  • 1,822
  • 10
  • 9
  • Can you confirm that requests are routed to the app servers only in case they do not match a static resource that can be served by the CDN? – Luca Poddigue Feb 14 '16 at 01:16
  • That's correct. You can check the server in the client - it's specified in the headers – Nick Feb 14 '16 at 01:31
  • 'In your case (an index.html for angular), you don't need a rewrite, you can map the same servlet/resource to all paths, e.g. /*' I would like to see a configuration of a working example doing that on live appengine. Map any path to a static resource (like index.html). – konqi Feb 14 '16 at 12:46