🌊 Real-time Next.js Streaming Client for RAGFlow

[RajeshShrirao]

Hey team 👋

I've been diving deep into RAGFlow's codebase this week and noticed something interesting — wanted to open a discussion before writing any code.

---

🔍 What I Found

I noticed the 2026 roadmap mentions WebSocket APIs as an upcoming feature. But while exploring the codebase, I discovered RAGFlow already supports SSE-based streaming via the REST API — there's just no Next.js frontend to consume it.

Looking at api/apps/conversation_app.py, the streaming endpoint is already solid:

async def stream():
    async for ans in async_chat(dia, msg, True, **req):
        yield "data:" + json.dumps({"code": 0, "data": ans}) + "\n\n"

The infrastructure is there. The frontend layer isn't.

---

💡 What I'm Proposing

A standalone Next.js 14 application (App Router) that:

• ⚡ Connects to RAGFlow's existing SSE streaming API
• 🔤 Streams answers token-by-token in real-time
• 📎 Renders citations inline as they arrive

---

🛠 Stack

Tech	Why
Next.js 14 App Router	Modern React with server-first patterns
Native SSE (fetch + ReadableStream)	RAGFlow already uses SSE — no WebSocket needed
TypeScript	Full type safety across the API boundary
Tailwind + shadcn/ui	Clean UI, easy to customize

---

❓ Questions for the Team

Before I build, I wanted to get your thoughts:

1. Direction — Is a community Next.js client something you'd want in the ecosystem?
2. Showcase — Would you be open to featuring this in the RAGFlow community showcase once it's done?
3. Tech choices — Any concerns with the stack, or things I should align differently?

---

✅ Quick Verification

Just want to make sure I'm not duplicating work:

• Is there already a Next.js client I might have missed?
• Are there any planned changes to the SSE streaming format I should design around?

---

Thanks for the great project — the codebase is really clean and well-structured, made it easy to explore. Looking forward to contributing 🙏

— Rajesh

[cike8899]

async def stream():
    async for ans in async_chat(dia, msg, True, **req):
        yield "data:" + json.dumps({"code": 0, "data": ans}) + "\n\n"

This code is intended for use with SSE. What is the purpose of using Next.js? What pain points does it solve?

[RajeshShrirao]

Great question. Here’s the reasoning.

Why Next.js?

1. Ecosystem and familiarity

Next.js is one of the most commonly used React frameworks right now. Many frontend developers already work with it, so if someone is building a RAG-powered app, there's a good chance their frontend stack is already Next.js.

2. Vercel workflows

A lot of teams deploy their frontend through Vercel. Using Next.js fits naturally into that setup, especially with things like API routes and edge functions.

3. Server Components

The App Router pattern makes it easy to combine server-side calls with client-side interactivity. That works well for a chat interface where you need streaming responses and dynamic updates.

---

What problems would this actually solve?

Pain Point	How a Next.js example helps
"How do I connect my Next.js app to RAGFlow?"	A working example reduces setup work
"The API streams responses — how do I render that?"	A simple SSE hook developers can reuse
"Citations appear during streaming — how should they be displayed?"	A reference component for rendering citations
"How should authentication with RAGFlow work?"	A basic pattern developers can follow

---

The honest goal

You're right that any frontend framework could work. The main goal here isn’t to push Next.js specifically. It’s to:

• Lower the barrier for developers getting started
• Provide a simple reference implementation
• Show how streaming responses from RAGFlow can be integrated into a modern frontend

If another framework makes more sense (Vue, Svelte, plain React, etc.), I’m open to that too. The main thing I want to demonstrate is the SSE streaming integration pattern rather than the framework itself.

Happy to adjust if you think another direction would be more useful.

[aniruddhaadak80]

Your observation about SSE already being available is accurate, and a clean Next.js client would genuinely fill the gap between existing infrastructure and usable frontend code. The stack choices are solid, and a standalone client feels like a practical way to prove demand before anything official lands.

Before full development, clarifying with the team whether they want this in the official ecosystem would save effort. If it stays community-maintained, that is still valuable, but it changes how you should structure the repository and documentation. Have you checked whether any breaking changes are planned for the SSE format?

[RajeshShrirao]

Thanks for the feedback!

To answer your questions:

On breaking changes
for now , I checked the repo and couldn't find any upcoming SSE changes. But I'll double-check the roadmap/discussions before I build. If you have insider knowledge on planned changes, would love to know so I don't build something that breaks next quarter.

On official vs community
Fair point. My thinking:

If RAGFlow wants it → Structure it for potential inclusion (cleaner, documented, follows repo patterns)
If community-only → More flexibility, faster iterations, less coordination overhead
I'm happy either way , just need a signal from the team. Should I open a separate issue to formally ask, or is this discussion thread enough?

Repo structure
If it stays community-maintained, I'd likely keep it as a separate repo (ragflow-nextjs-client or similar) with clear docs pointing back to the main RAGFlow repo. That keeps the main repo clean while still making it easy to find.

Let me know which direction makes sense