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

Web console: single instance of axios for all network requests #10408

Closed
wants to merge 16 commits into from
Closed

Web console: single instance of axios for all network requests #10408

wants to merge 16 commits into from

Conversation

AshishKapoor
Copy link
Contributor

@AshishKapoor AshishKapoor commented Sep 18, 2020

Fixes #10402. As proposed.

Description

Make use of a single instance of axios for the network requests.

Makes it easy to configure network calls with axios


This PR has:

  • been self-reviewed.
  • been tested in a test Druid cluster.

Key changed/added classes in this PR
  • axios imports

Sincerely
Ashish Kapoor

This is in effect with the issue id: 10402
@vogievetsky
Copy link
Contributor

Isn't the current usage of Axios already using a single (global) instance? As defined here: https://github.com/axios/axios/blob/master/lib/axios.js#L29

Is the idea of this to migrate the instance configuration from the defaults ( https://github.com/apache/druid/blob/master/web-console/src/entry.ts#L72 ) to this singleton Api file?

@AshishKapoor
Copy link
Contributor Author

AshishKapoor commented Sep 18, 2020

Is the idea of this to migrate the instance configuration from the defaults ( https://github.com/apache/druid/blob/master/web-console/src/entry.ts#L72 ) to this singleton Api file?

@vogievetsky Yes, you are correct!

One place to configure axios for the network requests and services. This way we can further define and separate all the network requests out of the views (in future).

Copy link
Contributor

@vogievetsky vogievetsky left a comment

Choose a reason for hiding this comment

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

This PR currently breaks the existing configuration route.
Try adding "customHeaders": { 'x-test-header': 'this-is-a-test' } to the console-config.js file and see that the custom headers will not be applied. This is because while you are creating a custom instance you are still setting Api.defaults which will not be read now.

I suggest you make a method called Api.initialize that will take the configs and create the instance. It must be called before any API requests can go through (in entry.ts).

@@ -70,14 +70,14 @@ if (typeof consoleConfig.title === 'string') {
}

if (consoleConfig.baseURL) {
axios.defaults.baseURL = consoleConfig.baseURL;
Api.defaults.baseURL = consoleConfig.baseURL;
Copy link
Contributor

Choose a reason for hiding this comment

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

These will now be ignored

@AshishKapoor
Copy link
Contributor Author

AshishKapoor commented Sep 21, 2020 via email

@ccaominh
Copy link
Contributor

This PR currently breaks the existing configuration route.
Try adding "customHeaders": { 'x-test-header': 'this-is-a-test' } to the console-config.js file and see that the custom headers will not be applied. This is because while you are creating a custom instance you are still setting Api.defaults which will not be read now.

I suggest you make a method called Api.initialize that will take the configs and create the instance. It must be called before any API requests can go through (in entry.ts).

Is it possible to add a test so that CI can help ensure this doesn't break in the future?

@AshishKapoor
Copy link
Contributor Author

This PR currently breaks the existing configuration route.
Try adding "customHeaders": { 'x-test-header': 'this-is-a-test' } to the console-config.js file and see that the custom headers will not be applied. This is because while you are creating a custom instance you are still setting Api.defaults which will not be read now.
I suggest you make a method called Api.initialize that will take the configs and create the instance. It must be called before any API requests can go through (in entry.ts).

Is it possible to add a test so that CI can help ensure this doesn't break in the future?

@ccaominh maybe we can re-run the failed travis-cI test case. Please let me know how I can get it fixed.

@ccaominh
Copy link
Contributor

This PR currently breaks the existing configuration route.
Try adding "customHeaders": { 'x-test-header': 'this-is-a-test' } to the console-config.js file and see that the custom headers will not be applied. This is because while you are creating a custom instance you are still setting Api.defaults which will not be read now.
I suggest you make a method called Api.initialize that will take the configs and create the instance. It must be called before any API requests can go through (in entry.ts).

Is it possible to add a test so that CI can help ensure this doesn't break in the future?

@ccaominh maybe we can re-run the failed travis-cI test case. Please let me know how I can get it fixed.

I've retriggered (Compile=openjdk8, Run=openjdk8) compaction integration test since the failure doesn't look related to this PR.

I think it'd be useful to add a web console test that ensures that the custom header, etc. are preserved.

@@ -18,4 +18,9 @@

import axios from 'axios';

export const Api = axios.create();
function initialize() {
Copy link
Contributor

Choose a reason for hiding this comment

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

I meant that instead of setting axios.defaults (above) you can pass the instance cnfiguration to the initialize method. So the initialize method would take { baseURL, headers } etc as an argument.

Comment on lines 21 to 57
export const API_ENDPOINTS = {
status: '/status',
properties: '/status/properties',
supervisor: '/druid/indexer/v1/supervisor',
supervisorFull: '/druid/indexer/v1/supervisor?full',
supervisorResumeAll: '/druid/indexer/v1/supervisor/resumeAll',
supervisorSuspendAll: '/druid/indexer/v1/supervisor/suspendAll',
supervisorTerminateAll: '/druid/indexer/v1/supervisor/terminateAll',
task: '/druid/indexer/v1/task',
tasks: '/druid/indexer/v1/tasks',
worker: '/druid/indexer/v1/worker',
workers: '/druid/indexer/v1/workers',
datasources: '/druid/coordinator/v1/datasources',
datasourcesSimple: '/druid/coordinator/v1/datasources?simple',
overlordStatus: '/proxy/overlord/status',
overlordStatusProperties: '/proxy/overlord/status/properties',
coordinatorStatus: '/proxy/coordinator/status',
coordinatorStatusProperties: '/proxy/coordinator/status/properties',
coordinatorCompactionCompact: '/druid/coordinator/v1/compaction/compact',
coordinatorRules: '/druid/coordinator/v1/rules',
coordinatorLookupsConfig: '/druid/coordinator/v1/lookups/config',
coordinatorLookupsConfigDiscover: '/druid/coordinator/v1/lookups/config?discover=true',
coordinatorLookupsConfigAll: '/druid/coordinator/v1/lookups/config/all',
coordinatorConfig: '/druid/coordinator/v1/config',
coordinatorConfigCompaction: '/druid/coordinator/v1/config/compaction',
coordinatorLoadStatusSimple: '/druid/coordinator/v1/loadstatus?simple',
coordinatorMetadataDatasources: '/druid/coordinator/v1/metadata/datasources',
coordinatorMetadataDatasourcesIncludeDisabled:
'/druid/coordinator/v1/metadata/datasources?includeDisabled',
coordinatorCompactionStatus: '/druid/coordinator/v1/compaction/status',
coordinatorTiers: '/druid/coordinator/v1/tiers',
coordinatorLookupsStatus: '/druid/coordinator/v1/lookups/status',
coordinatorServersSimple: '/druid/coordinator/v1/servers?simple',
coordinatorLoadqueueSimple: '/druid/coordinator/v1/loadqueue?simple',
druidV2: '/druid/v2',
druidV2Sql: '/druid/v2/sql',
};
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@vogievetsky we can add all the dynamic endpoints later.

@@ -425,7 +425,7 @@ GROUP BY 1`;
return (
<AsyncActionDialog
action={async () => {
const resp = await axios.delete(
const resp = await Api.delete(
`/druid/coordinator/v1/datasources/${datasourceToMarkAsUnusedAllSegmentsIn}`,
Copy link
Contributor

Choose a reason for hiding this comment

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

In the theme of listing all the API endpoints in once file, I think this one could be extracted also for consistency. Maybe extract it as /druid/coordinator/v1/datasources/%s and then do a .replace('%s', datasourceToMarkAsUnusedAllSegmentsIn) in this function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How about this?

`${API_ENDPOINTS.datasources}/${datasourceToMarkAsUnusedAllSegmentsIn}`,

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hey @vogievetsky

done for all the remaining ones.

@lgtm-com
Copy link

lgtm-com bot commented Nov 23, 2020

This pull request introduces 1 alert when merging db2e46b into 4537016 - view on LGTM.com

new alerts:

  • 1 for Unused variable, import, function or class

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.

Make use of a single instance of Axios in the web-console
3 participants