Hi Sanjay, I would say it is probably a bad idea in general, but it depends very much on your app. If the components are legitimately separate (like they don't need to access each other's data), or you're going to reuse some portion in multiple sites / apps, then maybe there is a case for it.
I would say If you're writing your apps to be modular, and not doing crazy stuff, then a vulnerability in the chat module shouldn't result in data exposure in another module (especially if you're not using GQL). URL Fetches to another app actually can be much more efficient than URL Fetches across the web. Overall I'd say you might be adding a ton of complexity for little gain though. Is writing the chat portion as a reusable module not sufficient? Robert On Fri, May 13, 2011 at 23:08, Sanjay <[email protected]> wrote: > For the chat service I was talking about before, the idea was that the > javascript for the main page would ping the chat server and if it didn't > respond, the chat ui wouldn't be shown. With services, I can have graceful > degradations for each service at multiple levels. For instance, if the chat > service was way over quota I can simply have it return 'empty' values that > say no one is online or something like that, or even simply take it offline. > It seems to me that splitting an app into services would increase its > reliability, not reduce it. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
