It seems like static files can only be served from the same domain as the app.
I could create a new app for hosting static files but I'm a little nervous that that would a violation of the terms of service.
You don't need to serve your static content from a different app, you just need to use a different hostname. App Engine makes it pretty easy to have many different hostnames that point to the same app.
With wildcard subdomains you don't even have to create a DNS entry. If your app lives at myapp.appspot.com, you can also reach it through any subdomain, like static.myapp.appspot.com. If you're using your own domain, you'll need to configure it manually.
"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 may not develop" but, you can "Enable Billing" for multiple application. An example:
1) mysite.appspot.com
2) mysite-static.appspot.com
3) mysite-data-service.appspot.com
Section 4.4 of the terms of service prohibit one from splitting one logical app into two pieces - so hosting your dynamic content and static content in two separate GAE apps would violate the terms.
However, you could host static files on another web hosting service - anything from a simple shared hosting solution all the way up to a big CDN. This approach enables your site to serve static content from domains other than your app's domain.
Related
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?
Maybe this is a really basic question, but how do you architect your system such that your single page application is hosted on premise with some hostname, say mydogs.com but you want to host your application services code in the cloud (as well as database). For example, let's say you spin up an Amazon EC2 Container Service using docker and it is running NodeJS server. The hostnames will all have ec2_some_id.amazon.com. What system sits in from of the Amazon EC2 instance where my angularjs app connects to? What architecture facilitate this type of app? Especially AWS based services.
One of the important aspects setting up the web application and the backend is to server it using a single domain avoiding cross origin requests (CORS). To do this, you can use AWS CloudFront as a proxy, where the routing happens based on URL paths.
For example, you can point the root domain to index.html while /api/* requests to the backend endpoint running in EC2. Sample diagram of the architecture is shown below.
Also its important for your angular application to have full url paths. One of the challenges having these are, for routes such as /home /about and etc., it will reload a page from the backend for that particular path. Since its a single page application you won't be having server pages for /home and /about & etc. This is where you can setup error pages in CloudFront so that, all the not found routes also can be forwarded to the index.html (Which serves the AngularJS app).
The only thing you need to care about is the CORS on whatever server you use to host your backend in AWS.
More Doc on CORS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Hope it helps.
A good approach is to have two separated instances. It is, an instance to serve your API (Application Program Interface) and another one to serve your SPA (Single Page Application).
For the API server you may want more robust service because it's the one that will suffer the most receiving tons of requests from all client instances, so this one needs to have more performance, band, etc. In addition, you probably want your API server to be scalable when needed (depends on the load over it); maybe not, but is something to keep in mind if your application is supposed to grow fast. So you may invest a little bit more on this one.
The SPA server in the other hand, is the one that will only serve static resources (if you're not using server side rendering), so this one is supposed to be cheaper (if not free). Furthermore, all it does is to serve the application resources once and the application actually runs on client and most files will end up being cached by the browser. So you don't need to invest much on this one.
Anyhow, you question about which service will fit better for this type of application can't be answered because it doesn't define much about that you may find the one that sits for the requisites you want in terms of how your application will be consumed by the clients like: how many requests, downloads, or storage your app needs.
Amazon EC2 instance types
We have a running multi-lingual app hosted in Azure written in AngularJS. For managing some of the unsecured/public pages, we are looking for hosting another app with a CMS. So our app structure is would look something like:
App: www.example.com
CMS: www.examplecms.com
What we want to achieve is that dynamic content generated by CMS (different domain) for static pages be served using urls in www.example.com. Is it possible? We are primary targeting .net based CMS solutions but are open to other platforms. The static content is not too complicated.
Since the app supports multiple languages and most of the CMS solutions available offer multi-language support via subdomain.example.com or www.example.com/language/ directory structure, we want the custom url redirection to point to our app site (www.example.com).
Looking for suggestions you opinions or best strategies to work around this problem.
This Q is off topic, nether the less...
As you would essentially be running 2 entirely different web sites, yes everything would work just fine. The requirements are vague and very generic but any application/CMS could be setup in different domains and if you wanted requests made between them, allowing cross origin requests would allow sharing content/data.
Umbraco, like many CMS's supports multilingual sites using path prefixes as you mention along with any other method you are willing to write yourself.
I would like to have the following:
myrootsite.appspot.com
myrootsite.appspot.com/app1
myrootsite.appspot.com/app2
etc.
Is this possible? I know I could just make /app1 be handled by app1, but then the redirects and everything wouldn't work unless I explicitly used redirect('/app1') instead of the current redirect('/').
Is there a way I can just upload my current apps (app1, app2, etc.) to the root site and have them work regularly?
Thanks in advance
You can only have one application per site. This means you'll need:
app1.appspot.com
app2.appspot.com
You can register one App Engine application ID and have each subdirectory do different things. For example, have all URLs under /app1 do one thing, and all URLs under /app2 do another thing.
However, they'll have to be deployed together, and will eat away at the same quota. They will, in fact, be one application, with URLs that do two completely different things.
Otherwise, what Taylor says is correct, you can only have separate subdomains (either on appspot.com or as subdomains on your own domain)
You can't have multiple apps on a domain without a reverse proxy - but you can have multiple 'subapps' - just configure each one independently using app.yaml / web.xml. They'll share the same datastore and memcache, but otherwise can be treated as separate components.
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