Does Spatie Media Library work with Vapor over 4.5mb?
According to https://docs.vapor.build/resources/storage.html in order to upload files greater than 4.5MB, you need to send files first to s3 directly. I can't figure out if the Spatie Media Library plugin will do this automatically, of I'll have to make a bunch of modifications.
Storage | Laravel Vapor
Laravel at Infinite Scale
Solution:Jump to solution
Turns out that somehwere along the line, whether that's in the Filament FileUpload or somewhere else, it does indeed send it to s3 directly, so it works with Vapor out of the box. I had to make sure that I had a few variables properly set in the .env file, but it works nicely:
```
ENABLE_MEDIA_LIBRARY_VAPOR_UPLOADS=true
FILAMENT_FILESYSTEM_DISK=s3...
13 Replies
I'm not using Vapor, but I have a production app in which I have the Spatie Media Library "disk" set to
's3' and I'm pretty sure the upload is going directly to S3.
However, you might have to experiment with disabling image-preview mode in the uploader.
awcodes may have more specific insight on this one. His curator plugin might do as you need, instead of the Spatie module.I think the trick here is figuring out exactly where the upload limit is getting set or falling down. I think it’s weird that vapor requires uploading an image first to see if it passes validation, but I understand that you have to explicitly define where the upload limit is getting defined. It could potentially be the livewire config, the php ini, the Aws config or even the vapor config. Unfortunately, this is the shitty side of serverless and there’s just no right or wrong answer in this particular use case. Since the file has to go through so many hands.
Personally, though I don’t use Aws so I very well could be missing something.
Agreed.
I was wondering if maybe Vapor relies on AWS to give metadata about the file, and uses "that" for validation, instead of Vapor parsing the file directly .... all about keeping the serverless instance small and fast, delegating as much as possible to other agents.
Yea. Personally, at that point, I would forgo Aws completely and defer to an actually asset manager like cloudinary or imgix which provide a lot more functionality out of the box other than just a source provider / cdn.
We just live in a different tech world now where it hard to over what we are used to when in comes to asset management and that why Curator doesn’t support Spatie’s package. It’s a totally different mindset to asset management. Not that either is right or wrong. But physical files at different sizes these days is completely pointless outside of focal points.
It has something to do with the serverless nature of vapor.
This is a direct quote from the vapor docs:
Then it sounds likes there’s a hard limit on vapor and nothing you can do about it.
Seems odd to me that there would be a hard limit on it though.
The solution, as the vapor docs say, is to stream directly to S3 through js, and then use that js response to send the backend the completed file location.
So I was wondering if that's what might be happening in the backend, but can't figure out if it is or not.
Right. I'm not sure if Filepond can do that directly or not (with the right configuration). Maybe it does automatically.
I think this would require livewire 3s stream functionality but not sure filepond even has a direct integration for streamed uploads.
Also, why I like to manage everything on my own server. Lol.
😄
Laravel News shared this link in their email blast yesterday: https://crnkovic.me/uploading-files-directly-from-client-to-s3
It's not Filament-specific but it is related to the concept we've been discussing.
Uploading files directly from client to S3 without files ever touch...
If your web application allows users to upload files, there are a few things to consider and be aware of before deploying file uploads to production...
Solution
Turns out that somehwere along the line, whether that's in the Filament FileUpload or somewhere else, it does indeed send it to s3 directly, so it works with Vapor out of the box. I had to make sure that I had a few variables properly set in the .env file, but it works nicely:
Super! Yes, now that you mention that configuration I do recall having seen that at one point. Just completely forgot about it until now. 😄