Is that somehow possible to access one datastore? Or access one app from different domains.
App Engine recently add support for a feature called modules (Docs: go, python, java)
App Engine Modules (or just "Modules" hereafter) is a feature that lets developers factor large applications into logical components that can share stateful services and communicate in a secure fashion. An app that handles customer requests might include separate modules to handle other tasks:
API requests from mobile devices
Internal, admin-like requests
Backend processing such as billing pipelines and data analysis
When you create a new module, App Engine will create a url that corresponds to the module name. If you only have one module then the name will be default. e.g.
http://default.myapp.appspot.com
http://mobile‑frontend.myapp.appspot.com
http://my-module.myapp.appspot.com
Using Domain masking, you could then direct from:
www.myapp.com => http://default.myapp.appspot.com
www.myapp-mobile.com => http://mobile‑frontend.myapp.appspot.com
www.example.com => http://my-module.myapp.appspot.com
Every app has its own datastore and memcache (shared among all versions of that app).
It seems not possible to share datastores between applications right now (unless you provide some web service for that), but that would be a nice feature to have, so maybe you should file a feature request with Google vote for it.
As for domains, you can associate your app with domains managed by Google Apps. Multiple domains for the same application should be no problem (except for SSL certificates).
Every version of an app is backed by the same datastore. If you want to limit access for individual requests, you'll need to add a field to your model to enforce that restriction. There are low level hooks in the datastore API for this sort of thing, if you want to go that far.
And yes, you can add a single App Engine app to multiple domains - even in multiple Apps accounts.
Kyle's solution would work, but App Engine was never designed to be used in this way. So if you architect your app(s) to rely on this kind of setup and Google clamps down for whatever reason then you'd be screwed.
You can have multitenancy using the Namespace Java API
Related
This is the first time i'm working with firebase. My goal is to have a bounch of client apps (more and more over time), all of them managed by an admin app (One app to rule them all).
The thing is that the client apps have a certain content that needs to be updated from the admin app. My best approach is to create a firebase project, put the admin app there and adding client apps over time. I'have read that is possible to have an unlimited number of apps inside one Firebase project. On addition, someone told me to create one project for each client app and connect them to the same database somehow. I simply don't know what to do.
Which would be the best solution for my problem? thank you
firebaser here
A Firebase project can currently contain up to 30 app definitions. This is meant to support variations of the same logical application. For example, having an Admin app in addition to the app for regular users, and/or having an iOS, Android, and Web version of the same app, and for example having a free and a pro version of the app (if that is allowed by the stores where you deliver them).
Adding multiple apps to a project is expressly not meant to be used for white labeling apps, where you ship essentially the same app with different branding to different user segments, as you'd be sharing the backend services between them. For some backend services (such as database and storage) this is not necessarily a problem, as you can isolate the customers with security rules. But for other services (such as authentication and analytics) this is not possible, which is why this use-case is not supported.
If you need to define a separate app in the project for each customer, the only supported approach is to create a separate project for each customer.
I'have read that is possible to have an unlimited number of apps inside one Firebase project.
In that case please provide a link, so we can either fix it, or (if it's not in the Firebase documentation) leave a comment to clarify.
By default, specific versions of an App Engine app are routed by URLs like https://[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com.
Is there any way to have something similar with a custom domain?
I currently have a subdomain mapping for my app configured with a CNAME DNS record pointing to ghs.googlehosted.com (my "naked" domain is not served by App Engine). This allows serving the default version of my app from that subdomain, but I also want to be able to test new versions of the app using my domain (for various reasons such as sharing cookies, etc.)
For example, let's say my domain is typeracer.com and my custom domain mapping in App Engine is data.typeracer.com: I want to be able to access a specific version of my app at a URL like https://[VERSION_ID].data.typeracer.com. Is there any way to do this?
I've looked at the App Engine docs for adding wildcard subdomain mappings and using a dispatch.yaml. However, it looks like that would work only for routing specific services, but not specific versions of the app.
No, what you ask for exactly is not possible as the mapping is a (sub)domain per GAE service one, you cannot select a certain version of a service in the custom domain settings screen.
Sounds like may be attempting to implement different environments (say staging) based on service versions, which has some disadvantage, see Continuous integration/deployment/delivery on Google App Engine, too risky?
If so you can try to implement them using different services instead, which:
would allow you to map one (sub)domain per environment
you'd avoid all drawbacks mentioned in the above-mentioned Q&A
The domain naming scheme you mentioned suggests variable nesting levels, which in itself can be problematic, see Sub domain not listed in Google App Engine while enabling SSL for custom domains. Maybe try something like https://data-[VERSION_ID].typeracer.com instead of https://[VERSION_ID].data.typeracer.com?
I've added a custom domain to an App Engine project. The TTFB of requests to that project's service on the *.appspot.com domain is under 15ms. Accessing the service via the custom domain, however, takes about 80ms. What can I do to fix this?
According to someone who works at Google, if you set up a custom domain for an App Engine project hosted in Japan, requests are then routed via Taiwan, which increases latency. I haven't heard an explanation of why they do that, but regardless, GCP has known about this issue for about three years and don't seem to think it's a big problem https://issuetracker.google.com/issues/64458939
Point mentioned in the documentation on mapping custom domain with app engine
Using custom domains might add noticeable latency to responses that
App Engine sends to your app's users in some regions. The regions are
as follows:
us-west2
us-east4
northamerica-northeast1
southamerica-east1
europe-west2
europe-west3
asia-south1
asia-northeast1
australia-southeast1
Link - https://cloud.google.com/appengine/docs/standard/python3/mapping-custom-domains
Im confused about these three different constructs in google cloud and trying to understand how these fit together.
First, from what I have read "modules" are just the old name for "services" right? So anything I read about google cloud "modules" would also apply to services?
Are you using namespaces AND services/modules together or are they generally mutually exclusive?
Is this a good example of how to use these things together:
Put my shared resources (storage, DBs, etc) in a "namespace" and that way multiple modules/services can access them. "Any App Engine request can access any namespace" so namespaces resources are bound by their project container.
Create "services" that access the namespaced resources
All of this is in a single "project" which is used as an environment (so I'd have a "dev" and a "prod" project
Right, services and modules are the same thing. Note the actual url path inside this quote from App Engine Services as microservices:
In an App Engine project, you can deploy multiple microservices as
separate services, previously known as modules in App Engine.
Namespaces are supported by just a few APIs that services can invoke:
App Engine currently supports namespaces in the following APIs:
Datastore
Memcache
Task queue
Search
They are really just a way to separate/slice (not share) data served by these APIs and can help prevent accidental data leaks across the namespace boundaries. See for example Implementing Multitenancy Using Namespaces. But note that the protection is only as good as the app code is (data will leak if the code is setting the wrong namespace).
Services do not offer data isolation, they can share data regardless of it being in a namespace or not, by appropriately setting the namespace when invoking the respective API. So it's not placing data in a namespace that makes that data shareable across services.
Project bounds apply to both namespaces and services. But it is possible to configure APIs and projects to allow access even across project boundaries (or even from outside Google network - see, for example How do I use Google datastore for my web app which is NOT hosted in google app engine?)
The primary purpose of using services is to obtain code isolation. But it comes with a price - each service has its own instances. Also a bit more difficult: docs and even tools are often a bit behind, many of them assume a single-service GAE app context.
Even though using services to create environments is offered as an alternative in Naming Developer Environments I would stick, as you mention, to using separate projects for that (to also have data isolation).
I have tried searching the info regarding applications on GAE within same domain talking to each other but so far I don't have any luck. There was a post here but I don't know if that answer is correct.
You could also run the two different "apps" as different versions of the same appid. Then they share the datastore. Also, urlfetch.fetch() calls to paths of the same app are treated specially, they are faster and don't require authentication (they count as if they are logged in as admin).
I believe you will be best served by exposing a REST API for both your applications, so that they can read/write information as needed.
For e.g. If one of your apps is an Invoicing App and the other app needs only read access to Invoices, you can expose an API in the Invoice App for:
searching invoices by some filter
providing the Invoice detail, given an Invoice ID
Exposing an API will keep the applications loosely coupled with each other and will allow you to enhance the API as more requirements emerge. In the future, you can even have other clients like a mobile app access the API.