cross app queries

[Fabricio Zuardi]

Is it possible to do cross app queries on GAE? As in a query for
entities of an application I own from another application I own using
the GAE db APIs only (and in case not, if this would be a good
request).

I guess what I want to know is if all of my applications(or even all
GAE apps) shares the same DataStore and if it is possible or desirable
to internally be able to query content from one another without the
need of making an external request.

[]s
--
Fabricio C Zuardi
http://fabricio.org

[ma...@google.com]

Hi Fabricio,
At this time, you can not directly query one application's datastore
from another application. You can expose datastore data in a feed, or
other mechanism to be read by other applications.

Also, feel free to post new feature requests, and vote for existing
feature requests on our Google Code Hosting project:
http://code.google.com/p/googleappengine

-Marzia

[Sanjay Menakuru]

Hi,

Splitting your app into multiple services that are isolated seems like a good architectural decision. For instance, I want to implement in-window chat on the website I am building on AppEngine. Since this website is probably the first in a series of apps I am going to be making for a customer, I think it would be nice if I could write the chat functionality as a standalone app/service that is used by this app, and possibly in the future by other apps. 

Also, writing apps as a set of services glued together seems to be a good way to go, because users data would be better isolated. For instance, if a bug in the chat service code exposes user data, it would only have access to the local datastore and therefore only be able to read chat history as opposed to getting full contact details for every user of the website.

I have 2 questions:

1) What do people think about architecting a complex website this way?

2) [More for a Google Engineer] If I use urlfetch to access other appengine apps (for the reason I mentioned above), since it can remain inside Google's infrastructure, is it more efficient than urlfetches to external sites? 

[Brandon Wirtz]

>Splitting your app into multiple services that are isolated seems like a good architectural decision

 

Service 1 has 5 minutes of down time a month on average.

Service 2 has 6 minutes of down time a month on average.

Service 3 has 15 minutes of down time a month on average.

 

Your Site on 3 services has 26 minutes of down time a month on average.

 

Sound like a good architecture?

 

Fetches to other apps are just as expensive as fetches across the web.

 

Fetches to the new back end instances may not be.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Sanjay Menakuru]

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.

[Robert Kluin]

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

[Sanjay Menakuru]

We are still in the process of whiteboarding to decide on overall architecture of some features, so I was wondering what were the common patterns used by other developers for modularization.

Writing a chat module (internal to the app) is definately something we are considering. The case to be made for this is the module can then be customized to access data more efficiently in other sites since it will have extra information about the data at hand. Is this the pattern you find yourself using frequently? 

On the other hand, if you write a chat service (or other types of services) as an external app, it is very easy to determine what each service is costing you and if it is exceeding your projected budget. Do you have any guidance on how to do that if you write internal modules?

[Brandon Wirtz]

Chatmodule.py

Userprofile.py

Sellsomebodysomething.py

 

Makes for great modular code.

 

Tracking the cost of each…   Load tester and the functions you are running.  I routinely write GAE apps that all they do is run calls to see how much money the other apps cost in a clean room.

 

Real world cost analysis you are right is harder if everything runs on the same account, but really is the cost of your website based on the cost of running chat? I assume you are running chat for community building, so you kind of just put that in the bottom line until you get to a certain size.

 

Remember that every time App1 Fetches from App2 you pay 22 cents a Gigabyte of data.  That’s likely to be more than the money you would save by deciding chat costs too much. :-)

 

If you write all of your modules as asynchronous AJAX and the data is in silos, then separate apps is not a bad thing.  Because no part is actually dependent on the other. 

--

[Robert Kluin]

Hey Sanjay,
If you're code is segregated by URL, you can grab your logs to do
detailed cost-analysis. The App Engine dashboard also includes some
basic information about each URL.

I usually prefer to write small 'library' type modules that I can
include in my projects. But, like Brandon said, if the other service
is interacted with via AJAX calls and shares no data with the rest of
the app it probably doesn't matter (beyond any potential cross-domain
stuff).

Robert