Fetch settings values from settings service #475
Conversation
|
At the moment the generated JS client for retrieving settings is using POST requests internally, for everything. We are working on changing this to something more RESTful. |
|
Are you ok with moving the generated settings client into a |
Yeah, would be nice to make it clear this way that it's not something developers should edit. |
kulmann
changed the title
| } catch (error) { | ||
| // fail on anything except settings service being unavailable | ||
| // TODO: if this changes to GET requests in the future, this will be 404 instead of 502 | ||
| if (error.response.status !== 502) { |
There was a problem hiding this comment.
now thinking, there might also be a risk that if the service is just down (but configured) that Phoenix would revert to default values instead of showing an error. we can consider this case in a separate issue
This PR introduces a new
settingsclass, which is responsible for fetching settings values from the settings service. It does so by using the generated JavaScript client (src/settingsClient.js). So please don't reviewsrc/settingsClient.js, as it's generated.As said generated client relies on Axios, this PR also introduces Axios. The bearer token - if present - is injected in
src/helperFunctions.js, so that axios requests can be made everywhere else in the code as well.The function
getSettingsValuesfromsrc/settings.jswill be used in Phoenix. I will link a Phoenix PR here, soon. The code is supposed to fall back to defaults, if the settings service is unavailable. We'll have to discuss, if those defaults are supposed to live in the SDK or in Phoenix. But in my opinion that can be solved later on.