Dynamic serving of public assets (images)

[tmlmt]

I do not know whether this is a feature request, an issue or a misunderstanding. Despite the doc says that:

All assets in public/ directory will be automatically served.

All assets added in the public/ directory after build are not served and requests lead to 404 errors in production
Is there a way for that behavior to be corrected?
It works as expected in a development environment in Nuxt 3

In order to avoid an XY Problem situation, I can explain what I am actually trying to achieve: user upload of images is part of a Nuxt app I am developing (and for which I would like to self-host everything (i.e. not depend on external providers)). I was thinking to simply save these images in the public/ directory so that the new ones can be served as well as the old ones already in the public/ directory at build time. A few questions arise:

• Is my approach the best one for my case? (it's a small hobby app, I do not expect more than 1000 users and 5000 images to be uploaded eventually after 1 yr). I thought of several workaround:
  • storing pictures as blob in a database (I'd like to avoid that, for no particular reason other than not being convinced of the real benefits vs storing as files)
  • using nginx currently also running on my server to serve a particular subfolder of /public, e.g. /.output/public/images. Is that stupid?
  • but ... I don't know if these are valid ideas. And was hoping for solving it through your help in understanding nitro / nuxt
• How could I then make it work with asset optimisation? i.e. some kind of dynamic image optimisation. Would using nuxt-image with ipx as provider solve my issue?

Thanks a lot for your help

[mouldt]

My experience is the same as yours, anything not present in the public folder at build time is not visible at runtime. So you can't just drop extra files into the /.output/public folder like you could on a 'normal' webserver.

That said,
why not use an API for your image upload? within the API method you can store the image wherever you want, local file system, database, blob storage etc. Hard to say what's best here. You don't mention how/where you would host your app i.e. a server/vm you own/maintain or some cloud provider service. Resilience would be a concern i.e. how does you images folder survive a server deployment? if the folder was external to the deployment or using an external storage then this is not an issue.

You also don't mention what you want to do with these images i.e. some form of gallery pages? a pageable API to retrieve a number of images could be the answer for this kind of thing.

Just my 2p, take this as you wish.

[tmlmt]

Hi @mouldt and thanks for having taken the time to share your thoughts.

To answer your questions first:

• Why not use an API for image upload?
  I do go through an API endpoint to take care of processing uploaded images. Most modern, especially commercial websites would probably rely on a CDN to take care of storing and serving images.
• Where would you host your app?
  I have taken the religious choice for my hobby not-for-profit project to self-host everything. So I want to store things on local fs, and instead of decoupling things, store these images together with the rest of my app. It's probably not the greatest idea, for the issue referenced in the title of this discussion, and for the next point you make. What I'm doing for the moment is storing uploaded images directly in .output/public/
• How would the images folder survive server deployment?
  Good point. That would require in my case a good backup and seeding procedure. But it is not my intention to change infrastructure anytime soon. I'm playing with and replying on my home server.
• What do you want to do with your images?
  I am listing places, and want to show a gallery of images for each place.

Coming back to my original question, I realize some time (1 month) has passed, and I managed to meet my need by using nuxt-image to display the images. The pre-configured ipx instance it comes with, do serve the specified folders dynamically, i.e serving pictures uploaded along the way.