First of all, I already read all related posts like this and this.
I saw in @tatiang post the solution with some blocks written by @japa6225a, but I really don’t understand the approach with the “eager” access, because there isn’t any demo project available in the thread with the solution.
I’m a pretty new in Thunkable, currently working with the StP version. and trying to develop a social network project and my needs are:
Upload photos to Cloudinary or any alternative platform, storing the files in different folders by userID, and according the category, saving in Firebase the photo URL. For example:
userID/profile/photo1.png
userID/album1/photo2.png
userID/album1/photo3.png
userID/album2/photo4.png
Add watermarks in the photos, and if possible, uploading reduced versions of photos to minimize the time to upload / download the photos.
Delete older versions of the stored photos (profile photos and others that can be deleted/updated by the user, so I don’t need any automatic “garbage collection”).
So, I want to ask if there is any tutorial or Demo Project for “dummies” on how to implement the Cloudinary API Access or an alternative service that performs the actions I described above.
I read that unfortunately that Thunkable’s Staff has no plans to improve the MediaDB functions, so the only solution to have this features is to use an API access to Cloudinary or use other photos repository via API.
Any tip, project example, or other idea to help here?
Unfortunately (or not), my project will need massive access to cloud images (and this is expensive, so any space saving is VERY welcome to reduce time to load and also disk space).
Hey @paulovaz72. Great idea and queries here. I don’t think we have any examples so in depth as you’re asking.
I think that using (for now) the Cloudinary API as the “first stop” and then setting up a backend workflow. Sounds like you need a backend that can do this heavy lifting. I’d recommend Xano for those needs if you aren’t familiar with setting up a backend and traditional coding. Supabase may be a solid alternative for many users too.
What you are asking could be done on a mobile device, maybe, but it would not be super efficient or a best practice, especially if the app goes . Most apps would. complete the bulk of these actions on the apps backend in the cloud.
I would either host my media with my backend, or ALSO use an S3/Firebase server to dispatch my media files and keep them. nicely organized. S3 is nice as you can set up image optimization. but it’s a heavy set up for most #noCoders.
Sign up via this link. to receive 10% off your monthly bill (or just use free! )
In fact, I have no fear to learn and produce code. But for me, due the lack of time to finish my project, I have no time to conduct a deep research, learn & explore an entire new class of things. That’s why I asked for a minimum functional Cloudnary API usage example, that allows me to adapt / implement what I need.
The problem of choose Cloudinary for now and later move to other platform, is the need to move all data from there, keeping the app live and avoid data losses. The better approach for me is to find at least the definitive place to leave the images.
The minimum functionality I need for now is:
Create & save images in distinct folders (if in cloudnary that’s ok, but any other will be welcome)
Delete older images wherever it be.
Later, if possible, reducing image sizes (via backend if necessary), and add watermarks will be welcome… but to launch my app this can be done later.
Do you think I can do it using Cloudnary API or better try Supabase instead?
P.S. Looks Supabase is cheaper than Cloudnary, right?
As far as I understand the challenges of using an API to store images (no matter witch platform you choose) goes through:
Authentication Function (called in all operations)
Folder Creation and Deletion Functions
Image Upload Function
Image Deletion Function
Image Resizing Function
Add watermark function
So on the screens that are necessary any manipulation of images will have to contain these functions/blocks.
I believe isn’t possible to do make it work using pure Thunkable WebAPI Blocks, right? Some coding in javascript, or another language will be required?
I really don’t know how to start… If I receive some guidance I can try! Anyone out there willing to venture with me to do this (5 & 6 can be done later)?
Well, they are 2 different things. Supabase is a Firebase alternative but I believe you can also host media.
Cloudinary is a quality “public” media server but AFAIK at this time, setting up 'user specific" authentication is not possible.
The delete function may come later this year, but it’s not a top priority at this time as there are workarounds available for that.
I am wondering why they need to be in specific folders. Would UUID’s not offer enough protection? I know Firebase and S3 allow for easy and programatic folder destinations for your media. Cloudinary too IF you were using the standard API (I believe).
It’s a bit silly, but, you may look into uploading to cloudinary, triggering a cloud function to then take the uploaded image, throw it into a folder, delete the original image keeping the newly moved file, resize and add watermark.
You might be able to do most of this via Integromat/Make/Zapier/n8n and skip adding these actions to a backend.
The idea behind of separating images into folders would be to facilitate batch deletion. Because my project will store several images for each user. So I thought of something like this:
So when deleting a user or album, it would be enough to delete the main folder! Otherwise I will have to create loops to exclude each image (which is not impossible, but it makes the process slower).
But yeah, if I can at least come up with an easy way to effortlessly delete the images even if they’re in a single folder, that would be a start.
I’ll take a look at your example and see if I can make it work in my project.
. Most apps would. complete the bulk of these actions on the apps backend in the cloud.