Allow frontend to accept different URLs

[ohaiwalt]

Problem

While trying to set up a staging environment, we found that the operationcode.org URLs are hardcoded into the frontend, because it previously only supported local development and production. It should be flexible enough to allow other environments or URLs. This is in support of https://github.com/OperationCode/operationcode_infra/issues/40

Definition of done

Environment variable to specify desired running URL, or some means of selecting where we're running.

[kylemh]

I'm not exactly sure what you mean by "URLs are hardcoded into the front-end".

There are a few places where the URL is hard-coded, but I need to know more in order to isolate the issue. My first hunch could be process.env.OC_HOST in scripts/build.js or in src/config/environment-prod.js

[nellshamrell]

I think I see the issue here:

api.operationcode.org

We hardcode api.operationcode.org in severakl places in the front end - in particular:

src/scenes/home/codeSchools/codeSchools.js

  componentDidMount() {
    axios
      .get('https://api.operationcode.org/api/v1/code_schools.json')
      .then((response) => {
        const schools = response.data.reduce((acc, school) => {
          school.locations.forEach((location) => {
            acc.push(Object.assign({}, omit(school, ['locations']), location));
          });
          return acc;
        }, []);
        this.setState({ schools });
      })
      .catch(() => this.setState({ errorResponse: true }));
}

And

  componentDidMount() {
    axios
      .get('https://api.operationcode.org/api/v1/team_members.json')
      .then((response) => {
        const boardMembers = response.data.filter(x => x.group === 'board');
        const staffMembers = response.data.filter(x => x.group === 'team');
        const boardChair = 'David Molina';
        const CEO = 'Conrad Hollomon';

        this.setState({
          boardMembers: this.getOrderedGroup(boardMembers, boardChair),
          staffMembers: this.getOrderedGroup(staffMembers, CEO)
        });
      })
      .catch(() => this.setState({ errorResponse: true }));
}

In the staging environment, this url is going to be different, something along the lines of "staging.api.operationcode.org". This should be something that we can change per environment - there are a couple of ways to do this.

1) I'm wondering if we could add an environment-staging.js config here. I'm not hugely familiar with environments in node, but I'm wondering if this would let us refer to the environmental variables? 2) We could populate those environmental variable through Kubernetes secrets, similar to what we do with the backend environmental variables. I do not currently know of a pattern to do this, but we could research it.

@kylemh, does that make sense? @ohaiwalt, does this sound along the lines of what your are looking for?

[nellshamrell]

Might need to do something in the build script as well https://github.com/OperationCode/operationcode_frontend/blob/c831a872ffc4579157cbedf7feb4de5f7091d649/scripts/build.js

[kylemh]

This is perfect.

I can map it such that locally I'm hitting the staging API, but when the application builds, it uses master. Is that satisfactory?

[nellshamrell]

I'd like to have a frontend staging environment on the web that can use the staging api.

[kylemh]

Is this meant to be for gating releases? Are we moving away from CI?

If that's the situation, I'll fuck with Travis to supply an environment variable for non-master branches such that local and feature branches utilize staging and master will use prod API. How's that?

[nellshamrell]

We are definitely keeping CI.

What I'm looking for is a way to have a staging environment that we can deploy feature branches to for review before merging them in to github and deploying through our CI (that is my understanding, at least, @ohaiwalt please correct me if I'm wrong there). This will possibly be separate from Travis.

I believe this is something that needs to be done at the code base level for consistency.

[kylemh]

The request URL being dynamic definitely needs to be implemented on a code level. Determining the proper back-end environment given the branch needs to happen at some point in CI.