Complete newbie here - can I use Langfuse without LangChain?

Oh definitely, you can use Langfuse without LangChain! I was wondering the same thing last month. 😅

You just use their Python SDK directly. It's pretty much like you guessed, you manually wrap your OpenAI calls. You create a trace, then a span for the generation, and log the input/output. It adds a few lines but it's straightforward.

How does the mocking work in your tests? I'm just starting with pytest and was curious about that part.

Exactly right. The manual instrumentation you described is the way to go. For testing, you'll want to mock the Langfuse client to avoid sending data during unit tests and to assert that the correct observability calls were made. Here's a quick pytest example using pytest-mock:

```python
def test_my_openai_call(mocker):
mock_client = mocker.patch('my_module.langfuse_client')
# ... your test code that calls your instrumented function ...
assert mock_client.trace.called
```

The key is patching the specific Langfuse client instance your code uses. This keeps your tests fast and deterministic.

Mocking the client is definitely the right approach for unit tests, but I'd suggest one step further for a cleaner architecture. Instead of patching `my_module.langfuse_client` directly, consider injecting the Langfuse client as a dependency into your service layer. That way, you can pass a mocked instance in your tests and a real one in production, without any patching magic. It makes the observability coupling much more explicit.

Your pytest example is solid for a quick start. For integration tests where you might want to assert on the actual trace structure, you could use the Langfuse client's built-in memory exporter. It's a bit more work but lets you verify the shape of the data you're sending, not just that a call was made.

I really like the dependency injection idea. Passing the client in makes the whole thing feel way more deliberate.

I tried the memory exporter for an integration test last week. It is more work, but seeing the actual trace object with all nested spans was super useful for catching a bug where I was tagging things incorrectly. Wouldn't do it for every test, but for the core ones it's solid.

Yes, you can use Langfuse directly. Here's a basic trace with the OpenAI SDK.

```python
from langfuse import Langfuse
import openai

langfuse = Langfuse()

def call_openai(prompt):
trace = langfuse.trace(name="openai_call")
generation = trace.generation(
name="chat_completion",
input=prompt
)
response = openai.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": prompt}]
)
output_text = response.choices[0].message.content
generation.end(output=output_text)
return output_text
```

For pytest mocking, patch the `langfuse` instance you import and instantiate.

Great question! I was in the same boat last month, trying to avoid adding extra framework weight. The code snippet posted by user518 is spot on for the basic integration. Since you're using FastAPI, you'll probably want to instantiate the Langfuse client at startup and make it available to your route handlers, maybe via a dependency.

One thing I'd add: manually tracing nested logic can get verbose. I started creating small helper functions to wrap common patterns, like `trace_openai_chat()`, which keeps the main handler code cleaner. Also, don't forget to call `langfuse.flush()` on shutdown in your FastAPI event handler to make sure all traces are sent! For testing, I second the dependency injection pattern; it's a lifesaver with pytest fixtures.

Perfectly possible. The manual instrumentation pattern you're describing is exactly how we do it. For a FastAPI setup, I'd initialize the Langfuse client as a singleton during app startup and inject it into route dependencies.

Regarding testing, I've found the dependency injection method others mentioned to be the cleanest. You can wrap the client in a simple service class that your business logic depends on. In tests, you pass a mock. This avoids global state and makes the observability layer explicit.

One practical note: if you're making concurrent requests, be mindful that the default Langfuse client is synchronous. For high-throughput FastAPI apps, you might want to look into their async beta or batch your trace exports to avoid blocking.

Totally agree on the dependency injection approach. I've been using a similar pattern where the Langfuse client gets wrapped in a small "TracingService" class, then injected into FastAPI dependencies. Makes it super clean to swap for a no-op version in tests.

That async note is clutch. I ran into blocking issues in a high-volume endpoint last month. For anyone hitting this, the batch export is a decent workaround. You can set `flush_interval` when initializing the client to buffer and send traces every few seconds instead of instantly. Saved our response times.

The manual integration works, but everyone's glossing over the overhead. You're adding a tracing framework as deep dependency to your pure SDK calls, which is a non-trivial architectural trade-off, not just a few extra lines.

For testing, the dependency injection advice is correct, but be realistic: wrapping it in a service class adds yet another layer. Your "unit" tests for business logic now depend on the shape of your tracing service interface. It's cleaner, but it's more code to maintain.

Also, are you actually going to *use* all that trace data, or is this premature instrumentation because everyone's talking about observability? If you're a newbie, get the core app working first, then add the tracing sinkhole.

You can absolutely use Langfuse without LangChain, it's just manual instrumentation. Everyone here is already giving you the code.

But since you're big on testing, listen. That whole dependency injection pattern everyone's championing? It's fine, but you're about to wrap a vendor client in your own service class, define an interface for it, and mock it all out just to log some JSON. That's a non trivial amount of ceremony for a newbie.

Start simpler. Just initialize the client globally, and in your `conftest.py`, patch it out wholesale for your test suite. It's not "clean architecture", but it's two lines and you can actually start writing your app instead of building a tracing abstraction layer. You can always refactor to injection later when you know you actually need the traces.

Yep, you can definitely use it without LangChain! user518's snippet is exactly what you'd do. You're just manually wrapping your direct SDK calls.

Since you're big on pytest, the mocking advice here is a bit split. I lean towards the simpler global patch for a new project - gets you going fast. But if your service layer is already built with explicit dependencies, injecting a client or a small wrapper is the cleaner path long-term.

Just watch out for the sync client in a FastAPI app, like user575 mentioned. Setting a `flush_interval` can help avoid blocking.

The sync point about `flush_interval` is critical for anyone using a synchronous client in an async framework. A common oversight is not realizing that even with batching, the actual HTTP call to the Langfuse backend on flush is still synchronous and blocking. For a high-throughput service, you might need to push the flushing to a background thread entirely.

Your suggestion of a global patch in tests is pragmatic for a newbie, but I'd add one nuance: patch the specific instance your module imports, not the class. If you patch `langfuse.Langfuse` globally, you might inadvertently affect other tests or modules. Something like `@patch('your_module.langfuse_client')` is more precise.

That's a really sharp point about the flush still being a blocking HTTP call even with batching. It's easy to mentally file it under "solved" once you set the interval and move on.

Your nuance on patching is dead on, and it's saved me headaches before. Patching the module-level instance is much safer. I've seen tests start failing mysteriously because someone imported the class directly somewhere else and the mock didn't reach it. I usually end up with a pattern like `@patch('app.observability.client')` where `client` is the singleton instance I've already created at startup. It feels a bit less "magic" than patching a constructor.

The background thread idea for high volume is interesting, though it adds more moving parts. Have you tried that pattern, or does it just become easier to wait for their official async client?

I think user441's advice about starting with a global patch in your `conftest.py` is pragmatic, but I'd take it a step further given your stack. Since you're already using Pydantic for settings, you can make the Langfuse client initialization conditional based on an environment variable like `LANGFUSE_ENABLED`. In your tests, you set it to `False` and skip the initialization entirely, avoiding mocks for the majority of your unit tests.

For the actual instrumentation, here's a compact pattern I've used that fits a FastAPI dependency:

```python
# In a dependencies module
def get_tracer(request: Request):
# Inject the singleton client attached to the app state
client = request.app.state.langfuse_client
if client is None:
yield None
return
# Start a trace for this request
trace = client.trace(name=request.url.path)
yield trace
trace.update(output={"status_code": request.state.response_status})
```

Then in your route, you wrap the direct OpenAI call within a span from that trace. It keeps the manual instrumentation contained to about three extra lines per logical operation. The sync client blocking is real, but for a new project, setting `flush_interval=5` is usually sufficient until you have the volume to justify the complexity of a background thread.