You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The original idea of this library was to detach the auto-generated underlying spec from the public interface to avoid unexpected breaking changes. That's why we created the structs you see in lib/langfuse_sdk/tracing.
We use those structs to create and update the Langfuse entities, but not when we fetch or list them. We should have a standardized way of consuming this library by either:
Finding a good way to map everything back to the public interface so the caller can trust to use the same "object" for every operation
Open question: Would a common interface between all operations be enough? What about additional metadata?
Open question: It's a little more work to maintain going forward since we are also maintaining custom code
Relax things by accepting plain maps as params and going full on the generated code (maybe getting rid of the Generated namespace in the process)
Open question: Exposing the auto-generated code might introduce breaking changes upon regeneration, are we ok with this?
Open questions: Tests can potentially break with auto-generated code, which is both good and bad. Good because if we have tests we can properly take action, bad because we are maintaining auto-generated code
PS.: The current implementation was heavily influenced by the TS SDK, so we keep taking some inspiration from them.
The text was updated successfully, but these errors were encountered:
The original idea of this library was to detach the auto-generated underlying spec from the public interface to avoid unexpected breaking changes. That's why we created the structs you see in
lib/langfuse_sdk/tracing
.We use those structs to create and update the Langfuse entities, but not when we fetch or list them. We should have a standardized way of consuming this library by either:
Finding a good way to map everything back to the public interface so the caller can trust to use the same "object" for every operation
Relax things by accepting plain maps as params and going full on the generated code (maybe getting rid of the
Generated
namespace in the process)PS.: The current implementation was heavily influenced by the TS SDK, so we keep taking some inspiration from them.
The text was updated successfully, but these errors were encountered: