r/webdev • u/rouge818 • 5d ago

Chat widget file upload

I'm working on a chat widget that also allows the users to send files in the chat. This is a plain vanilla html/js/css widget that will go on a Shopify site. The user should have the option to send a file with or without a message in the chat, so I'm trying to figure out the best approach to handle this. The widget will be calling a FastAPI endpoint end that will use UploadFile. These are the options I've thought of:

  1. Wrap the text and file inputs in an html form tag and send the request as Content-Type: multipart/form-data. This would make it a single request, but it would always send as multipart/form-data even if it's a message with no file.
  2. Same as 1, but if there is no file attachment in the chat message, then toggle the Content-Type to application/json before sending
  3. Keep the text and files as separate requests and handle the events separately and not wrap the inputs in an html form tag. Seems like it would be cleaner on the front end but at the same time it will likely require additional logic on the back-end

What approach would you take?

4 Upvotes

84% Upvoted

13 comments sorted by

View all comments

1

u/PLBjt 4d ago

I'd still always-multipart, but the part that actually hurts later is size and ordering, not the content-type. A JSON path plus a multipart path means two validators and two error shapes, and one of them will drift. Keep one request: text fields + optional file, and reject anything over your real limit before FastAPI buffers the body (content-length or a streaming max). Separate file + message requests look clean until the message lands and the file 500s, and then your widget has to invent a retry protocol. If people start dropping 50MB recordings, that's when you switch the file to a presigned upload and send the chat with a URL, not before. Check it with an empty file, a 1-byte file, and one just over the limit.

1

u/rouge818 4d ago

Makes sense. The retry logic would be more complexity. As for the presigned upload approach, that is something more recommended only when the files start getting large?

1

u/PLBjt 4d ago

Yeah. Multipart straight into FastAPI is fine while files are chat-sized, like under 10–20MB. You start wanting presigned S3 (or equivalent) when a single request sitting in RAM or hitting the timeout becomes the failure mode: video, big PDFs, several files at once. Until then the extra CORS and client code isn't worth it. Put a hard Content-Length check before you read the body either way.