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

[Blocked] Query-Service config and runtime configuration of URL path-prefix #151

Closed
wants to merge 7 commits into from

Conversation

tiffon
Copy link
Member

@tiffon tiffon commented Dec 23, 2017

This PR is no longer relevant.

Refer to #198.


Fix #42.

Adds config data from the query service that is separate from the UI config, dubbed querySvcConfig.

Presently, this contains a single property, pathPrefix, which causes the UI to handle being served from a URL prefix, at runtime.

When set, the pathPrefix should be formatted as /xyz.

Query-service changes

Changes in the query-service this PR relies on:

Config injection

  • Related to the UI config regex:
    • Rename DEFAULT_CONFIG to __INJECTED_UI_CONFIG__
    • Change the regex to now handle the return __INJECTED_UI_CONFIG__; replacement
  • Treatment similar to the UI config for the query-service config
    • The variable name is: __INJECTED_QS_CONFIG__
  • If the URL path-prefix is set, it needs to be passed into index.html in a manner similar to the UI config, e.g. as JSON:
    • {"pathPrefix":"/xyz"}

Static assets that need URL rewrites in their content

In order for the URL path prefix to work, the all URLs need to have the prefix pre-pended. This essentially amounts to the reference to the favicon and references to static assets (including references in static assets).

@yurishkuro
Copy link
Member

Incidentally, the URLs are not constants but instead are derived from expressions. Therefore, while possible, rewriting the static asset URLs in the JS files looks precarious and error-prone.

wouldn't they still have a fixed prefix /static/js that is easy to search & replace? Doesn't seem that much different from how the query service would have to pre-process the other files.

const JAEGER_CONFIG = DEFAULT_CONFIG;
return JAEGER_CONFIG;
const DEFAULT_UI_CONFIG = null;
const JAEGER_UI_CONFIG = DEFAULT_UI_CONFIG;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need DEFAULT_ constants? When I originally proposed them I thought they would have some concrete values, and it was easier to search&replace the string JAEGER_UI_CONFIG = DEFAULT_UI_CONFIG than to replace the JS expression on the right hand side. But these are always null anyway, we might as well have JAEGER_UI_CONFIG = null, it's just as easy to search&replace.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could do that.

I think tweaking the name a bit to imply it might be over-written has some value, though:

// use `null` as a fallback value if the query-service does not embed a value
const __INJECTED_UI_CONFIG__ = null;
const JAEGER_UI_CONFIG = __INJECTED_UI_CONFIG__;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for __INJECTED_UI_CONFIG__. I don't think you need the second const, you can simply return __INJECTED_UI_CONFIG__;.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great. Done.

@@ -116,7 +116,7 @@ export default class SearchTracePage extends Component {
!hasTraceResults && (
<div className="ui middle aligned center aligned grid" style={{ marginTop: 100 }}>
<div className="column">
<img className="js-test-logo" alt="presentation" src={JaegerLogo} width="400" />
<img className="js-test-logo" alt="presentation" src={prefixUrl(JaegerLogo)} width="400" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was it using relative url before?

Copy link
Member Author

@tiffon tiffon Dec 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it uses an absolute path.

The image is imported in JS:

import JaegerLogo from '../../img/jaeger-logo.svg';

That does two things:

  • Causes the asset to be stored in /static/media/ with a filename derived from the file's hash
  • Stores the eventual absolute path of the media asset in the variable JaegerLogo

The absolute path is then used in the JSX as you excerpted.

The prefixUrl(...) adds the path-prefix, if it is configured.

@tiffon
Copy link
Member Author

tiffon commented Dec 23, 2017

@yurishkuro

wouldn't they still have a fixed prefix /static/js that is easy to search & replace? Doesn't seem that much different from how the query service would have to pre-process the other files.

It's not that much different, and we can go down that road. It would spare any impact to the initial page-load time and remove the need for react-app-rewired. The expression(s) in main.NNNN.js that would need to be updated are generally of the form:

u.src=t.p+"static/js/"+({}[e]||e)+"."+{0:"03cf6b4e"}[e]+".chunk.js";

The filesize of main...js is around 2 meg.

@ghost ghost assigned tiffon Dec 24, 2017
@ghost ghost added the review label Dec 24, 2017
// prevent code-splitting to allow the URL path-prefix for the site to be
// configurable at runtime
// https://github.com/jaegertracing/jaeger-ui/issues/42
new webpack.optimize.LimitChunkCountPlugin({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so which way are we going, global search&replace of the path in the query service or using this plugin to not split the js files?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yurishkuro Still up for debate.

The main considerations:

  • Primarily - The exact form the loading of JS chunks takes (which is the site of the search/replace) has an unknown level of risk of changing
  • The search/replace in the JS files is not as "clean" as the others
  • The main.js filesize is ~2M, on disk (not sure to what extent that is much of a consideration)

Note: every *.js file, not just main.NNNN.js, must be checked for the static/js path and prefixed if found

So, my main concern is around maintainability.

The above inconveniences allow us to avert a likely hit on initial page-load time, possibly a ~5% increase.

The ideal scenario, IMO, is to do the global replace and if maintaining it is a PITA then revert and go with the plugin approach to not split the files. Not sure how feasible that approach is on the query-service side.

Would that work for you?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I would suggest trying global replace first.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. This PR needs some rework, then.

@tiffon
Copy link
Member Author

tiffon commented Jan 3, 2018

Closing, will re-open when I've reverted the chunkless changes.

@tiffon tiffon closed this Jan 3, 2018
@ghost ghost removed the review label Jan 3, 2018
@tiffon
Copy link
Member Author

tiffon commented Feb 6, 2018

Reopening this PR. Main change necessary, from the previous state, was to revert the removal of the chunk generation.

It's worth noting, this PR requires several changes to the query-service, as noted in the PR description.

@tiffon tiffon reopened this Feb 6, 2018
@ghost ghost added the review label Feb 6, 2018
@codecov
Copy link

codecov bot commented Feb 6, 2018

Codecov Report

Merging #151 into master will increase coverage by 0.02%.
The diff coverage is 95.83%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #151      +/-   ##
=========================================
+ Coverage   90.77%   90.8%   +0.02%     
=========================================
  Files          93      94       +1     
  Lines        1930    1935       +5     
  Branches      383     382       -1     
=========================================
+ Hits         1752    1757       +5     
  Misses        155     155              
  Partials       23      23
Impacted Files Coverage Δ
src/constants/default-ui-config.js 100% <ø> (ø)
src/utils/metrics.js 0% <0%> (ø) ⬆️
src/reducers/config.js 66.66% <100%> (ø) ⬆️
src/constants/default-query-svc-config.js 100% <100%> (ø)
src/components/DependencyGraph/index.js 100% <100%> (ø) ⬆️
src/components/App/TopNav.js 75% <100%> (ø) ⬆️
src/utils/config/index.js 100% <100%> (ø)
src/utils/prefix-url.js 100% <100%> (ø) ⬆️
src/components/App/Page.js 100% <100%> (ø) ⬆️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b7a3e74...cddac1b. Read the comment docs.

@saminzadeh
Copy link
Member

Looking back at this, create react app documents a section on this.

Looks like we are doing this already +1

Copy link
Member Author

@tiffon tiffon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ys can you mark this PR with "Request changes" so merging it will be blocked until the necessary changes in the query-service are ready?

Copy link
Contributor

@black-adder black-adder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this one bit, scrap it all

@ys
Copy link

ys commented Feb 12, 2018

Can you please stop mentioning me all the time here! I think it is about someone else

@tiffon
Copy link
Member Author

tiffon commented Feb 12, 2018

@ys Apologies! I'll block you so it doesn't happen again!

@tiffon tiffon changed the title Query-Service config and runtime configuration of URL path-prefix [Blocked] Query-Service config and runtime configuration of URL path-prefix Feb 13, 2018
@tiffon
Copy link
Member Author

tiffon commented Mar 2, 2018

@yurishkuro Doesn't look like the work needed in the query-service for this PR is going to be on the docket anytime soon... Think it makes sense to close this PR?

@tiffon
Copy link
Member Author

tiffon commented Mar 13, 2018

This PR is waiting on work from the query-service, which is currently not scheduled. So, I'm closing and will mark the ticket as blocked.

@yurishkuro
Copy link
Member

This PR is waiting on work from the query-service, which is currently not scheduled.

Do we have a ticket in the main repo w/ description of what needs to be done? We can tag it "help wanted".

@tiffon
Copy link
Member Author

tiffon commented Mar 18, 2018

@yurishkuro I'll create an issue in the main repo once I create the PR for the <base> approach.

@yurishkuro yurishkuro deleted the issue-42-query-service-config branch January 29, 2020 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

No support for Jaeger behind a reverse proxy
6 participants