Content Store as real CMS

Heyho,

we are planning to use the Content Store as a real CMS for our application. Currently we have static images in use, which are part of our frontend static resources. But in the near future we want to save selected predefined images and create images in the backend and using them in the Frontend later.

We still have to make thoughts if we want to handle these static images (there at compile time) by still having them as static images in the Frontend or storing them in the CS. At least uploaded or created images has to be saved in the CS.

Some questions:

Is it possible to upload images during the startup of the application ?
Image we will move all images at compile time into the CS, we have to do that before the application is deployed fully. Is there already a way to upload images or do we have to use the migration support and uploading them ?

Fixed Ids
Is it possible to have some fixed ids ? So when i upload an image, i can get the image by a fixed value/name/id ? Or do i have to upload them (e.g. during migration) and persist my own mapping from name to UUID ?

Are there experiences about the performance ?

We are building a SaaS, so have high traffic might be possible in the far future and the ticket system requires two calls to the CS.

Happy Regards,
Tjorben

Hi @tjorben-atomic-moss,

The content store (CS) from DS can store content and efficiently serve it to callers. When using public content, you have the option to use stable URLs; unlike private content, no additional request is needed to make public content available for download.

CS is clusterable and can run in multiple replicas. (Note: if you use a filesystem-based implementation, the volume must be shared between replicas.) Performance is highly dependent on the type of data you store in CS and the expected volume of read operations.

I do not recommend using CS as storage for static resources like application logos—Apache is better suited for this, and a Spring Boot application using CS will be slower. CS does not store any metadata about content, nor does it provide cleanup logic or security features. All of these features are handled by DS: DS tracks which attachments (content IDs) are assigned to which documents, and manages their scheduled deletion.

If you decide to use CS as a standalone service without DS, you will need to implement your own logic to keep track of the content created in CS.

Hello @tjorben-atomic-moss , I am a member of the Discourse team. I can see that there was a new response to your question on Content Store as real CMS. Do you find it helpful, or should the question remain open?

Thanks ahead for your feedback and have a nice rest of the day!

Heyho,

yeah sorry i had a call together with Tomas. We use the CS for storing our images. In rare cases also static resources, but we had to implement an own way to get fixed ids.

Thanks to @tomas-thin-gale

Case can be closed