Why Use Cloudinary to Host Images in the Cloud?

Let's go to our profile page in our application and examine the listing we just recently created. If we see within our network logs the data returned from our query for this particular user or from my user, we can see that the listing we've hosted uses the base64 encoded version of the image file as the image data. And if we open our listings collection in MongoDB Atlas and look for this certain listing we just saw, we'll see the same base64 encoded string in the image field. This shouldn't be surprising because this is what we told our server to do. We encoded an image file in the client, sent the encoded image as a string to our server to be stored in our database. Thus, when we request listing data, whether it's in the listings page, the listing page or the user page, the listing image field will return a base64 encoded string directly from our database. Although there's nothing wrong with this method of storing images, it isn't ideal and among different reasons there's two inherent flaws with it. First of all, images can take a lot of storage space in our database. Image files by nature are large. In addition, when we're base64 encoding the binary image files into a string, it actually increases the size by about 33%. In fact, our image field would take up more space than the rest of the fields of a single listing document combined. The second reason is, if all our listings in our app had base64 images, transmitting and querying all that image data from our GraphQL queries will slow down our response time, which can make our app feel laggy and unoptimized. This is where a cloud-based image and video management service comes in. These services can store our images for us on the cloud and all we'll need to do is save the URL link of this image in our database instead of the image itself. If our app was to even have videos, these services can help store videos as well. All major applications we use in the web actually utilize these services. For example, let's check out Airbnb. If we go to one of their listings and look for the image and try to find the source for it in the document inspector, we'll see that this particular image is hosted by the following URL. Cloud-based image management services solves the previous two problems we talked about. We're not going to be storing the images directly into our database anymore. We're only going to be storing the URL link to it. This makes our database smaller, which increases the speed of certain database operations, such as copying, reading, backups, etc. Not to mention, this potentially saves money, since database memory oftentimes costs money. It also makes our app much more responsive because we don't have to transmit our query all that image data from our GraphQL queries. Our GraphQL queries will only have the URLs, and when we pass the URLs to the HTML image tags in our client, they'll load the individual images in parallel. Another significant advantage that we won't necessarily use in our application but is incredibly helpful is that these cloud-based image services often allow the capability to manipulate and enhance images with a URL-based API. With popular cloud-based solutions, practically any kind of image manipulation that we can think of can be done, such as changing the pixel size, adding filters, rotating , rounding corners, and much more. In fact, if we take a look at the URL we found for that listing in Airbnb, if we look closely, we can see a query parameter that says 8KI policy extra-extra-large. Now I don't know what cloud-based solutions they're using, but we can probably gather that this image is given an extra-extra-large size based on this particular parameter. If I was to change this to extra-large, I'll get a slightly smaller image. Large, give me a smaller image. Medium will be even smaller. This is incredibly helpful for multitude of reasons. One, we don't have to manipulate images often through CSS if we're able to simply obtain the image sizes we're looking for directly from the URL. Although many different cloud solutions exist, one of the more popular cloud- based image and video management service is Cloudinary. Cloudinary has a free plan allowing us to store around 25 GB of managed images for free, which is perfect for trying it out in our development stack. So we'll use Cloudinary. If you don't have a Cloudinary account, the first thing you'll need to do is head over to the Cloudinary site, Cloudinary.com, and click on the signup for free button . Here's where you'll be able to fill in your information and sign up and create a new account. Once signed up, Cloudinary should send you a verification email for the email for your account, so do verify that email request. Before you create your account, within the signup form, you should have the opportunity to provide a name of your choice for the cloud that Cloudinary would give you where you can store your images and videos. We'll encourage you to pick a name that you prefer, however, if you don't do this here, you should also have the opportunity to change your cloud name in the account settings section of your Cloudinary dashboard. When you've verified your Cloudinary account and have signed in, you should land in the dashboard of your Cloudinary account. This is the /console route. Here we're able to see some stats about our Cloudinary account. But what is of interest to us is the account detail section at the top. To use Cloudinary's API in our server account and make changes to this particular dashboard, we'll need to have all three of these account credentials saved in our server, Cloudname, API Key, and API Secrets. Since these are environment-specific information, let's store this information in the .n file of our server projects. We'll copy over the cloud name first and store its value for an environment variable we'll call Cloudinary-Name. We'll copy the API key and store it as an environment variable we'll call Cloud inary_Key. And finally, we'll copy over the API secret and store it as an environment variable we'll call Cloudinary_Secret. Great. The next lesson we'll pick up from here and utilize Cloudinary to host the listing images of our application. [BLANK_AUDIO]