RFC: The future of this library

[oliverb123]

👋 Hi folks, I'm Olly. I work on the error tracking team, and have taken ownership of this library, for the foreseeable future. That means you should feel free to ping me on PR's or issues if they've been open for a while and haven't gotten attention.

I'm opening this issue to ask, if you use posthog-rs, what would you like to see added or changed? What do you feel is missing? What pain points around using it do you encounter? If you don't use it, and do use rust, what's stopping you from adopting it?

I'll edit this comment with common themes in replies, and try to respond to any questions or feedback.

On my side, my priorities are roughly as follows:

• Maintain backwards compatibility where possible. That means no changing existing interfaces, but it also means e.g. not exposing the "guts" of the library where possible (for example, rather than making all fields of the Event type pub, if something needs to be user settable, expose a setter).
• Keep it simple and flexible - I've seen proposals for adopting queue-based or actor-based systems, or generally extending what I'd call the "architecture" of the library significantly. I think there are pro's and cons here (event batching "for free", but the overall library becomes more complex, particularly around e.g. error handling), and am interested in hearing opinions.
• Extend support to other posthog features - integrating with features like user identification, feature flags, experiments or error tracking.
• Maintain parity between sync and async interfaces
• Keep the dependency list low, if possible

That priority list is mostly out of an awareness that my bandwidth is fairly limited, and that means I'd rather this library "cover" less, but be more stable/bulletproof.

[omarabid]

Hey @oliverb123 ! I am working with a Wasm back-end and wonder if part of PostHog plans is to support wasm as a target for this library.

[domenkozar]

Would love to see feature flags implemented!

[jkelleyrtp]

A tracing layer would be cool. We needed to build / have built an integration that lets us regular tracing statements.

tracing::trace!(src=posthog, field1 = "one", two = "two") 

I noticed that claude-code uses statsig which seems to handle batching and integrations for local-first tools like CLIs.

[niusia-ua]

I'm going to try PostHog for my Tauri application.
In Tauri, it is common that everything is done on the Rust rather than web. So many libraries proxy their API request through the Tauri backend. I'm planning to utilize this approach to collect metrics both from Rust and web.

Here are some points I see would make this SDK better:

1. Make public structures (e.g., Event) deserializable so that it is possible to pass them from the fronted to the backend.
2. Support all APIs so that it is possible to proxy every supported event type.

I think it will make the Rust SDK more useful for other types of Rust applications (e.g., CLIs, TUIs, pure Rust web apps, etc.).

[alanjds]

Error tracking would be very useful.

May be used easier via an impl From<anyhow::Error>, but that is just a 2nd wish.

[yawn]

While general feature parity would be great to have I'd love feature / experiments support.

[petersamokhin]

Error tracking would be really nice to have 🙏

[jkelleyrtp]

We implemented stack trace -> posthog event here, in case anyone needs code to work from:

https://github.com/DioxusLabs/dioxus/blob/a4785896f5327448152d438dc2c5bb5fb051aa40/packages/cli/src/logging.rs#L951-L1034

The full event type is here, but it might be specific to our usage of posthog:

https://github.com/DioxusLabs/dioxus/blob/a4785896f5327448152d438dc2c5bb5fb051aa40/packages/cli-telemetry/src/lib.rs#L61-L100

[yawn]

I just noticed that you export (in the official documentation) your schema types as rust structs (e.g. exception and stack frames). Which is a bit weird given the current feature state of the client.

What I really wanted to task: how much bandwidth for community PR integration is available for this repo? I would love to use most of the features of Posthog and not split my analytics over Posthog, Sigstat, Sentry etc. pp - contributing features might not be too hard but that only makes sense if there is some official resources attached to this repo.

[yawn]

We implemented stack trace -> posthog event here, in case anyone needs code to work from:

Awesome! Quick question: you have way more data in your types then the Rust references from above. Are these extra values useable / visible in Posthog? Did you know about this "cymbal" repo and did decide not to use those types for a specific reason or did you just happen to land on the implementation by following the "looks-like-sentry" guidance from the documentation?