We would like to develop and sell custom commercial GAE applications. I would like information on the deployment of GAE applications on arbitrary Google Apps domains (i.e. not appspot).
Suppose our company is abc.com and we are selling app to def.com and xyz.com. What are the steps to deploy our app on our customer's domain?
When an app is deployed on many domains:
- Is the code duplicated or shared?
- Is the datastore definition duplicated or shared (or more precisly the kinds)?
- Any domain attribute add to the entity?
-
This is possible but to the best of my knowledge,
def.com
&xyz.com
will have to sign up for Google Apps.Once the domain is registered with Google Apps by your prospective customers, they can add not only Google Apps like Gmail & Docs to subdomains (
mail.def.com
&docs.def.com
) but also any GAE apps (fooapp.def.com
).- Is the code duplicated or shared?
Shared - Is the datastore definition duplicated or shared (or more precisly the kinds)?
While the schemas (definitions) are shared, what isn't shared is the actual datastore. i.e. each instance of your app will have separate data. - Any domain attribute add to the entity?
You can figure out which domain your app is being served under using one of the CGI/HTTP environment variables. I don't remember which variable exactly but I'll update the answer once I look at some old code of mine. Once you find out what is the current domain, you can choose what to do with that info, including saving it to an Entity or simply denying access.
Another cool feature about this is that let's say company
def.com
is using hosted GMail and have Google Authentication for their employees. Now if your app is using the GAE provided authentication hooks, then you can automatically authenticate just their employees without any code change on your part! At least, that's the theory since I haven't tried it out myself ;-)Nick Johnson : Point 2 and the footnote are incorrect: They all use the same datastore, and you can't have a single app instance authenticate multiple Apps domains, currently.antrix : I am actually talking about multiple app instances from the same code. If company `def.com` wants to use fooapp, they go to their Google Apps Admin and add that app. This will create a new instance of the app which will use a different datastore & authenticate against `def.com` and not general Google Accounts. Is that wrong?antrix : Reading your answer now, I meant to describe scenario 2 that you've outlined but perhaps I wasn't very clear!Gig68 : Thanks, very helpful. Sorry can't vote up yet - no reputation - Is the code duplicated or shared?
-
You have three options at the moment, when it comes to a 'multi-tenant' app such as you describe:
- You can have a single app that your customers add to their domains. Your app will have a single datastore, but you can use the Host header to determine which customer is accessing the app, and segregate the datastore entries based on that.
- Easy to deploy and upgrade
- Easy for customers to install
- Users have to have Google accounts, not Apps accounts, to log in.
- You can deploy a fresh app instance for each customer.
- Harder to deploy and upgrade
- More customer involvement required to install
- Provides firm separation of data
- Users can log in with their Apps credentials
- You can work with Google to create a new Apps Marketplace app
- All the benefits of point 1 and 2, above
- Requires Google involvement
- No certain release date yet
Gig68 : Thanks, very helpful. Sorry can't vote up yet - no reputationPaweł Dyda : This is quite an old question, but it was changed recently. Now developing and deploying multi-tenant apps is easier. - You can have a single app that your customers add to their domains. Your app will have a single datastore, but you can use the Host header to determine which customer is accessing the app, and segregate the datastore entries based on that.
0 comments:
Post a Comment