Thoughts on a new, more general purpose health library?

[Natalie Zamani]

Hi folks!

Awhile back we contributed the dropwizard-health module, which offers some extra functionality for health checks in the Dropwizard framework. I’ve been wanting to separate out the core logic of that library from the Dropwizard glue, similar to the metrics library, because much of it is very framework agnostic, and generally useful.

I’m curious about where you all think might be a good home for that new library though. The current ideas, in order of which I currently prefer:
* A new standalone library
* A sub module of metrics
* a sub module of Dropwizard-health

Any thoughts on this? I want the DW glue to remain in the same library, so that won’t change.

Thanks!

[Jochen Schalanda]

Hi Natalie,

sorry for the late reply. :-)

> I’m curious about where you all think might be a good home for that new library though. The current ideas, in order of which I currently prefer:
> * A new standalone library
> * A sub module of metrics
> * a sub module of Dropwizard-health

I think a standalone library makes sense if the goal is for it to be used in other projects than dropwizard-health or Dropwizard in general.
You're welcome to start it under the umbrella of the Dropwizard organization on GitHub, if you want to go that route.

In general, I think it would also make sense to move dropwizard-health as a core module into Dropwizard, so that people don't have to discover it independently.

So we'd have the standalone library for the framework-independent parts and dropwizard-health as a core module in Dropwizard.
What do you think?


Best regards,
Jochen

[Natalie Zamani]

Hey Jochen!

Apologies for also being late to reply.

I think a standalone library makes sense if the goal is for it to be used in other projects than dropwizard-health or Dropwizard in general. 

Right, that's definitely our goal. Allowing this same logic to be used in apps that use other server stacks or frameworks, as it's really only the bindings to Dropwizard that are dropwizard-specific. 

You're welcome to start it under the umbrella of the Dropwizard organization on GitHub, if you want to go that route. 

And that would be great! I think we (Peter and I) still don't have permissions to create a new repo, but the name we were thinking of for this was health, if we could get help creating that repo in the DW org. :) 

In general, I think it would also make sense to move dropwizard-health as a core module into Dropwizard, so that people don't have to discover it independently. 
So we'd have the standalone library for the framework-independent parts and dropwizard-health as a core module in Dropwizard. 
What do you think? 

We totally agree! It definitely seems less confusing to have this be opt-in functionality in a separate library.

So I think we would first need a new health repo, which I'll need to contribute the framework-agnostic logic into, and then I'll work on consuming that in the core Dropwizard project once that exists. Sound reasonable?

[Natalie Zamani]

> We totally agree! It definitely seems less confusing to have this be opt-in functionality in a separate library.

Sorry! Just to correct this, I meant to say:

It definitely seems less confusing to have this be part of the core project than have it be opt-in functionality in a separate library.