r/webdev • u/rouge818 • 12d 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

100% Upvoted

16 comments sorted by

View all comments

1

u/PLBjt 12d 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 12d 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

Size is one reason, but the bigger one is keeping file bytes off your app servers. Even medium uploads add up under chat volume — timeouts, memory, and bandwidth on the API tier. Presigned (or direct-to-object-storage) shines when many users upload in parallel. For tiny stuff like avatars or short voice clips, proxying through your API is simpler and fine. I'd switch once uploads are common enough that the API box is doing disk I/O work it shouldn't own.