Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client-side routing for recent EMS versions #229

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nickpeihl
Copy link
Member

Status

Proposed for discussion

Context

Since 7.6 EMS and ems-landing-page releases have matched the Elastic Stack minor releases. Currently, each release of ems-landing-page (v7.6, v7.7, v7.8...) is created in a new branch and each branch is published as separate applications in subdirectories in a Google Bucket.

The region maps visualization and Elastic Maps application in Kibana includes links to the matching release of EMS landing-page. For example, Kibana v7.4 links to https://maps.elastic.co/v7.4, Kibana v7.6 to https://maps.elastic.co/v7.6, and so on).

Because each version of ems-landing-page is a live website, we do our best to maintain security updates for all versions. Currently, this requires us to backport fixes to all previous branches and fix merge conflicts when necessary which is time consuming.

To eliminate this tech debt, I am proposing switching to a client side routing technique using React Router. Because of limited changes to the schema of the EMS manifests, the current ems-client library supports versions of EMS >= v6.6.

Decision

TBD

Consequences

This PR is a moderate refactor that uses react-router to load the corresponding EMS manifest version based on the URL path. This allows us to maintain a single codebase without requiring backports that can cause merge conflicts.

There were significant changes between EMS v2 and EMS v6.6 manifests which will require more work to implement. Breaking changes in future EMS manifest versions may become harder to implement. We might consider maintaining separate branches for major EMS versions that have breaking changes (v2, v6.x, v7.x, v8.x).

@thomasneirynck @nyurik @jsanz

Does not yet support EMS <= v2
@kibanamachine
Copy link

💚 Build Succeeded

@jsanz
Copy link
Member

jsanz commented Aug 19, 2020

It definitely improves the situation to move from needing a deploy per minor to one per major and the rest left to the client. I would also consider v2 as deprecated for the landing page, so we shouldn't have to update it anymore.

How can we test this? I've tried with browser-sync with the single option but even it renders the main page, then the route for the JS bundles is not resolved, so I'm probably trying this in the wrong way

npx browser-sync start --server build/release --single

@kibanamachine
Copy link

💚 Build Succeeded

@nickpeihl
Copy link
Member Author

How can we test this? I've tried with browser-sync with the single option but even it renders the main page, then the route for the JS bundles is not resolved, so I'm probably trying this in the wrong way

npx browser-sync start --server build/release --single

For now, yarn dev is the only way to test. I haven't fixed the yarn build process yet.

@kibanamachine
Copy link

💚 Build Succeeded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants