This is just an idea; I haven't thought about how it will work or what the API will look like yet.
As told in the documentation:
For files larger than 10MB, it is recommended to use a dedicated solution for performance and reliability.
From my understanding, it is not recommended for "big" files, because under the hood, it encodes/decodes in base64 (haven't tested it)?
Even, file upload is much more than only 1 API request, it's not the same thing as basic JSON api call. Performance and resumable file uploads are crucial + good UX client side to show how much kb has been uploaded and much need to be uploaded still etc.
tus - Open Protocol for Resumable File Uploads makes file uploads more reliable and performant for any size of files.
While, we can already use @tus/server in combination with oRPC, I believe there might be a better way that keep type-safety, zod goodness and simplicity while preserving tus goodness too.
Would be great to define oRPC route as "tus route" and then call them with the RPCClient like normal routes with more features like tus-js-client, for example:
const handleUpload = async (file: File): Promise<void> => {
const upload = new tus.Upload(file, {
retryDelays: [0, 1_000, 3_000, 5_000],
metadata: {
filename: file.name,
mimetype: file.type
},
onError: (error) => {
console.error(error)
},
onProgress: (bytesUploaded, bytesTotal) =>{
const percentage = (bytesUploaded / bytesTotal * 100).toFixed(2)
console.log(bytesUploaded, bytesTotal, percentage + "%")
},
onSuccess: () => {
console.log("Download %s from %s", upload.file.name, upload.url)
}
})
const [previousUpload] = await upload.findPreviousUploads()
if (previousUpload != null) {
upload.resumeFromPreviousUpload(previousUpload)
}
upload.start()
}The good thing, is that we can have a onProgress and regularly tell the user, how much bytes uploaded, how much still needed, percentage.
Also we have out of the box, resumability so for example, if the internet connection of the user is bad, and is interrupted, they can try to upload again the file, without the need of uploading the file from scratch, especially useful for big files, or really bad connection, like mobile network.
We could have a way to do it, with oRPC, the same type-safety, and APIs to define middleware.
This is just an idea; I haven't thought about how it will work or what the API will look like yet.
As told in the documentation:
From my understanding, it is not recommended for "big" files, because under the hood, it encodes/decodes in base64 (haven't tested it)?
Even, file upload is much more than only 1 API request, it's not the same thing as basic JSON api call. Performance and resumable file uploads are crucial + good UX client side to show how much kb has been uploaded and much need to be uploaded still etc.
tus - Open Protocol for Resumable File Uploads makes file uploads more reliable and performant for any size of files.
While, we can already use @tus/server in combination with oRPC, I believe there might be a better way that keep type-safety, zod goodness and simplicity while preserving tus goodness too.
Would be great to define oRPC route as "tus route" and then call them with the RPCClient like normal routes with more features like tus-js-client, for example:
The good thing, is that we can have a
onProgressand regularly tell the user, how much bytes uploaded, how much still needed, percentage.Also we have out of the box, resumability so for example, if the internet connection of the user is bad, and is interrupted, they can try to upload again the file, without the need of uploading the file from scratch, especially useful for big files, or really bad connection, like mobile network.
We could have a way to do it, with oRPC, the same type-safety, and APIs to define middleware.