> This doesn't have to involve a great deal of extra complexity in your code. > The keyword here is "multitenancy", and there are several possible > solutions. One option is detailed in my blog post > here:http://blog.notdot.net/2009/11/API-call-hooks-for-fun-and-profitand > another > here:http://blog.notdot.net/2009/11/Enforcing-data-isolation-with-CurrentU...
I'm sorry, but hooking the API to do this seems pretty complex to me. As a developer, it would be much nicer if I could create apps that were specifically meant to be deployed into a customer's Google Apps domain. My code would be significantly simpler in that it would just operate on a datastore assuming that the datastore is owned by the consumer of the app and not shared with any other consumers. > A third option is to use a model that several of our customers are already > using: Have your users create an app engine app and add you as an > administrator, whereupon you deploy your app to their instance. This seems like an awfully big hurdle for someone to deploy an app. Shouldn't Google's goal be to make Google Apps as easy to use as possible? By making it easier for 3rd party developers to enhance the value of Google Apps, both Google and the 3rd party developers would benefit. The GAE system is already fairly user-unfriendly. Every time I go to my dashboard, I get redirected to my start page which doesn't actually list any of my apps. There's no support email for me to talk to. Instead, I have to craft specific URLs to get to my apps. Now, this is likely a bug and I'll eventually get around to reporting it, but imagining trying to walk some customer through the process of getting an account and deploying an app seems like pure pain to me. I'd much prefer if there were a Google Apps Marketplace. I could create my app with GAE and configure it to be made available through the Google Apps Marketplace. People who have Google Apps could easily browse/search the marketplace, where I could provide screenshots, pricing information, etc. Then, with a single click they could choose to consume my app in their domain. > Users seem generally tolerant of this if you are professional. FogBugz, for > example, have an excellent bug tracking (and more) platform, which is > optionally hosted on their hardware. The same goes for a plethora of other > companies. I agree, but I would prefer if I could just take myself out of the loop. It's their data. I really don't want access to it. I'm presenting a system whereby I can develop an app that potentially deals with sensitive data and I can assure customers that only they (and Google) have access to that data, not me. Someone else raised the issue of bugs that would require access to the datastore to resolve. If that were the case, I would much rather have a customer opt-in to giving me some type of access to their data when they find it necessary because of a software bug. In that case, the vast majority of users would probably not need to ever give me access. Only the minority who encounter a bug and want to help in the resolution would need to expose their data to me as the developer. > One important thing to note is that there are few (if any) plausible > scenarios that _don't_ require trust from your users. Since you wrote the > code, you could easily be doing nearly anything with their data; if you > provide for updates, you could modify the app to disclose information to > you, even if you don't have direct access to their datastore. Essentially > the only way around this would be to provide your users with the source, and > make updates entirely manual and up to them to apply. Sure, but customers are used to running software. They're not as used to having their data live under someone else's control. But, to be honest, let's just forget that I even mentioned the security issue with regard to the datastore: the fact still remains that it would be much less work for me as a developer if I could develop an app that works against a client's own datastore rather than my app's shared datastore. The complexity of my models goes down: - I don't need to store information about which clients own which data My development time goes down: - I don't need to spend time enforcing client separation - I don't need to write as much code to handle who the current client using the app is - I don't need to develop a time/storage billing system per-client to recoup my GAE hosting costs My potential return goes up: - Lots of companies are using Google Apps for hosting their domains, this is a nice market for me to target - Google Apps Marketplace would provide an easy way for people to find and subscribe to/buy my application - Google makes out well, too, taking some percentage of the subscription/sale All these things seem like they'd be wins on both Google's side and GAE developers' sides. Yes, your links may provide ways that GAE developers can do some of this, but it's certainly less attractive than the solution I'm proposing. andy -- 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.
