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

Readiness api endpoint #437

Open
3 of 6 tasks
purge opened this issue Feb 23, 2024 · 3 comments
Open
3 of 6 tasks

Readiness api endpoint #437

purge opened this issue Feb 23, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@purge
Copy link

purge commented Feb 23, 2024

Feature description

worker API that can determine whether worker is up-and-running

Motivating example

when kubernetes is running a pod it has several probes to determine its status (startup, readines, liveness)
while I could touch a file on an event handler this would require ephemeral storage on a read-only filesystem.

A useful pro feature could be to allow for an endpoint /readiness which can respond with a 200 when worker is up and running.

Breaking changes

None

Supporting development

I [tick all that apply]:

  • am interested in building this feature myself
  • am interested in collaborating on building this feature
  • am willing to help testing this feature before it's released
  • am willing to write a test-driven test suite for this feature (before it exists)
  • am a Graphile sponsor ❤️
  • have an active support or consultancy contract with Graphile
@benjie
Copy link
Member

benjie commented Mar 4, 2024

It's possible to build a system for this based on the eventing system #155 - I've done so for clients before. And yes, this is one of the planned features for Pro; Worker itself will never come with a bundled HTTP server.

@benjie benjie added the enhancement New feature or request label Mar 4, 2024
@jcgsville
Copy link
Contributor

We built a duct-taped solution for this at Logixboard too. I could be interested in building a public version of this feature if it is not on your short term roadmap.

I'm also open to adding it to pro, despite pro not being OSS. Not dogmatic on that, and happy to give back to graphile :)

Otherwise, maybe a 3p library that people can install? I imagine y'all have a trademark on the name Graphile Worker, so is something like graphile-worker-readiness-api acceptable? I want to respect y'all's branding.

@benjie
Copy link
Member

benjie commented Dec 18, 2024

Sorry this got buried in my notifications a bit! This is something I plan to add to pro at some point next year, but have higher priorities right now. I've no issue with you releasing one as OSS and calling it graphile-worker-readiness-api or similar :) Anything that we did would be under @graphile/* or @graphile-pro/* most likely, so I don't see any risk of naming conflicts there.

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

No branches or pull requests

3 participants