Using JSZip with Zod and tRPC
I am making a uploadRouter for my website where a user can upload 5-10 images. I want to be able to zip those image and then upload it to a r2 endpoint.
I never really worked with zipping and image schemas in Zod and tRPC so im not sure on what to do.
Here is what I have so far
This is the error im getting
59 Replies
try this
you're using it wrong
hmm
my schema is most def wrong
also, maybe this should be a better zod schema
yep
you're using 1 object
it should be an array
hmm
didn't saw that
its not making any sense to me
what u sent
nor does mine either
cause it was just ripped from a blog
and even the blog didnt make sense
basically what i need is to get the images that the user uploaded
so for example i select 5 to 10 images on the website
click upload
then it goes to this trpc endpoint
and zips them
ya know....... you can just.... use a nextjs raw http endpoint to handle file uploads
hmm that is true
I've always used those for doing file stuff
as the raw request object is available
ok im gonna do that
is there a guide or documentation u can link me to?
hold up I have a code snippet I wrote a few days ago
hmm
this is what I wrote, it's saving one image a time though
you'll have to read the formidable docs to handle first parsing multiple files, then saving them. Or hold up a minute
wait don't use that it'll get messier that way
alr
i just want a way to get the images
and check if they are actually images
and check if they are smaller than 50 mb thats it
I have something along those lines, let me remember where I saw it
*proompting some code into existance here
here
an example of using multer to handle files
I used this once before so I remember it works cleanly with files.
mind you the snippet above is from ChatGPT so use at your own discretion
are u using chatgpt lol
haha just did as an example, I don't have a code snippet for multer
whats multer?
GitHub
GitHub - expressjs/multer: Node.js middleware for handling `multipa...
Node.js middleware for handling
multipart/form-data
. - GitHub - expressjs/multer: Node.js middleware for handling multipart/form-data
.also i want this to be protected
thats why trpc made sense
put in some pre-checks
like in the above code snippet, before the
try
block, put in your
or whatever session validation you havequick update
im fully committed to using trpc
and to making it work
so currently i have
š There's a way, good luck
i just did it š
GGs, did you inject the http req body into the context? or did you do it in another way?
first i made my own type
mmhm
then made a function to get the base64 (client side)
okay
and
then in the file input i got
pretty much we just convert it to image type
I see
then the upload.ts router
is almost the same
so you're abusing a base64 string of an image to uploading it normally to trpc
^
there it is
nice workaround haha, I might have thought of that on my 2nd-3rd try if I was as adamant as you in making trpc work with it
thats all the code
i also had to disable the
1mb limit
u should probably increase it
someone did warn me that there was a 5mb limit in prod so i will try that now
which is not a good thing to do generally (payload bombing to slow the server down/^ cost)
hmm
as long as you keep a limit, it's probably alright
but this is with images
so i think its fine
there is already WAFs on serverless
i have the limit set in zod to 50mb per image
it is
so it is fine
hmm but.....
are your users going to be uploading 8k raw images?
even those don't touch 50mb
nah
your right
you should reduce it to around 10mb per image
i should prolly leave it around 10mb
yep
š well may not be the best solution, but definitely a good one ( I did that too the other day with a custom captcha service I made in go )
yep i hope there is a better solution out there with trpc
but this is what i came up with
and i couldnt find any online resources
there is, it's just that it's focused on web standard file uploading, where as you're seeing it with the eye of t3 stack's abstracted layer; which I'm sure does not have any references online
which is why I recommended a raw next http endpoint in the first place
in the end i think it would be the same
it actually might be a bit slower
how so
but yeah if it's serverless, you're not measuring the server resource costs
costs = CPU/RAM usage, which is negligible for a small userbase, but noticable on the 10k+ user base
awe whatever our product has like a 10000% margin
eh trpc setting up it's context to process and all, plus you using b64 to encode and decode 5 images, the cpu does it's work
encoding/decoding comes with a cost, just that it's not noticable on the smaller scale.
The reason for there being
url-form-encoded
is to optimize image transfers over http
image= file transfers
anyhow that's me being over-conscious of the costs
š well whatever fits your need is a good solutionhope someone stumbles upon this and finds it useful
and if they have a better solution they should tag me
maybe I'll do it IF I ever decide to handle file uploads in this interesting manner
I know the better solution...... just that I'm a bit too sleepy to spin up a fresh trpc server to provide it
The one I mentioned before: updating your ctx||input variable to include the incoming files from the request into the context, which can then be accessed like
ctx.prisma
or whatever
though in the case of the ctx
method, you'll have to do zod validation yourself š¤ which I like 3-5 more LOC