Open mousetraps opened 5 years ago
mousetraps
commented
5 years ago Figured it out! Turns out it was an SSL issue! Isolated by running through all the CF setup steps on a test app, but it would have been nice to have a more helpful error message.
SachaG
commented
5 years ago I think I just ran into the same issue actually. I was getting 403 errors for all internal GraphQL requests (those going from Meteor to the GraphQL endpoint during SSR). To fix it I did the following:
forceSSL to true in mup.jsIf you found a way to make it work with all CloudFlare features enabled though I'd be very interested.
And yeah the error messages are not very helpful… hopefully this issue goes away altogether with Apollo 2, since there shouldn't be a separate request anymore.
mousetraps
commented
5 years ago Yep, I meant to post an update. I also had to put Cloudflare into "DNS-only" mode, which was quite sad. Was already forcing SSL, and I actually redirect the other way: non-www to www, but I don't think that was necessary step. Additionally found that I had to use Full (strict) on certificates. Looking forward to Apollo 2!
SachaG
commented
5 years ago Let's keep this open until we either find the "real" fix with full Cloudflare features; or we update to Apollo 2 then.
mousetraps
commented
5 years ago @SachaG was just thinking about this... what's special about SSR in CDN mode? IIRC, queries without SSR were going through just fine.
SachaG
commented
5 years ago With the current version of Apollo, when the server needs to access your API data for the SSR process, it makes a query to the GraphQL endpoint with a new request. My understanding is that maybe Cloudflare messes up the process at that point.
In Apollo 2, if I'm not mistaken there is no need to make an actual request anymore, the endpoint can be queries in the same process.
My understanding of all this is pretty fuzzy though so I might be wrong.
eric-burel
commented
5 years ago Hi, the relevant doc about this in Apollo 2 is here: https://www.apollographql.com/docs/react/features/server-side-rendering.html#local-queries and here https://www.apollographql.com/docs/link/links/schema.html
They specifically mention Heroku for example.
To sum it up in Apollo 2 you have a new alternative specifically tailored for server side usage, the Schema Link. Instead of sending an HTTP request to itself to fetch data, Apollo will simply call the schema resolvers directly.
So indeed we can hope that this will prevent such issues, though I am not sure at all of the technical consequences of using the Schema Link vs usual HTTP Link, this is all very new.
SachaG
commented
5 years ago Thanks for the clarification! So are you currently using that schema link in the Apollo 2 branch?
eric-burel
commented
5 years ago Yes it's used in the Apollo 2 branch (here), if you want to test this already it should work as expected
I've narrowed down the issue, but still don't have a solution.
Our setup involves Cloudflare DNS (
https://www.example.com) -> Heroku (https://example.herokuapp.com)Visiting the Heroku instance directly (after modifying
ROOT_URLenvironment variable and thegraphQLendpointURLproperty inMETEOR_SETTINGSto point to the respective heroku urls) works fine. However, visitinghttps://www.example.comyields the following server-side errors. There are no client errors. I suspect this might be related to CORS.Thoughts on a workaround? This issue is slowing down website loads considerably.