Modernize platform-health about firefox-health-dashboard HOT 11 CLOSED

@digitarald @stuartphilp @eliperelman Just so this does not come as a surprise.

I've decided to separate the backend/frontend code into their own directories and boilerplate.
I can make Heroku start both up.

This will make it easier to move the forward the frontend without breaking the backend.

This all steams from that I tried to include react-metrics-graphics (for a frontend issue) and I started getting backend production-specific issues (#21 (comment)).

I was hoping that switching to Neutrino for both parts (backend and frontend) would make it easier to add new packages but the build complexity of webpack.config.babel.js and app.js has proven challenging.
See master...armenzg:switch_neutrino

If any of you have sample project I could look at to determine project layout it would be great.

from firefox-health-dashboard.

If the outcome is a project that is as performant, easier to maintain and has better developer ergonomics, I am for it.

from firefox-health-dashboard.

I'm going to take a step back to evaluate if we can avoid separating the project into two.
I'm going to revisit the production speficic issue when trying to introduce react-metrics-graphics:
#21 (comment)

If I can't I will separate frontend and backend into different repositories since it makes the deployment story with Heroku nicer. I will explain why.

Heroku only likes one Procfile per repository and only 1 web process, thus, requiring two different apps and pushing subtrees.

The document I followed:
http://adampaxton.com/how-to-deploy-to-multiple-heroku-apps-from-the-same-git-repository/
I've managed to deploy a frontend app with code from the frontend directory, however, that requires manual intervention. It requires pushing a subtree to one of your branches.

Side notes with regards making the static buildpack to work:

From reading this:
https://gist.github.com/hone/24b06869b4c1eca701f9#building-assets-on-heroku

Configured the Heroku remote:

armenzg@armenzg-mbp frontend$ heroku git:remote -a platform-health-frontend
armenzg@armenzg-mbp frontend$ git remote -v
heroku https://git.heroku.com/platform-health-frontend.git (fetch)
heroku https://git.heroku.com/platform-health-frontend.git (push)
origin [email protected]:armenzg/platform-health.git (fetch)
origin [email protected]:armenzg/platform-health.git (push)
upstream [email protected]:mozilla/platform-health.git (fetch)
upstream [email protected]:mozilla/platform-health.git (push)

Added the right buildpacks:

$ heroku buildpacks:clear
$ heroku buildpacks:add heroku/nodejs
$ heroku buildpacks:add https://github.com/hone/heroku-buildpack-static

Added static.json and removed the Procfile.

from firefox-health-dashboard.

@stuartphilp since I'm going to split and rename the repository, can we rename the project to firefox-release-dashboard or firefox-health or similar? I want to drop the name platform from it.

Forward plan:

• Have two branches: backend & fronted
• Once both work get code into two different repositories (due to Heroku's needs)
• The frontend code will deploy with the current Heroku app to avoid having to rename anything
• When the two apps run locally they should have different ports

Few technical details (kudos here to @eliperelman):

• Use Neutrino instead of webpack
• Remove server.js as it is unneded for Neutrino
• Rename src/app.js to src/index.js
• Remove the static cache since the UI's static assets won't be served from node

from firefox-health-dashboard.

I have the backend running here:
https://platform-health-backend.herokuapp.com/api/perf/benchmark/speedometer
I removed flushing to CDN and I have to fix the test script.

I have the frontend running based on data from the backend instance:
https://platform-health-frontend.herokuapp.com/

I need to fix the routing, status of benchmarks, the favicon and few other minor things.
I've also noticed few postcss warnings like:

6:5 ⚠ Custom property ignored: not scoped to the top-level :root element (:root { ... --fontSize: ... }), in atrule [postcss-custom-properties]

The branches used are:
master...armenzg:frontend
master...armenzg:backend

from firefox-health-dashboard.

The frontend is working and running against the official backend:
https://firefox-health-dashboard.herokuapp.com/quantum
The new backend repo will be this:
https://github.com/mozilla/firefox-health-backend

On Monday, as preparatory steps, I would like to switch the 'platform-health' GH repo to be 'firefox-health-dashboard'. I will need to make the 'platform-health' Heroku app point to the renamed repository.

For now, I won't rename the Heroku app to firefox-health-dashboard since it would break the domain.
I believe http://health.graphics/ points to https://platform-health.herokuapp.com
This will be the last step. I need to finish the backend.

from firefox-health-dashboard.

Would you like the original code of 'platform-health' to be tagged with 'original'? or to branch it?

from firefox-health-dashboard.

I've landed the backend and frontend changes.
We're fully live.

I've adjusted a couple of variables in the Heroku platform-health app to point to the backend and to deploy a static app.

We now have 2 fx-health pipelines. One for the frontend and one for the backend.
We have support for review apps for each one.
I've also fixed that Travis was always failing and support for coveralls.

The FE now loads a bit faster than the previous set up (2-3 seconds).
I assume it is because the backend now takes less time to calculate the data for each API.

Here’s the timing of Heroku FE to Heroku backend (the refactoring work):
https://cl.ly/0P1a2d0W0218 Finish: 4.44s DOMContentLoaded: 2.04s load: 5.43s
https://cl.ly/2Q0i0N3i420S Finish: 3.94s DOMContentLoaded: 1.09s load: 4.18s

Here’s the current health page:
https://cl.ly/2o3q1u100E24 Finish 8.09s DomContentLoaded: 2.18s load: 8.13s
https://cl.ly/3D2P3316013S Finish 7.09s DomContentLoaded 1.25s load:7.58s

from firefox-health-dashboard.

DOMContentLoaded isn't going to be very useful for timing this since it's not measuring anything meaning related to paint in a SPA like this.

You could either inject your own timings using UserTiming, or look more into the amount of data being transferred.

from firefox-health-dashboard.

I assumed the Finish and load values are more meaningful.

The amount of data was pretty much the same between the two.

from firefox-health-dashboard.

They are meaningful, but not so much in the context of a SPA when the page is rendered async.

from firefox-health-dashboard.