Comments (11)
@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.
Related Issues (20)
- New raptor-browsertime tests instead of old raptor-webext HOT 3
- Add graphs comparing Fission vs non-Fission performance telemetry for Firefox Nightly HOT 8
- simplify expression
- ytp results for chrome are not displayed
- Change ypt results according to 2020 changes HOT 1
- Add more Talos and AWSY test results to Fission health dashboard
- Android PGO builds were renamed to Android Shippable HOT 1
- Migrate dashboards to use autoland instead of mozilla-central data (where possible)
- Removed Nimbledroid from backend HOT 5
- simplify expression
- Migrate browsertime metrics in the dashboard to *SI HOT 3
- Tp6m charts show wrong application
- Tp6m results mixed with webrender
- Fix warm test results for chimera pageload testing mode HOT 1
- https://health.graphics/playback never finishes loading (infinite loop?)
- Update Unity WebGl mobile tests to browsertime
- Private domain & cloudflare HOT 4
- Display a banner suggesting the site may be retired and asking for feedback HOT 1
- Decommission dashboard and redirect users to arewefastyet.com
- Action Required: Fix Renovate Configuration
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from firefox-health-dashboard.