Initial dashboard implementation

[sethvincent]

This implements the dashboard based on existing mockups.

API requests were starting to get complicated enough that the use of a state management library seemed necessary. I went with unistore because it is very similar to redux while cutting down considerably on both the library size and amount of boilerplate code required compared to redux.

So far I've focused on usage with tasking manager 2, but includes work to make it compatible with tasking manager 3.

[sethvincent]

I'm totally stumped by some weird behavior:

When I request api('get', '/api/projects/') from the dashboard while logged out, I get the response I expect.

When I request api('get', '/api/projects/') from the dashboard while logged in, I get the same response as when I request /auth/userinfo.

It doesn't matter if this api request happens inside of an action or just called directly in a component method.

When I visit the /scoreboard/api/projects route in the browser I always get the JSON response I expect.

My best guess right now is that it has something to do with the port 3000 -> 5000 proxying that happens. I don't fully understand how this proxy works, though.

@kamicut I'm hoping you'll have an idea about what's happening here.

[scisco]

@sethvincent the issue you are having at when calling the api endpoints in the browser and getting json errors I think is related to this: https://github.com/developmentseed/scoreboard/blob/master/frontend/src/index.js#L9

The other issue might be related this: #43 (comment)

[sethvincent]

So far I'm not seeing any difference with the service worker disabled (including making sure the service worker is unregistered).

I've worked around it by not using axios for that request, so the PR as it is now works.

[scisco]

@sethvincent great. I like removing axios all together and also i think we should separate the api frontend sooner than later.

[scisco]

This looks good to me. I think as this gets more complicated and we have a good amount of data and associated logic, we should move to properly use redux here.

[kamicut]

@sethvincent great. I like removing axios all together and also i think we should separate the api frontend sooner than later.

What do you mean by separate the api frontend?

[scisco]

@kamicut the API is currently accessed as a proxy under the same URL used for the frontend. For example if you are running the api on localhost:3000 and dashboard on localhost:5000, you access the api via locahost:5000/api instead of localhost:3000/api. This is possible with the use axios but it has a number of disadvantages and make the setup very complicated.

I think we should stop using this sort of proxying and just call the API endpoint directly.

[kamicut]

I disagree with this @scisco. I think that we should take the opposite route of just rendering the pages from the server to simplify deployment. This would remove all the proxying and help with rewriting URLs related to logins.

For example, this line in https://github.com/developmentseed/scoreboard/blob/master/frontend/src/containers/Dashboard.js#L141 (and others around the app) does not make sense when hosting a public version of scoreboard. We should rewrite localhost:5000:

• Rewrite APP_URL on the server and render the page on the server (this is the simplest logic)
• Create a frontend REACT_APP_URL that replaces this at build time (this is the simplest fix, but requires two environment variables, APP_URL on the server and REACT_APP_URL on the frontend) cc @sethvincent

[scisco]

I think we are talking about two different issues. I agree with your vision of combining the api and frontend and make it into a dynamic site (similar to a flask app) rather than a static one.

@sethvincent and I are only trying to fix the way it is currently working. We should work on your idea of combining the api and frontend into a single app separately I think.