Open marktani opened 6 years ago
Comment by sedubois Monday Jul 24, 2017 at 08:09 GMT
+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.
Comment by danmkent Tuesday Jul 25, 2017 at 12:44 GMT
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
Comment by sorenbs Thursday Jul 27, 2017 at 10:33 GMT
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?
Comment by enricenrich Thursday Jul 27, 2017 at 10:37 GMT
@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 👍
Comment by kbrandwijk Thursday Jul 27, 2017 at 11:19 GMT
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.
Comment by enricenrich Thursday Jul 27, 2017 at 11:29 GMT
@sorenbs Like @kbrandwijk says, CNAME worked for the api.graph.cool
domain, but not for the API endpoint. It just doesn't work.
Comment by sorenbs Thursday Jul 27, 2017 at 11:43 GMT
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.
Comment by enricenrich Thursday Jul 27, 2017 at 11:45 GMT
@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.
Comment by stuhlmueller Friday Jul 28, 2017 at 19:20 GMT
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.
Comment by sorenbs Friday Jul 28, 2017 at 20:15 GMT
@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.
Comment by enricenrich Friday Jul 28, 2017 at 21:16 GMT
@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 👍
Issue by enricenrich Sunday Jul 23, 2017 at 13:24 GMT Originally opened as https://github.com/graphcool/prisma/issues/325
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.