> Finally, App Engine has a hard 30 second limit on frontend requests. For the most part, this was fine. But certain requests started to take longer than 30 seconds, particularly when empires started getting larger
This is a very sensible limit. As your game is growing, more and more of these requests will pile up and will take resources away from quicker requests, making the game slower for everybody and crashing your architecture.
Adding limits like this is one of the very basic things you do when you need to scale. Changing platforms in order to get rid of limits like this will only mean that you'll have to re-add them at some point.
The correct fix for not running into such limits is to fix the code, not remove the limits.
If your requests need more than 30s, something is wrong. Most apps strive for <200ms responses. If you need a long time, rearchitect it. Run a background thread. Poll for completion or email the user when complete. Again, annoying, but your app will be better for it.
Saying that a legacy product sucks, but that you still need it to run is not an effective mindset. These platforms have constraints. Work within them and the app will scale and perform very well.
That seems like a rather arrogant attitude. You cannot force (what you consider) good practices on users/customers and expect them to be happy about it.
That is a very narrow-minded attitude. Not all apps have to scale and not all parts of an app have to scale. It may not make sense or be worthwhile to spend the effort to make a long running request shorter if it's used infrequently or by a small number of users or if the system as a whole does not require a high level of concurrency. Not every company is Google.
No. The developers are clever enough to decide for themself whether the code needs to be fixed. There may be some situations where it may actually mae sense to have 30+ s long requests.
No, when utilizing a REST protocol it is not desirable to have long requests. The correct way to do something that could potentially take a long time would be to process it in the background queued and then have the client poll the server until complete or to push it to the client when complete.
Having an open connection for 30 seconds + is bad practice, and App Engine is a shared resource. Arbitrary limits are sometimes bad but in this case it will deter poorly designed APIs from starting in the first place.
But the developer is in the best position to decide whether he should fix the code. Perhaps he's just testing something, that will be rewritten later. 30+ seconds requests are not always bad.
It has a cost (it takes time to fix it) and value (users won't have to wait). The developer has more information than Google to decide whether cost or value is higher.
Out of curiosity, can you describe a situation where 30+ second requests on a large-scale, high-traffic system is acceptable (in the sense that it is better to hold the connection waiting rather than erroring out)?
EDIT: long-polling aside, and even then, 30 seconds is a perfectly acceptable limit.
Realtime updates (if you're not using Websockets) are usually done with long-polling, for which 30 seconds is perfectly acceptable. Socket.io, for example, uses a default of 20 seconds [1].
Streaming music and certainly video are generally delivered as chunks, with a few chunks per request that don't require long connections [2].
This is a very sensible limit. As your game is growing, more and more of these requests will pile up and will take resources away from quicker requests, making the game slower for everybody and crashing your architecture.
Adding limits like this is one of the very basic things you do when you need to scale. Changing platforms in order to get rid of limits like this will only mean that you'll have to re-add them at some point.
The correct fix for not running into such limits is to fix the code, not remove the limits.