Uploading images to the server from the admin panel for the front?

Question

Programming

Dear Khabrovites!
I broke my head, I can’t think of anything interesting.
A little background: I develop websites, I developed a small framework for this. I write on asp.net mvc and usually I make a separate Area for the admin panel. With this organization of the project, everything is ok, I upload files to a separate folder (eg ~/content/images/), the part that is responsible for the front freely accesses files from this folder, no difficulties. Moreover, I wrote a helper that generates a picture of the required size directly when accessing it. It looks something like this: I recently decided to separate the admin panel and the front into different projects in order to be able to scatter them across different domains. This is where the problems started. Where and how can I upload files? thought about these options:
@Html.ImageFor(Model.Image, 150, 250)
1) just drop it into a folder in the admin panel, access it from the front. I don't like the option, because I don't want the user to know about the admin domain.
2) write a service that is located on the front, saves files to a folder on its domain. As if the option is not bad, you can make an implementation of the service that would save files somewhere in the cloud. And everything would be fine, but then what about the size? After all, with this implementation, I can not generate pictures of the desired size.
3) the previous point + set the size of the pictures in advance, in the site settings. in this case, I lose flexibility in layout. That is, the layout designer, in addition to knowing in advance which pictures and what sizes should be, must also climb somewhere else and indicate these sizes.
In general, I am at a great loss and really hope for your wise advice.

Answer 1

1) It is not entirely clear why you need to generate images of the required size at the time of accessing them. Usually all variants of pictures are generated at the time of loading.
2) If, nevertheless, it is more convenient for you, in any case, in the place where you will store the pictures (and form them on the fly), you will have to write some kind of preprocessor code. For example, Nginx first tries to get an asset, and if it doesn’t find it, it transfers control to the software part, which is responsible for generating and saving the image. Immediately after the first call to the image, it will be created and Nginx will immediately send it to the client as a ready-made asset, without transferring control to the script anymore.
3) There can be no problems with sharing images. Only the path to the asset is stored in the database. For example /public/pics/flower.png. Since you are programming the system yourself, both on the front and on the back, you can easily set a specific path to your CDN in constants + set your own rules for forming image names.
For example:
Only
/public/pics/flower_original.png
is stored in the database And then you can form anything based on this base url.
/public/pics/flower_8000_6000.png
/public/pics/flower_800_600.png
/public/pics/flower_80_60.png
Storing URLs to all image options in the database is nonsense.

Answer 2

Have you considered a CDN option like Amazon S3? Or via ftp add the necessary pictures from the admin panel directly to the front?

Answer 3

The problem is with image processing. How to generate a picture of the sizes I need so that this happens during layout? Well, and then when processing user files.
Hypothetical situation: A user uploads a 6000 x 8000 px photo. When saving, I form an image of some acceptable size, say 1500 by 2000 px, but for displaying previews, I want to display images sized 150 by 200, and when displaying in the sidebar, some other size. You can’t foresee everything right away, so they are generated for me the first time they are accessed and saved, so a direct URL is taken right away, based on the required image sizes.
If we project the current implementation onto what I want, then in order to determine whether it is necessary to generate a file, I need to check whether such a file exists at such and such a URL (I used to check the file in a folder), and if not, then download the original one, make a new one, feed the new image saving service. But this is nonsense, of course.
There is another idea: store urls to all generated sizes in the database. But somehow it doesn't seem normal to me.
I want the perfect solution

Answer 4

I thought a little more.
I'll write in more detail:
Point 1. Maybe they do it usually, but the option that I use now allows you not to bother during the programming of the site, about the sizes needed for layout. I repeat, the picture is generated 1 time, then the path to it is formed from the required dimensions.
Point 2. At first I liked this point. But in fact it turns out the same get-request. That is, a potential "intruder" can run a bunch of requests for different image sizes, thus tormenting my server. In my current version, only those images that are specified in the template during layout are generated. The file physically exists when the page is rendered.
Point 3. There are no problems with this, specifying the path and the rule for generating the file is not a problem. The goal is to ensure that when this name is formed, the file has already been created, and not created upon request.