Fix #664: Use API_URL from .env for telescope API #690
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue This PR Addresses
Fixes #664
Type of Change
Description
This adds an
API_URL
environment variable, and the logic for using it in various build steps. TheAPI_URL
should be one of the URLs we use for our deployments: localhost, staging, or (eventually) production.You choose the backend you want your frontend to work against by setting this value in your
.env
, or otherwise setting this environment variable. When you run one of the GatsbyJS cli scrips (build, develop, etc) it will read this value via the code insrc/frontend/gatsby-config.js
. Here we'll try to load the root.env
file, and import any environment variables, then try to pick the correctAPI_URL
to use, falling back tohttp://localhost:PORT
if none is found. This means we don't need thehttp-proxy-middleware
anymore, since it will use whatever URL you specify without the need for proxying.In our Zeit Now build, I specify that I want it to always use the staging URL. This way our preview deployments will have live data.
In terms of how you consume this variable in the frontend, I did some research and the way Gatsby wants you to do it is via GraphQL to query the sitemetadata. There are two ways to do this:
<StaticQuery>
, which can work for any component (e.g., ES6 class), but requires you to pass data as props. See https://www.gatsbyjs.org/docs/static-query/I did both because we use both methods in our tree, and now there are examples and reusable code (the custom hook) we can reuse.
I've never used either of these before, so it's possible I'm doing some of it wrong. Check my work.