starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-25 13:55:59 +03:00

[GH-ISSUE #2023] File handling between UI and Server #581

New issue

Open

opened 2026-02-26 18:47:40 +03:00 by kerem · 1 comment

kerem commented

2026-02-26 18:47:40 +03:00

Owner

Originally created by @el3ctrician on GitHub (Sep 10, 2025).
Original GitHub issue: https://github.com/documenso/documenso/issues/2023

Describe the improvement you are suggesting in detail

Hello Everyone. I am not a developer by anymean and maybe i am missing bigger concepts here but i wanted to share my thoughts with you.
I have been trying to deploy the documenso on a custom setup but i figured that i need the S3 bucket to be accessibile from the browser as well. That got me thinking why it's not the case that when opening a document for edit that the server will get the data from the buket and encode it as base64 then send it to the UI instead of relying on the browser to access the data from a presigned URL. The same is true when uploading from APIs (I see it's planned in APIv2 but not yet implemented) my questions are:

wouldn't it be an improvement if only the bakcend handled everything related to the docs leaving the frontend with always the same way of displaying files regardless on which storage medium is used?
in the same way wouldn't it be better if the create documents/templates api accepts the files encoded and let the server handle the upload part either to "db" or a bucket?

IMHO (which comes from a non expert eye) i think this all could be achived by abstracting the file reppresentation in the APIs / Frontend and Backend so that APIs and UI always get/set a Json from/to the server without having to "know" which storage medium is used

Additional Information & Alternatives (optional)

No response

Do you want to work on this improvement?

Please check the boxes that apply to this improvement suggestion.

I have searched the existing issues and improvement suggestions to avoid duplication.
I have provided a clear description of the improvement being suggested.
I have explained the rationale behind this improvement.
I have included any relevant technical details or design suggestions.
I understand that this is a suggestion and that there is no guarantee of implementation.

Originally created by @el3ctrician on GitHub (Sep 10, 2025). Original GitHub issue: https://github.com/documenso/documenso/issues/2023 ### Describe the improvement you are suggesting in detail Hello Everyone. I am not a developer by anymean and maybe i am missing bigger concepts here but i wanted to share my thoughts with you. I have been trying to deploy the documenso on a custom setup but i figured that i need the S3 bucket to be accessibile from the browser as well. That got me thinking why it's not the case that when opening a document for edit that the server will get the data from the buket and encode it as base64 then send it to the UI instead of relying on the browser to access the data from a presigned URL. The same is true when uploading from APIs (I see it's planned in APIv2 but not yet implemented) my questions are: 1. wouldn't it be an improvement if only the bakcend handled everything related to the docs leaving the frontend with always the same way of displaying files regardless on which storage medium is used? 2. in the same way wouldn't it be better if the create documents/templates api accepts the files encoded and let the server handle the upload part either to "db" or a bucket? IMHO (which comes from a non expert eye) i think this all could be achived by abstracting the file reppresentation in the APIs / Frontend and Backend so that APIs and UI always get/set a Json from/to the server without having to "know" which storage medium is used ### Additional Information & Alternatives (optional) _No response_ ### Do you want to work on this improvement? No ### Please check the boxes that apply to this improvement suggestion. - [x] I have searched the existing issues and improvement suggestions to avoid duplication. - [x] I have provided a clear description of the improvement being suggested. - [x] I have explained the rationale behind this improvement. - [ ] I have included any relevant technical details or design suggestions. - [x] I understand that this is a suggestion and that there is no guarantee of implementation.

kerem added the

Stale

status: triage

labels

2026-02-26 18:47:40 +03:00

kerem commented

2026-02-26 18:47:40 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 10, 2025):

Thank you for opening your first issue and for being a part of the open signing revolution!

One of our team members will review it and get back to you as soon as it possible 💚

Meanwhile, please feel free to hop into our community in Discord

@github-actions[bot] commented on GitHub (Sep 10, 2025): Thank you for opening your first issue and for being a part of the open signing revolution! <br /> One of our team members will review it and get back to you as soon as it possible 💚 <br /> Meanwhile, please feel free to hop into our community in [Discord](https://documen.so/discord)

kerem referenced this issue

2026-02-26 19:31:39 +03:00

[PR #581] [CLOSED] feat: migrated to signpdf from node-signpdf #1060

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/documenso#581

No description provided.

Rows
Columns