I’m investigating redwoodjs as an option for a new site I’m building. I love the premise and the technology, but I do have one question.
It looks like images can only be sourced from the local filesystem (please correct me if I’m wrong). I’m planning on building an app that allows admin users to upload images to a storage bucket which then schedules a build and deploys the site with the images sourced from that bucket.
Is this an option? Is there a better way to handle something like this?
@mpigsley This is definitely possible. I discussed (at a high-level) how you’d approach integration with other services using GraphQL in the thread below. Also, note the example of an article on GraphQL + S3, which I hope is of help!
@rob I know you used an image storage service for the RedwoodJS Example Blog. Do you have any other suggestions based on that experience?
In the example-blog app I integrate with Filestack to handle uploading and storage of images. If you’re on the JAMstack and need any kind of image uploading and storage you’re gonna have to go with a 3rd party service.
You could use your db given the need / type of app, but I 100% agree 3rd party is the way to go here.
Ahhh yeah forgot about BLOBBING them into the database! But I haven’t done that in more than a decade now! Plus with an actual file service you get all kinds of benefits like image optimization, resizing, etc, etc.
Ha! And did I just publicly regress to my early days of Drupal??? 
Ahh, okay that makes sense. I was already planning on using a 3rd party to store images. Looks like once the photo is uploaded the link is saved with the posts object back to the database, which is used to build the site.
I’m coming from Gatsby where sourcing images from a bucket is possible so that you can access the actual images through the graphql API and use gatsby-image to render them at different sizes.
@thedavid @rob Are you guys going to add some “helpers” for file-uploading because I saw on the roadmap. That you guys are working on,
I was thinking so maybe something similar for file-uploading? Like
Ah, got it. Gatsbyjs is definitely using a different design/process here (as well as having a much more mature ecosystem of plugins and features). And, most importantly, everything is pre-rendered at build time. RedwoodJS does not work the same way — it’s a dynamic, single page app connected to a database.
If you take a look at the Gatsby plugin, you’ll see the libraries being used for image processing. So if you want to roll your own and use Lambdas, these are some of the libraries you should look into:
Again, you’ll likely get more bang for your buck at this time by using a 3rd party service.
I know Auth is in progress. Image/File integration is definitely a good idea but not something we’ve discussed internally. Definitely more things like this to come just can’t say it’s near-term. But that’s why we’re so grateful for people like yourself jumping in and helping us get there faster!
@thedavid @rob @mojombo @peterp I like the idea though having an option like storing files locally in disk or similar to ruby in rails on a temporary directory.
Active_storage when you install it stores everything in local folder but in prod you can point the storage to services like s3 by changing some environment variables.
Redwood should do something similar and not rely on services early on. If you tell a user that you have to setup an amazon account and “then” you’re able to upload files. You have already lost someone, having things working locally is such satisfaction.
This should be possible to do because Redwood owns the entire stack both backend and frontend. Please have an option for a local file-upload or at very least have it in the roadmap? File-upload is second close to authentication and sending-emails when building web applications.
@guledali 100% agreed with you regarding both the need for a file store process/system and an approach like this. And, yes, definitely in the realm of possibility. But also not something that’s currently next-up on our roadmap at this time. But of course, we’d welcome community involvement to get there faster.
As a next step so this doesn’t get lost at the bottom of this topic, could you take this idea and create a new topic (including something like “Feature Request”) in the “Discussions” category?
For now our main use case for Redwood is deployment on the JAMstack, where everything is static and served over a CDN—there is no local filesystem for you to save your files to! I’m from a Ruby/Rails background so this took me a while to wrap my head around. It’s the same reason we have no background job processing built in—there’s no server to coordinate running those tasks. Things like uploading files and processing background jobs need to be handled by 3rd party services with an API. Our example-blog app uses https://filestack.com for image uploads. We’ve been recommending to people to use https://easycron.com for background or recurring job processing.
We may add features going forward that make Redwood more general purpose and add features that are common to a traditional server-based stack, but that isn’t our focus at this time.