Tussle is a mostly spec-compliant server implementation of the tus upload protocol.
Tussle is implemented as a collection of interchangeable modular components, allowing the developer to choose which services that they'd like to integrate with. At the center of a Tussle instance is the Tussle Core, which handles all communication between individual components.
Middleware components handle communication between clients and the Tussle instance.
- middleware-koa - mount a Tussle server as a Koa route handler.
- middleware-cloudflareworker - run Tussle server in a cloudflare worker.
Tracking state is tricky and often your options are limited by your deployment environment. Tussle state components are modeled after the Web Storage API
- state-memory - simple in-memory store, works anywhere.
- state-memory-ttl - in-memory store with TTL record expiration, works anywhere.
- state-namespace - wrapper to add transparent key prefixing for other stores.
- state-postgres - store upload state in a PostgreSQL database.
- state-cloudflareworkerkv - store upload state in Cloudflare Workers KV.
Uploaded files have to be stored somewhere, that's the purpose of the storage components.
- storage-b2 - Backblaze B2 cloud storage (supports large file upload)
- storage-pool - Pool multiple storages into a single logical pool with auto-failover.
- storage-r2 - Cloudflare R2 cloud storage (supports large file upload, ^0.4.0 adds parallel support)
- storage-s3 - AWS S3 compatible cloud storage (supports large file upload)
The request component a responsible for creating outbound HTTP requests and -- when possible/appropriate -- transparently proxy upload payloads, which is determined by the storage component.
- request-axios - Use Axios, suitable for node environments.
- request-cloudflareworker - Use Cloudflare Worker's Fetch() (for use with middleware-cloudflareworker).
If you find this library useful, please consider buying me a coffee as a way of showing your support!
