In Google app engine, what is the benefits of using modules instead separate applications?
For example If am already having an application named "Example" for my example.com and now I need new blog feature for blog.example.com.
Now Which is better? New module named "blog" in "Example" application OR New application named "Example Blog" like that?
And Note I concern about Google's Free Quota for App Engine too. If I use separate applications I can get Free Quotas for each Individual application. But If I used modules I should manage both example.com and blog.example.com in the same Free Quota usage.
So which option is best on Price Comparison and which is best in Performance
Modules are operates under same AppId, that mean that they will:
share same Datastore for data
same Task Queue for interoperability
same configuration for other Google Cloud services (BigQuery, Storage, etc)
There is not difference in Performance, separate apps or separate modules of same app could have as much resources as they need.
As about price, then two apps could be little bit cheaper that two modules, because of Free Quota. But I don't think there is a significant difference for most apps.
Related
In the documentation for App Engine it says:
Meeting your latency, availability, or durability requirements are
primary factors for selecting the region where your apps are run.
You cannot change an app's region after you set it.
In App Engine Standard Environment (with automatic scaling), what should I do if my application starts getting a lot of requests from a region far away from mine? For example if my region is us-east1 but I get a lot of requests from asia?
For some reason I thought that App Engine would spin up new instances in the region the request is coming from.
If wanting to build a globally accessible and fast app, this seems like a big limitation to me. Is GAE standard environment a bad choice then?
For the most part, Google App Engine is designed for small, simple and easy to deploy server instances.
If you need global load balancing and auto scaling, then you will need to select and configure the services yourself. Google's load balancer supports global geolocation based load balancing. You can define, in advance, which regions it will load balance to. Combined with Google Compute Engine and Instance Groups, you can define the global characteristics of your site.
The tradeoff for you is how much effort do you want to spend in planning, deploying and managing your setup. Google App Engine makes this easy, but you are limited in some options. Google Compute Engine takes more effort, but you have a larger set of options to chose from and manage.
Start with some research on Google's Load Balancer to better understand the options available to you.
GOOGLE CLOUD LOAD BALANCING
Google Cloud's structure related to "projects" has me really confused.
On the one hand all GCP services are encapsulated in a "project" right? So I think, OK I'll create something like "test", "stage", and "prod" projects. All my applications can be tested in "test" and eventually move to "prod" when they are ready to go live. Also, I can have SQL,bigquery,bigtable and whatever else in the test project that developers can hack on without having to worry about effecting production.
But I can only have one app engine app per project? How does that work? I can see how in app engine you have different versions so if I have one project per app engine app the test/staging mechanism is in that app's project, but what about the other GCP services?
If I have a bigtable or bigquery or something on storage multiple apps need to access what "project" do I put that stuff in?
Do I still have a "test","stage","prod" project for my services (where my DBs, storage, etc live), but then also create separate projects for each app engine app?
If multiple apps need to access something, it can live in one of the app's projects- that doesn't make sense.
Edit: google does have some good docs about how projects and services can be organized https://cloud.google.com/appengine/docs/python/creating-separate-dev-environments
While you can only have one App Engine app per project, an App Engine app can host multiple services, each of which has several versions of code deployed.
You can configure resources in one project to allow access to users/apps outside that project. See, for example Setting ACLs for how you can allow multiple projects to access a Cloud Storage bucket. Similar cross-projects access can be configured for most if not all Google Cloud resources/services/apps - but you need to check the respective docs for each of them to see the specific details each of them may have.
With this in mind it's really up to you to organize and map your apps and resources into projects.
Can i develop multiple applications on Google app engine or Amazon AWS??
Does it violate any of the Google app engine and Amazon AWS rules??
Plz advice me on this topic
Yes, you can have multiple applications. But for Google there is a limit of 10 applications per developer. In Amazon there is no limit (other than capacity) of number of servers you can buy and no one really asks how many applications are there, unless you perform illegal actions with it (eg. spam).
on Google AppEngine you can't use multiple applications as a way to avoid fees for you application.
So your applications should be different, and you can't deploy many instances of the same application so you get more 'free' allocation.
From the GAE terms of service
4.4. You may not develop multiple Applications to simulate or act as a single Application or otherwise access the Service in a manner
intended to avoid incurring fees.
I am considering developing a platform in GAE.
for this to work I would like to be able to have run the same app engine instance run several 'sister' sites. This would be something similar to the way that the stack exchange sites work, so each 'sister' site would have its own users, data and theme (but may potentially be configured slightly differently - think different plugins used), but essentially would have the same function & format.
I would like to know if it would be possible to have each sister site have its own (customer defined) url, which would use the same app engine instance, and the app engine instance would be configured (by setting the site id and valid plugins for that site) depending on the url which was used to access it.
Yes, this is entirely possible. As Fox32 points out, you can use namespaces to separate different datasets. For domains, App Engine supports wildcard mappings, so you can map *.yoursite.com to your app. If you want to add custom TLDs, either you or your customers will need to create a Google Apps account for them, or add the domain as an alias on an existing Apps account, and associate it with the App Engine app - this doesn't require that they be admins of your app to do so.
You can use namespaces, to separate different websites, for many api methods. Take a look at the GAE documentation about it.
The Namespaces API is integrated with Google Apps, allowing you to use your Google Apps domain as the current namespace. Because Google Apps lets you deploy your app to any domain that you own, you can easily set unique namespaces for all domains linked to your Google Apps account.
I am interested to build a platform on Google App Engine where one Master App provides common functionality to several child Apps (Web portals).
Master App:
Offers Common Social Networking features
Common user database
Interacts using Web services API
Child Apps (Web Portals):
Connects to Master App for user database and social networking features
Uses Local business logic for local features
My Design plan is:
Master and Child Apps will be
individual Apps on GAE Appspot (for
easy management)
All will communicate via REST/JSON?
I will enable billing for all Apps so
nothing is against Google's usage
policy.
Will use SSL for login into Master App, later use a token
(cookie) for further interactions
Could anyone kindly spot risks and suggest any improvements?
Your "Master/Child" concept will be hard to maintain, introduce issues with cross-site-scripting and most importantly be completely against Google App Engine's terms of service for combining multiple apps into one.
4.4. You may not develop multiple Applications to simulate or act as a single Application or otherwise access the Service in a manner intended to avoid incurring fees.
You could use multiple app versions (defined on app.yaml) to deploy different codebases to the same appspot.com subdomain, and access them like http://app1.myapp.appspot.com, http://app2.myapp.appspot.com for "versions" app1 and app2. You could even have one version running on Java and another one on Python.
They'll all share the same datastore, although you'd be able to use namespaces to separate them if necessary.
For the distributed nature of the architecture you proposed, I'd suggest having a deep look at Facebook's graph API and Twitter's API. They both use oAuth for authentication/authorization and already have a proven implementation of what you're trying to accomplish.