Any plans for tickster as a library?

[jacksontj]

I see in the new 1.x branch that the code is no longer in the root of the repo (yay!), but I do see that most of the code is under internal which means that trickster wouldn't be usable as a library anywhere-- are there any plans to allow/enable this type of usage?

[jranson]

That definitely sounds interesting! We've been intentionally placing things deemed worthy of import by other projects into pkg, with the criteria of being simple, useful, portable and unique; and keeping the currently-less-sharable stuff in internal. With 1.0, the intent is to make things as generic, yet customizable, as possible for the existing users and developers. So those exposed packages fit that theme. I would say when we get next merged into master, we can start working on getting more of the core trickster packages into pkg so long as they are refactored to be a little more generic and less intertwined with each other. And with that, help is definitely welcomed :)

[jranson]

@jacksontj there is some interest in giving this a look by a few other stakeholders from the Trickster community. @dmitsh and @alfred-landrum from Sysdig demonstrated to me a prom-specific working POC of an importable Trickster package; it looks like a really good starting point for this feature.

One of the things I am concerned about getting right is ensuring that we make make the package solution simple, easy-to-use and future proof. As we are planning to expose Trickster's HTTP Reverse Proxy/Cache abilities as an origin type itself (outside of time series accelerators) in 1.0, a single generic library may or may not be the best idea. So I think the options are, 1) come up with a single package that is designed well enough to flexibly support all origin types (including non-timeseries caching), or 2) expose origin-type-specific libraries (e.g., /pkg/trickster/prometheus, /pkg/trickster/hrpc) that would be scoped for the features for the specific origin type.

I see benefits to both approaches. Everyone who has inquired about this is developing a solution for Prometheus, so it's possible that Option 2 is more desirable. I invite everyone with an opinion to chime in on this issue so that we can make the right choices. Based on the consensus here, we can come up with the final design and get it shipped. Thanks to everyone for their interest and feedback!

[dmitsh]

I've posted a PR #262 with our proposed approach. This PR incorporates @jranson idea of origin-type-specific libraries.

[jacksontj]

My initial thinking is that approach #2 would be beneficial -- as each system has their own client types etc -- so it would be nice if they mirrored the upstreams. Then trickster the binary could use those same libraries itself (meaning the http -> library translation is done presumably in another library).

[jranson]

@jacksontj @dmitsh @alfred-landrum we have finally merged next into master (I have rebased the POC PR to master). While most of the packages still reside under internal, the good news is that a major overhaul of the 1.0 codebase over the past few months means that every part of the application now uses the basic http handler components (*http.Request, http.ResponseWriter), and the specifics about the request (which cache, origin, etc) are passed with request using a context. This will make the end goal of importing a trickster library much easier to accomplish, as the exposed packages only need to set the context and then pass along the client Request and Response objects. I anticipate we can expose the packages for the library integration and have that ready to go in the next 4-6 weeks. I will follow up with you all under separate cover to coordinate when we are ready. Thanks for your patience!

[jranson]

@jacksontj if you'd like to hit me up via email, we'd love to put some time on the calendar to talk about this issue and get it ready for release.

[jranson]

All, as of today, internal is no more in master, and all packages are relocated to pkg for importation. The pre-release v1.1.0-beta should be usable in go.mod. We've love some feedback on how we can better structure the package layout to be more accessible and portable.

We will still provide more streamlined packages in v1.2 that are specifically meant to facilitate using Trickster as a router handler. I will keep this issue open until that release is cut. It would be great if anyone who plans to use any of this functionality could get in touch to help us drive our roadmap. Thanks!

[jranson]

closing as implemented