api: Create a new Go module for API; with remote write client and handler.

[bwplotka]

I wanted to proposeremotewrite module for generic PRW client and handler code. During PromCon audienced asked exactly about this.

Lot's of assumptions here:

• We want separate module (we don't have processes on how to version it and release).
• We want to expose generated protos, without gogo.
• Do we need v1 PRW?

TODO:

• Check if we want to reuse this "weird" httpClient, is it useful?
• Add examples, documentation
• Try using it in Prometheus before merging.

[ArthurSens]

Interesting idea :)

I like that we're doing this in a separate module, but we could do this move in stages maybe? What do you think of moving our HTTP API (the one that calls Prometheus API for instant_query, query_range, etc) and see how versioning and releases would work with that move?

The rationale I'm having here is that worrying with new functionality AND how to handle versioning in the same PR is probably to much...?

[bwplotka]

Yea, I am curious how to do this the best here, given we already have v1 package in the same repo and module.

My main intention is NOT to solve #1649 (comment) in this PR, but rather experiment on reusable remotewrite package/module, ppl can use now on different projects (Otel, Prometheus, avalanche, some other side projects). 🙈

How to get that to this point the fastest? I can't put it in the main module given proto and vtproto deps... Moving API to different module is not pressing now and I even proposed a separate Go module remotewrite vs other HTTP API, given protobuf deps, but maybe it's too small module to manage, given the feedback.

That's why a draft. I might just use this as a source of truth and reference this branch for now 🙃

[bwplotka]

I think I might then put it in the current module. If I scope out vtprotobuf helpers (but still allow it for advanced users) and vendor backoff we might be able to NOT increase deps here with this 🤔

[bwplotka]

But then it's not clear where to put it. api.go was built in very non-flexible way. We do say it's experimental versioning, but as we discussed, this impacts users nevertheless.

Then for remote write we also want to offer receiving handler, which does not fit within v1 api really 🤔

cc @jmichalek132 as it might help you in the implementation of client in Otel?

[bwplotka]

Closing this, in favor of #1658