#Create storage abstraction library

1 messages · Page 1 of 1 (latest)

drifting garnet
#

Many modern frameworks incorporate their own storage layers to facilitate communication with various storage options such as local disk, S3, GCP, and others.
Few examples are :
Laravel - File Storage
AdonisJS - Drive

I recommend developing a new library such as @nestjs/storage that can effectively handle communication between applications and their designated storage layers.

I came up with the idea for "@nestjs/storage" while developing a serverless app for AWS Lambda. I needed to use the local disk during development and S3 for deployment. A library like this would be beneficial as it eliminates the need for developers to create custom storage solutions, which can be challenging.

One potential reference for the development of such a library could be the deprecated @codebrewlab/nestjs-storage library.

Laravel - The PHP Framework For Web Artisans

Laravel is a PHP web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small things.

idle raptor
drifting garnet
#

Indeed, this is my initial encounter with this package, to be honest. While it may possess desirable qualities, I think a package developed and maintained by the Nest team would be more reliable, without disrespect to the author of this package.

versed whale
#

Any reason you want the nest team specifically to manage it? If the community member(s) want to maintain that package that they created that's a burden off of us

drifting garnet
#

The main reason is because some packages are unreliable and hard to maintain. Most of them use an outdated version of AWS SDK, v2, when v3 is already available and comes pre-installed in Lambdas Node 18. We need to use v3 for our project, and although we'll make a pull request to update it in the other community based packages, we still believe that core team-based libraries are more dependable and better tested than community-based ones. No offense to anyone, though!

versed whale
#

some packages are ... hard to maintain

And so the burden should be on the core team?

we still believe that core team-based libraries are more dependable

Well, thank you for that. It's still more of a burden on us to maintain a package like that.

I might make something for @nest-lab that handles local files and sets up the plugin system so they anyone in the community can create an S3 or whatever other storage drive they want to go with it

latent ember
#

we still believe that core team-based libraries are more dependable and better tested than community-based ones
I would agree with that if the core team was much bigger or if at least one member of the team could work full-time for @nestjs/ only (like the legend https://github.com/sindresorhus).
I know that the community seems to be more happy on maintaining those @nestjs/* packages than a community-based one. But that doesn't seems healthy for the nestjs community in general.