I have two apps - One is the public face of the application, and the other is the app itself. I'd like to set up heroku to serve one app (the public site one) to www., and serve up a different app *.domain
Is this possible?
not with Heroku and multiple applications.
If you already have www.domain setup when you try to add the wildcard is suspect it wouldn't let you because the wildcard would also match attempts to www.domain and there's no way to set a priority.
I have apps like you talk of on Heroku and have them all the same codebase and then work out which site should load based off the requested url
Related
I'm trying to develop an app that uses Strapi Admin Panel api generation, and, at the same time, serves as a website that consumes this api.
So, basically, I'm trying to build a website:
where /api route servers as a Strapi API endpoint
where /admin route serves as a Strapi Admin Panel for API creation
where all the other routes are configured to serve my website, i.e.:
/ route is the landing page of my website
/contacts is the contacts page
etc.
And, moreover, the static files of the website (html/css/etc) should be served from the server that, respectively, consumes the generated API (server-side).
I hope I'm not expressing myself too vaguely.
Essentially, I need to integrate one node.js app (my website) with another node.js app (Strapi) in such a way that they work seamlessly together as one.
Does anybody know how to achieve that?
I've read some answers here on Stackoverflow and on Strapi GitHub issues, and some people said that the way to achieve that is to run two separate apps on different ports, but it doesn't feel right to me (or maybe I just don't understand some basic stuff).
What I need is to make a single app that is, basically, a simple multi-page website, but enhanced with api generation tools from Strapi.
I have my Strapi app up and running and I thought maybe I should find some place in the app folder structure to put my website (i.e. all the static stuff to the public folder), but where to put the server-side stuff?
And I'll need to use a templating engine, so the question of "where to put the client-side files" arises again. The more I dig into the code, the more I get confused.
PS: I'm fine using Koa which is used as a server for Strapi.
PPS: Further, I'm planning to deploy the app to Heroku on a single Dyno (if it is important).
Okay I just played with the routing prefix and that is the solution I suggest you.
So you will have to build you website app. And push the build in the ./public folder of the Strapi application.
Then in your api/.../config/routes.json files you will have to add an option prefix in the config key of each of your routes and for all your APIs
{
"routes": [
{
"method": "POST",
"path": "/restaurants",
"handler": "Restaurant.create",
"config": {
"policies": [],
"prefix": "/api"
}
}
]
}
So at the end you will have your admin on /admin
Your APIs endpoints prefixed by /api
And your website/assets on /
I found myself in a similar situation. In my situation I wanted to deploy Strapi along with a static site (in my case built with Gatsby) just in one server instance, at least to try if possible.
There are some open questions left from the original post, so let me answer them based on my context:
First of all, yes it's possible. But each app has to function on their own port. In that way your server knows which one to serve based on the request. Trying to mix them into a single port will mess a lot both apps.
In my situation, what I end up doing is to have Strapi running in Port 1337 and serve my static page in Port 80. In order to achieve that I used NGINX for serving content and work as a proxy. I first tried to have them on the same domain, but got a lot of conflicts. So I strongly suggest to use subdomains. So I ended up like this:
domain.com serving my static page
api.domain.com serving Strapi
You can achieve that having your configuration file in NGINX like:
server {
server_name domain.com www.domain.com;
root /var/www/domain.com/html;
}
server {
server_name api.domain.com
location / {
proxy_pass http://127.0.0.1:1337;
proxy_http_version 1.1;
}
}
As you can see there is a lot of configuration you will need to perform, so I won't recommend trying something like this in Heroku since you really don't have much control of the Dyno (ports, routing, etc). If you want to go with Heroku then, you should have a separate Dyno for each app. One for Strapi and a separate one for the other app.
I would strongly suggest something like DigitalOcean or any other where you have total control over your server in Digital Ocean called a Droplet. I was able to install on the same Droplet an instance of Strapi and serve my static site built in Gatsby.
I have a web server using cpanel and I would like to use a custom domain on one folder for an api. So if I created a folder called api in the public_html folder then the path to that folder would be www.example.co.uk/api/(some php file). How could I change it so the folder would become a custom domain of api.example.co.uk/api/(some php file).
I have looked at a few options but don't really know the best way. I have tried to add a htaccsess file to the api folder and then create a rewrite rule to rewrite the www to api.
I also then looked at creating sub domains with the path to the api folder.
I have read that creating a A record on the server could work but I'm not quite sure how to do this. I know it can be done as most apis use some custom domain like facebooks graph api. (i.e https://graph.facebook.com/youtube/)
This will depend on if you have access to make DNS records for your root domain, example.co.uk. For example right now www. is a CNAME or A record (depends on how your web server is set up), that resolves to the address of your web server. If you made an identical record but named it api. (api. IN A ip-of-webserver), then api.example.co.uk would do the same thing that www.example.co.uk does. This is kind of pointless if they go to the same web server though, the /api/ part of the route makes it clear enough that the routes are for the api. What subdomains like facebook's are doing are pointing to a completely different application, and different web servers. For example, a company may have domains like mail.company.com, portal.company.com, sso.company.com, that all resolve to the address of different web servers for the different apps they have, but in this case it sounds like you are running one web server which is fine, you can have one web server be the api as well as serve the website.
I am creating my first MEAN2 app, but I stuck in mid. My site required one front-end (mysite.com) and one back-end(admin.mysite.com) to manage content. In future I would like to have a unique URL (*.mysite.com) for all the uses who will register at my site, for which there would not be a any directory in real. How could I acchieve it in a best way. To be more clear my requirement is -
mysite.com (original site)
admin.mysite.com (a sub-domain to be managed from same server.js file)
*.mysite.com (based on request host)
Note: I have created site using angular-cli are my structure is like below
-mysite(angular 4 app)
-admin(another angular 4 app)
-server.js
This problem is not specific to node.js. However, in order to setup a domain successfully for your web app, you'll need 2 things:
Web Server
This will manage for you virtual hostnames etc. I would advise you to look at setting up nginx as a reverse proxy in front of your node app.
Domain provider
This will actually allow you to publicly use the domain *.mysite.com. Then you will have to setup a DNS Record, generally an A record, to point at your server IP Address.
This is very high level :) but should be enough to get you started.
EDIT
If you want to test locally just setup nginx with a test server name to proxy_pass to your local nodejs app (i.e. http://localhost:3000) and create a host entry in your hosts file for that hostname.
I'm moving from Apache on Linux to Azure Web Apps and I have a specific url (mysite.com/blog and everything under it) that is configured with a reverse proxy so the end user doesn't know that the content is actually coming from another service.
I'm sure I can do this within Web Apps (which runs on IIS) but I can't find any documentation on how to do this. As a backup I'm open to putting another service in front of my Web App.
How can I accomplish this in Azure?
Update: I did try using another service - Functions. My architecture looks like this:
This works in production but I'm hitting snags in development. /blog may or may not work depending on the entry point. In prod, our DNS will be configured so mysite.com points to mysite-proxy.azurewebsites.net and, therefore, any URI the user hits will work. In dev, however, we may want to browse to hit /blog from the Traffic Manager which will route us to /blog on the webapp which doesn't exist. Same problem, of course, if we go to /blog directly on the webapp. I tried to show these examples on the right side of the diagram.
I would like to find a solution so the webapp itself can handle the /blog proxying and then we can determine whether it's worth the speed and cost tradeoff compared to the existing solution.
You might want to checkout Azure Functions Proxies: https://learn.microsoft.com/en-us/azure/azure-functions/functions-proxies
Sounds like you want an Application Gateway (caution, costs like $15/day)
The AGW can have multiple listeners against multiple hostnames, including path-based routing.
You will want to add two backends, one for the /blog endpoint and one for the non-/blog stuff. The backends just take the IP or FQDN of the target resource, in this case you will have:
blogBackend: myblog.com
defaultBackend: myWebapp.azurewebsites.net
Then you need to add listeners for your public-facing domain, it would be like:
myHttpListener: port 80, hostname=mywebsite.net
myHttpsListener: port 443, hostname=mywebsite.net
Then you need an HTTP setting
myHttpSetting: protocol=HTTPS, port=443, useWellKnownCACert=Yes, HostnameOverride=Yes,pick from backend target
Then you need rules, one for http=>https redirect, and the other for handling the pathing
myRedirectRule: type=basic, listener=myHttpListener, backendtargettype=redirection, targettype=listener, target=myHttpsListener
myRoutingRule: type=path-based, listener=myHttpsListener, targettype=backendpool, target=defaultBackend, httpSetting=myHttpSetting, pathRules=
path=/* name=root backendpool=defaultBackend
path=/blog name=blog backendpool=blogBackend
You can create additional http settings and assign them to the path rules to change the behaviour of the reverse proxy. For example, you can have the user's URL be https://mywebsite.net/blog, but have the path stripped on the request to the blog so the request looks like myblog.com instead of myblog.com/blog
There's a lot of tiny parts, but the app gateways can handle multiple applications at scale. Biggest thing is to watch out for the cost since this is more of an enterprise solution.
I'm writing an app using Meteor for company inventory management. Each company will get their own subdomain, but essentially they'll all be using the same code & routes, the only difference being that depending on the subdomain the subscribe/publish/log-in will be unique to that subdomain.
For example, costco.myapp.com will only subscribe to the data that pertains only to costco.
My question would be how do I successfully create/implement subdomains using Meteor that use the exact same code/routes, but publish collection info only relevant to that subdomain?
I assume you want to know how to inspect the app url using Meteor.
Normally this would be accomplished with Meteor.absoluteUrl()
However, this uses the ROOT_URL environment variable, so you will not be able use it to differentiate different urls for the same app instance.
On the client use plain old window.location.hostname instead.