Framework Integration
Drop chunk-engine into any web handler — the same three-step recipe across Python, JavaScript, and Rust frameworks.
chunk-engine is a plain library call with no services, no global state, and no warm-up. That makes web integration the same everywhere, in every language:
- Read the uploaded bytes from the request.
- Pass them with a
filenameso the engine can route by extension (a namedBlob/Filesupplies its own name). - Return the chunks — or stream them as they're produced.
Pick a mode per use case
Handlers below use the default mode for brevity. In practice pass
mode="semantic" for LLM/RAG ingestion or mode="section" for search
indexing — see Chunking Modes.
By language
Python
FastAPI, Flask, Django, Litestar, aiohttp, Celery.
JavaScript
Express, Fastify, Hono, Next.js, NestJS, SvelteKit — Node, Bun, Deno.
Rust
Axum, Actix Web, Rocket, Warp.
Streaming responses
All three language pages now carry an NDJSON streaming handler:
| Language | Handler |
|---|---|
| Python | FastAPI StreamingResponse |
| JavaScript | Next.js ReadableStream and Express |
| Rust | Axum NDJSON body |
“Streaming” doesn't mean bounded memory
Forwarding chunks as NDJSON always makes the response incrementally
consumable, but only three formats (PDF, spreadsheets, CSV) parse
incrementally, and only in native Rust and Python. JavaScript's streamChunks
computes the whole array before it yields the first item. Read
Streaming before you rely on a handler to survive a file
that getChunks could not.
Errors
Each page's handlers assume the happy path; map failures onto status codes
explicitly. The Rust page
has a complete ChunkError → IntoResponse mapping (415 / 400 / 422 / 500) and
the JavaScript page has the
same table for ChunkError.kind. The full contract is in
Error Handling.