Add unauthenticated API healthcheck endpoint

[katanacrimson]

Doesn't need to do anything fancy, just respond with 200/500 depending on whether the application is running nominally (maybe a SELECT 1 to ensure the database connection is still live?) or not.

This would be useful for container orchestration as a means to ensure application availability.

[diced]

This will be added in V4, check out the roadmap: https://diced.notion.site/Zipline-v4-Roadmap-058aceb8a35140e7af4c726560aa3db1?pvs=4

[superintendent2521]

There will hopefully be ratelimits to it?

[katanacrimson]

That would be unwise - health check endpoints should be light and low-impact to begin with, and healthchecks on some major appliances can be as aggressive as multiple times a second in bursts (ex: AWS ELB healthchecks, even with throttling configured, due to the load-balanced nature of the healthchecks themselves).

[itsnotrin]

I agree with damian here. However, I think we should also add options for endpoints like this that aren’t strictly needed to be disabled, perhaps a toggle on the admin page per-endpoint as well as a bulk “Optional Endpoints” on/off toggle to make Zipline more customisable for each person to fit into different environments perhaps?

[diced]

The current implementation I added into v4 adds IP's into a in-memory map that handles ratelimits. I think a better way would be doing what you guys are saying, having it under some sort of option to enable.

[itsnotrin]

I don’t think I quite got it across right. The ability to toggle endpoints wasn’t related to the aforementioned rate limiting stuff, more so for people wishing to tidy up their installs or simply they aren’t using that portion of Zipline.
Just small things like this to help make Zipline stand out as more customisable pretty much

Edit: I’ll make this a new discussion since it’s a separate feature that I think would be nice to be introduced.