Add design note for health and status endpoints #49
Conversation
|
|
||
| Two endpoints would be added to the Admin API: | ||
|
|
||
| 1. `GET /health` -- on success returns status code 200 and payload `{"status": "ok"}` |
There was a problem hiding this comment.
this is for the overall Node-RED service ? - so yes agree 200 OK fine. (maybe if we want to be detailed could add one for starting and stopping - obviously no response when actually stopped)
There was a problem hiding this comment.
I think that's a great idea!
There was a problem hiding this comment.
I think the /health end point will need to be configurable - both in terms of whether the endpoint is enabled at all, and what url it is exposed on.
We also have two separate route handlers in Node-RED - the admin side and the node side. We need to decide which handler these end-points are on. They are probably admin routes - although we know some users will disable the admin route handler entirely for their production system.
As there will be existing flows that serve up their own /health end point, we may have to disable it by default - and allow it to be enabled via the settings file.
|
|
||
| 1. `GET /health` -- on success returns status code 200 and payload `{"status": "ok"}` | ||
| - Likely don't need to discuss what a fail condition would be since this endpoint is designed to indicate simply that Node-RED is up and running | ||
| 1. `GET /status` -- on success returns status code 200 and payload: |
There was a problem hiding this comment.
Which status object ? They are currently for nodes. Is this scoped to nodes ? in which case then does every node need to be able to provide status ? (imho no) - or to the overall runtime in which case what should it actually contain ?
There was a problem hiding this comment.
@dceejay, I'm imagining it returning an array of the same status objects that the status node provides. Only nodes that provide a status would be included in the return payload.
There was a problem hiding this comment.
none of the status is held as state anywhere apart from in the client browser - hence doing what you suggest now means we have to hold all that state centrally for all nodes just in case - whether there is a browser client or not. I think that is not something we want to do on the offchance someone wants it. I can see the use of an overall status of the runtime - eg maybe showing things like uptime, name of running flow, maybe process cpu load ? that sort of thing - but not state of every single node.
There was a problem hiding this comment.
none of the status is held as state anywhere apart from in the client browser
That's not entirely true. The runtime does have to hold the current status value of all nodes so that when a new editor connects, it is able to deliver the status value to get it in sync.
That said, the node status is meant to be ephemeral internal state of the flow - used by the flow itself in its operation - it wasn't something intended to be exposed via admin apis. A flow could be created to expose node status if the flow author wants to do so - but that isn't a pattern I have ever seen mentioned in the community.
So it is technically possible to do, I would like to understand the specific use case for it a bit more.
|
@dceejay ? |
|
@dceejay It looks like this branch has been pending your approval/review for the last two years. Got to digging for a health endpoint for node-red, and came across this. |
|
@XtremeOwnageDotCom there are unresolved review comments from both @dceejay and myself. There hasn't been much community demand for this, so it hasn't had much attention to chase up. |
Adds a design note and updates root README for proposed new endpoints on Admin API.