Background
I'm currently using Heroku, running a single Hobby Dyno to serve both static assets and a simple API using node.js. I'm now looking to separate the static delivery and API into different dependencies. Having looked around, I'm now considering Firebase for static hosting.
Question
Using Firebase static hosting, is it possible to configure the DNS, or setup a URL rewrite, to make external API calls for a given URL, e.g.
http://myapp.com/api -> external API call to http://myapp.herokuapp.com/
http://myapp.com/* -> serve static file
If not, is it possible to configure a DNS entry to point www to Firebase, and api to Heroku?
Bonus Question
If possible; would this API call count as a cross-origin request? Preferably all requests would be made against the Firebase domain, and then everything done behind closed doors.
It is not possible to have Firebase Hosting rewrite the URL to a different server. While it is possible to have Firebase Hosting redirect the request to the Heroku server, that likely won't help you.
The common approach is indeed to split this in the DNS. Have api.myapp.com point to Heroku and www.myapp.com to Firebase Hosting.
Related
I'm managing the DNS of my domain with Cloudflare.
The marketing pages for are hosted with Netlify.
The main application is hosted with Heroku.
Is it possible with cloudflare + a naked domain (my-example.com) to have some paths being served by Netlify and other paths by Heroku?
Or am I forced to put one of the hosting services on a subdomain?
Disclaimer: I work for Netlify.
You can definitely do this without running your own server or paying anything extra.
Since Netlify already has a CDN, it's suboptimal to put cloudflare's CDN (activated with the 'orange cloud' in their settings) in front of Netlify's. Besides being inefficient, doing so breaks Netlify's atomic deploys and rollbacks and also slows down page service from our observations. It may work, but is not recommended. However, CloudFlare's DNS is quite performant and can be used without their CDN (turn off the 'orange cloud'). Their DNS works well with content hosted on Netlify's CDN.
Here's how to set things up to accomplish this via Netlify.
Deploy your static assets to a Netlify site at your main custom domain, let's say it's my-example.com. For testing purposes you can use the built-in sitename at Netlify (something-something-1234.netlify.com) instead of my-example.com. The below example redirects are "host agnostic" so will work with the Netlify hostname, Netlify deploy previews, AND the production hostname.
Find all the paths for your dynamic content - for this example, let's say it's /main/* and /app/* that are dynamic and your backend is hosted on Heroku.
Create proxy redirect rules to point to those paths. They could be hosted via CloudFlare's CDN to protect your API if you wanted to - Netlify proxying to CloudFlare-fronted sites on Heroku works fine. You could also choose just to proxy straight to Heroku which would be less complicated. Netlify has some DDoS protection built-in and is still "in front of" your Heroku app. Up to you.
Deploy those proxy rules and test.
Netlify's proxying (technically reverse proxying) can connect to whatever backend you'd like and does NOT show the URL to the visitor - it looks to them (URL bar in the browser, HTTPS connection) as though they are connected to my-example.com the whole time, but the content is returned from your backend (including HTTP status codes. This response is cached on Netlify's CDN if indicated by your Cache-Control: HTTP Header directives which the Heroku app sends. Note that CloudFlare WILL CHANGE your Cache-Control header in case you set it on content they proxy to! Netlify won't.)
Here's a common setup:
/main/* https://yourapp.herokuapp.com/main/:splat 200!
/app/* https://yourapp.herokuapp.com/main/:splat 200!
Note that if you deploy ANY assets under /main or /app to Netlify, they will be ignored due to the trailing ! on those rules. See https://www.netlify.com/docs/redirects/#note-on-shadowing for some more details about how that works and the alternatives (TL;DR: deploying some things like /main/logo.png on Netlify but nothing that Heroku should serve vs deploying ALL needed content for /main/* on Heroku).
Note that I suggest using identical paths on Netlify and Heroku (/main/*) rather than proxying to /somethingelse/* since it is easier to debug asset loading when paths match up. This isn't a requirement, though.
As mentioned in the comment, its possible using cloudflare enterprise service.
But you can do it with a simple nginx reverse proxy setup.
Have DNS resolve to nginx reverse proxy and based on the path, appropriately call the upstreams.
eg. example.com, and then direct queries for /path1 to 100.100.100.100 and for /path2 to 200.200.200.200
Currently I'm hosting a client application written in AngularJS on Google Cloud Storage using the configuration described here.
I like this configuration because it acts as a CDN and we don't have to use a dedicated machine to host the frontend files.
The problem is that Google Cloud doesn't support HTTPS for custom domain names, and we want to improve our security standards serving at least the login page on an https domain.
¿Is there anyway we can keep the static files hosted on Google Cloud/some other CDN for fast serving and use an https domain?
Update
For anyone interested, we finally migrated all our CDN with HTTPS requirements to Amazon S3 + CloudFront and it works like a charm.
While Google Cloud Storage does support HTTPS, it does not support HTTPS for custom domain names.
Although you've found a solution not connected with your original question, I'm answering in case someone gets here with the same question like I did.
Google Firebase link is an excellent way to serve websites (and apps) as it is automatically through SSL (https) and Google Edge servers (effectively CDN function). And https will work using your own domain name. You can push your site from your local machine (Node.js needed) or from GitHub, Gitlab, etc. using continuous integration/deploy.
There is a generous free trial plan to try it first, then a reasonable monthly rate to pay as you go as your usage grows. plans
Say you have two apps hosted on heroku: appA and appB. They will be accessible at appA.herokuapp.com and appB.herokuapp.com. Is there a way to "share" the subdomains? As in, can I have appA listening on both urls?
I suppose I could have appB forward all its traffic to appA, but I'm more curious if it can be done through some heroku setting.
Thanks!
No, this cannot be done through a heroku setting. You either need one of the two apps acting as a reverse proxy to the other app, or else you need a third server running a dedicated reverse proxy such as nginx.
Heroku support once suggested using a third heroku app as an nginx reverse proxy with a custom buildpack to accomplish this, although I decided not to go that route. It is unfortunate that there is no systematic support for multiple apps on the same domain at Heroku, but that would add significant complexity to their currently predictable and transparent routing platform (which is itself a non-configurable reverse proxy).
I want to make my web app fast, especially the first page load (index.html).
Can I do this by hosting myfastapp.com on Rackspace CloudFiles and then have a subdomain called nodeserver.myfastapp.com which connects to a Node Server on Joyent.
Note: The node server will only connect via socket.io to tell the client which additional files to grab from the CDN (myfastapp.com).
There's a guide for this in the Cloud Files docs at Create Static Website.
There should be no issue with that the logistics of that.
The main issue is getting the main site on Cloud Files due to cname restrictions, at least in the Rackspace system, but it can probably be done.
Is there any benefits to host our application static contents on a completely different Domain rather than host on a Sub-Domain of our main Domain like others? for exampe Microsoft uses i.microsoft.com, Google uses gstatic.com, Yahoo uses yimg.com, Stackoverflow uses sstatic.net
Thanks in advance
It should be different domain.
From Yahoo's Best Practices for Speeding Up Your Web Site
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. Yahoo! uses yimg.com, YouTube uses ytimg.com, Amazon uses images-amazon.com and so on.
Images should be on a different domain (or your CDN's domain). CSS on the other hand, can benefit from being hosted on the ROOT domain, i.e. the same domain as your web server. See this experiment that proves the better load times: http://www.jonathanklein.net/2014/02/revisiting-cookieless-domain.html