0

I'm in the process of building out an infrastructure to support a gaming platform we intend to scale out to hundreds of thousands of users. Since this is in the entertainment / gaming industry, we are expecting a heavy load from each user session, therefore, performance is of upmost importance.

We are trying to parallelize as much of the architecture as possible, meaning API, databases, and applications run off of different servers that can be horizontally scaled. One of the applications is a web app, and we're having the most trouble with this due to a specific scenario involving the same origin policy on legacy browsers.

This application running in the web browser will need speedy access to the models only available through the centralized API. While this is great for our dedicated mobile clients, browsers unfortunately need fully CORS support to interface directly with our API. This is problematic because some of the HTTP verbs are not supported on all browsers (put / delete). Our only known workarounds are, rewrite the API to create more abstraction (we believe this is not a best practice and will increase development time and potentially performance) and work with only POST using JSONP or create a proxy (which will add an extra two leg to the trip and double the latency performance).

Bottom line is, we have boiled this question down to... are these the only two options, or is there something else we aren't considering, and if so, which of these solutions would be better suited to a gaming platform.

J K
  • 339
  • 5
  • 14

3 Answers3

0

Another option to consider is JSONP. By wrapping a JSON response to enable it to be loaded as a script tag, you can avoid problems with the same origin policy.

I can't speak to performance issues of your specific application without knowing the app in detail. I would think that you would see similar performance on the server with JSONP, since your major difference over other methods would be that you are concantenating an extra string.

Jeffrey Blake
  • 9,659
  • 6
  • 43
  • 65
  • We looked at JSONP, that is one of the options but it requires us to break RESTful conventions and limit ourselves to the POST verb. – J K May 09 '13 at 20:21
0

SOP should not be the problem. Use JSONP for domain-across requests. Wrapping the answer in in a callback method should not be the problem for your server-side part and sould be transparent for the rest of the application. Doesn't break REST style. On client-side library the use of JSONP should also be transparent for the rest of the application.
So, what's about PUT and DELETE? Simply perform a POST and set the X-HTTP-Method-Override header with the intended method. Your webservice handler on the serverside should recognize the header and imply the request with the method from the header. All transparent to the rest of the application.

Emii Khaos
  • 9,983
  • 3
  • 34
  • 57
  • Interesting, I didn't realize that this could be done. In fact, another article here on stackoverflow states that PUT and DELETE can't be done with JSONP. (http://stackoverflow.com/questions/5345493/using-put-post-delete-with-jsonp-and-jquery) So, 1) you're saying this header will be interpreted by let's say a node.js REST server or a PHP rest server as the HTTP verb? 2) Does this work in older browsers such as IE8? – J K May 10 '13 at 00:03
  • I'm not sure, but JSONP is only needed if you want to read data from a remote url. A normal POST could send to every domain? The interpretation of the header have to done in your application. Sending the header should work in every browser. – Emii Khaos May 10 '13 at 10:04
0

While JSONP certainly does have "universal" support - it's still a bit hacky and has a few negative side effects: mainly that you can't capture errors.

The reason JSONP works everywhere is because requests made by the script tag fall within the confines of a "simple request", as defined by the CORS specification.

My point? Instead of using JSONP, you could also modify your API (or at least the most commonly accessed parts of it) to fit within the confines of a simple request. Then you get full ability to handle errors without any of the performance impact of preflight requests.

For the places you must use preflight requests, you can cache the preflight responses.

I have a full write up on this technique at Two Strategies for Crossing Origins with Performance in Mind

nikmd23
  • 9,095
  • 4
  • 42
  • 57