Skip to content

Instantly share code, notes, and snippets.

@tjquinno
Last active March 4, 2021 14:40
Show Gist options
  • Save tjquinno/d5b5d13d4e1220e6631372c59d2f7d8b to your computer and use it in GitHub Desktop.
Save tjquinno/d5b5d13d4e1220e6631372c59d2f7d8b to your computer and use it in GitHub Desktop.

Background

The Micrometer support I have been adding shares lots of logic with our existing metrics support, on both the SE and MP side. To avoid duplicating code, the inheritance structure I've created looks like this:

MetricsSupport --------+
                       +-- extends --> HelidonRestServiceSupport
MicrometerSupport -----+

and

MetricsCdiExtension ----+
                        +-- extends --> HelidonRestCdiExtension
MicrometerCdiExtension -+

We need Maven modules which will collect the shared behavior and types used from our core technologies (e.g., metrics) and integrations (e.g., Micrometer).

Tomas and I have been talking about this, and none of the existing modules seemed like the right choices.

Proposal

We suggest the following:

Create a new top-level module service-common (result of a vote) containing these submodules (to start with):

Submodule under service-common Contents
rest Types and behavior shared among all Helidon SE services that involve or add REST endpoints (e.g., HelidonRestServiceSupport)
cdi-rest Types and behavior shared among components with CDI extensions that involve or add REST endpoints (e.g., HelidonRestCdiExtension)

Fit for Micrometer

This works well for the Micrometer work. As shown above, both MetricsSupport and MicrometerSupport would extend HelidonRestSupport. Similarly, both MetricsCdiExtension and MicrometerCdiExtension would extend HelidonRestCdiExtension.

Future

Just as importantly, this approach gives us the flexibility to create additional submodules in the future for sharing across other technologies.

For example, here are some other possible future submodules:

Future submodule under service-common Contents
common Types and behavior shared among all Helidon SE services that DO NOT involve or add REST endpoints
cdi Types and behavior shared among components with CDI extensions that DO NOT involve or add REST endpoints

Over time we can also migrate existing technologies (health, OpenAPI, etc.) so their xxxSupport and xxxCdiExtension classes extend these new base classes HelidonRestServiceSupportand HelidonRestCdiExtension.

Alternatives (less desireable)

Existing common module

The modules under the existing common top-level module do not depend on servers (SE or MP) and it would be appealing to preserve that. Adding the proposed rest submodule here would introduce a dependency on the SE server module. Adding the proposed cdi submodule here would add a dependency on the MP server.

Existing microprofile/cdi module

Some technologies, such as Micrometer, are not MicroProfile and it would seem incorrect to put them under a microprofile module.

@spericas
Copy link

I don't think "services" is the right name for these modules. As I understand it, they are not full-fledged services. Terms like "shared" and "support" seem to make more sense to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment