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
backend: add service discovery interface and implement for single host deployments #2600
Conversation
listenPort = DEFAULT_PORT, | ||
} = readBaseOptions(config.getConfig('backend')); | ||
const protocol = config.has('backend.https') ? 'https' : 'http'; | ||
const internalBaseUrl = `${protocol}://${listenHost}:${listenPort}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can listenHost be ::
or 0.0.0.0
for example? Is it always possible to form the url using these components?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should work just fine, changed it to support IPv6 though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably nicer to translate those to localhost even if it happens to work though, updated that too
|
||
const catalogRes = await fetch(`${catalogUrl}/entities/by-name/${triple}`); | ||
if (!catalogRes.ok) { | ||
catalogRes.body.pipe(res.status(catalogRes.status)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fancy. And this works whether there's a body or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should, an empty pipe is still a pipe, no? 😁
c9bb58c
to
880d8b9
Compare
880d8b9
to
4e84e3f
Compare
4e84e3f
to
2a443ce
Compare
943ce8c
to
5893efb
Compare
5893efb
to
1ae59f0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Any docs we should update too?
@benjdlambert couldn't find any docs to update, cept for the changelog |
Ok maybe one for an upcoming docs party. |
@spotify/techdocs-core can I get your approval too? |
Fixes #1847, #2596
Went with an interface similar to the frontend
DiscoveryApi
, since it's dead simple but still provides a lot of flexibility in the implementation.Also ended up with two different methods, one for internal endpoint discovery and one for external. The two use-cases are explained a bit more in the docs, but basically it's service-to-service vs callback URLs.
This did get me thinking about uniqueness and that we're heading towards a global namespace for backend plugin IDs. That's probably fine tbh, but if we're happy with that we should leverage it a bit more to simplify the backend setup. For example we'd have each plugin provide its own ID and not manually mount on paths in the backend.
Draft until we're happy with the implementation, then I can add more docs and changelog entry. Also didn't go on a thorough hunt for places where discovery can be used, but tbh I don't think there are many since it's been pretty awkward to do service-to-service communication.