Would be fantastic to be able to use custom domains for the API endpoints. The main reason behind this idea would be in the case that we need to migrate out from Graphcool to another platform. Or from another platform to Graphcool.
On mobile apps we depend on users to update the app, and if we change the endpoint of the API with a different domain, users are forced to update the app or it will stop working. That's not acceptable.
So, we should be able to provide custom domains and even the endpoint URL to access the Graphcool APIs.
+1 for this.
Also, some people might want to make this API public to users. In which case it helps if it is easily accessible under e.g a subdomain of our own site.
A workaround for the issue of updating mobile apps is to have the API endpoint URL served in a json file from a static web host on a domain of your choice and have the app get the endpoint to use from that before accessing the actual API
I would highly recommend shipping configuration to the app independent of the app store like Dan suggests. That has saved me on previous projects.
But I also think custom api domains has value. I'm curious - @enricenrich and @sedubois have you tried already setting up a cname with your own dns? I don't see why this wouldn't just work. Is there any other specific support you would need from us?
@sorenbs A few months ago I tried to setup a CNAME with CloudFlare but it didn't work for some strange reason. Can try it again tho'.
And nope, nothing specific for you to support, just the option to have custom domains 馃憤
Please let us know how it goes :-)
A CNAME record would help for the 'api.graph.cool' part, but not for the /simple/v1/projectId part. Also, a CNAME record might introduce CORS issues, but I haven't tested it...
The projectId might be worked around using an alias, and if you need to switch to a different project, reuse the same alias after removing it from the old project.
@sorenbs Like @kbrandwijk says, CNAME worked for the api.graph.cool domain, but not for the API endpoint. It just doesn't work.
Ahh, now I see what you are saying.
So, there are two parts of the uri that you want to control: the domain and the path.
The domain can be handled on the dns level with a cname as you have verified. enabling the cname is very un-intrusive and allows you to continue to take advantage of the Graphcool routing infrastructure as described in https://www.graph.cool/docs/blog/introducing-regions-and-better-performance-she7yaab6l/ as well as new features we will introduce in the future.
The path can not be handled on the dns level, so if it is important for you to have something else than /simple/v1/projectId in the uri there are basically two options. Either Graphcool introduces explicit support for custom paths (maybe in combination with cnames) or you use a proxy like nginx or AWS API Gateway. If you decide to set up a proxy you will loose the benefits of our routing infrastructure.
Let's keep this ticket open so we can gather more use cases.
@sorenbs That's it 馃槉
Ideally the best solution in my opinion would be that Graphcool introduces explicit support for custom paths and domains. And like you say, I don't think that a proxy is a good solution because we would loose the benefits of your routing infrastructure.
Is the CNAME approach supposed to work right now? I would expect there to be issues with the Graphcool SSL certificate not matching the domain.
@stuhlmueller You are totally right about the ssl certificate being an issue.
So long story short is that Graphcool needs to introduce explicit support for custom domains.
@sorenbs Yes, Graphcool needs to support custom domains 馃槉
Regarding to this topic and talking about SSL certificates; to provide with SSL support for those custom domains I would suggest you to use Let's Encrypt like Heroku is doing now 馃憤
This issue has been moved to graphcool/graphcool-framework.
Most helpful comment
@stuhlmueller You are totally right about the ssl certificate being an issue.
So long story short is that Graphcool needs to introduce explicit support for custom domains.