Hacker News new | ask | show | jobs
by iluzone 4 days ago
tbh it's partly timing and partly layer. the origins of Trifle go back to 2015 and when I revived it in 2021 OTel was still quite new. it wasn't really an "instead of" decision back then.

but I would also say they sit at different layers. while OTel is a standard for emitting telemetry and data still ends up being stored in some backend (jaeger for traces, prometheus for metrics), Trifle keeps data in the database you already have. which was kinda my point from the beginning, you don't need a dedicated database/stack to do basic analytics. I believe the audiences differ a bit as well. OTel grew towards infra/observability, while Trifle mostly ends up tracking product/business counters. for now I don't see these as competition.

back in 2021 I also started working on Trifle::Traces. which is a really (really!) simple tracing library for Ruby to wrap your code in different tracing blocks - I really disliked the idea of having puts statements everywhere and then patching stuff together in raw logs. at the end you get nicely structured output that is then completely up to you how you store it. we ended up putting searchable metadata in MongoDB and actual data in S3. then we built a small internal UI around it. ngl it sounds awfully like OTel tracing and jaeger.

so yea, that's a fair question. if OTel had been where it is today back then, maybe I would have fewer repos. I believe we often get lost thinking that we need these big tools to do basic things. to me, this is the gap that Trifle fills.

1 comments

Thanks for the response - that makes a lot of sense. I wonder how hard it would be to make a compatibility layer in the future.