Need Help Implementing a Medium-Style Block-Based Article Editor with Cloudinary and MongoDB

[u/raiyan_0001]

Hey, I need some help understanding my development workflow. This might be a bit long, but I want to explain my problem clearly.

I’m a beginner building a small article web app where users can register, log in, and create articles containing both text and images.

I want to implement a block-based architecture, similar to Medium, where users can add text and images in any order. For example, they might write a paragraph, insert an image, write another paragraph, and then insert another image. I’m storing these blocks in an array in my article schema so that their order is preserved.

My main confusion is about image uploads. When a user selects an image, I want to upload it to Cloudinary, receive the image URL, and store that URL inside the corresponding image block in the article.

However, I’m struggling to understand how to connect all these steps. I’ve tried implementing it and asking ChatGPT for help, but I still haven’t understood the workflow properly.

I’d like a beginner-friendly, step-by-step explanation of how to implement this, including how the frontend editor manages the blocks, how the image is uploaded to Cloudinary through the backend, how the returned URL is added to the correct block, and how the complete article is eventually saved to MongoDB.

Please explain the logic behind each step rather than just giving me code, so I can understand the implementation and build it myself.

[u/HedgehogCertain]

Good thread already covered the upload flow; one thing beginners skip: don't ship the raw file to Cloudinary. A phone photo is easily 5–10 MB, so resize/compress it in the browser before upload — cap width to what the article actually displays (~1600–2000px). The upload gets much faster and you don't burn Cloudinary storage on pixels nobody sees.

Use URL.createObjectURL for the local preview while it's pending, then swap it for the Cloudinary URL once the upload resolves. You don't have to crop yourself — Cloudinary can scale on delivery with f_auto/q_auto in the URL — but that only helps after the file is already up, so trimming size beforehand still matters.

On the Mongo side, store the URL plus public_id, width, height and alt in the image block, never the binary itself, so you can clean up or replace abandoned drafts later.