feat: s3 driver

[becem-gharbi]

🔗 Linked issue

#11

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

There is already an open PR (#96) for an implementation based on AWS sdk.

This PR adds an AWS s3 driver based on HTTP for a lightweight bundle size and edge runtime compatibility.

This is a WIP, I'm not sure if all driver methods can be implemented readme.

Progress

• Implement main methods getItem getItemRaw setItem setItemRaw getKeys getMeta clear removeItem hasItem
• Refactor & optimize
• Add respective tests
• Add respective docs

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[itpropro]

Hi @becem-gharbi,
thanks for your PR! I would like to address a few points to help get the driver ready for merging:

• Remove your playground folder from the PR
• Add the required tests for your driver

  testDriver({
    driver: driver({
      DRIVER_OPTIONS
    }),
  });

• Lazy load the connection for example with getAwsClient(), you can check some other drivers for similar implementations
• Can we reevaluate on aws4fetch? It seems unmaintained and the preferred solution from Support s3 driver #11 was direct HTTP, which should be possible with ofetch and uncrypto
• Implement at least getItem, setItem and clear in addition to the existing methods for basic string based kv operations
• Add respective docs for the driver

[becem-gharbi]

Hi @itpropro, thanks for your help.
This solution is a direct HTTP client, aws4fetch is there to sign the request by generating headers for authorization. To be honest I'm not familiar with AWS signature. However the package is stable and works well as expected.

[nuxt-studio]

✅ Live Preview ready!

Name	Edit	Preview	Latest Commit
unstorage	Edit on Studio ↗︎	View Live Preview	7b24a35

[becem-gharbi]

Hi @itpropro, the driver is now ready to review. Regarding test, I'm not sure if using process.env is the way to pass driver options.

[becem-gharbi]

Hi, I have recently converted this PR to a draft. The reason is because this driver is intended to be used with any S3 compatible service. The problem is that some differences exist in term of their implementations. These differences reflect in the driver usage. I have mentioned them in docs. I'm not sure about the current approach and I'm looking forward to your feedback.

[pi0]

(@becem-gharbi sorry for delay on my side to give feedback, if you like, we can still keep it open or alternatively i can continue on this. just assuring you it was not intentionally left unattended)

[productdevbook]

@becem-gharbi Thank you, you've done a good job again. we need to make sure you support all s3 protocols. cloudflare r2, amazon s3 etc.

@pi0 can you prioritize this issue, because this is a need in many areas such as amazon and cloudflare r2. It is an expected feature to use nuxt-og-image together.

[amandesai01]

Thanks a lot @becem-gharbi for the PR! For now, we have hosted your work here.

Your code passes all the tests with 2 very small issues. See open issues in the repo.

Thank you !

[MickL]

Is it really needed to support S3-like environments? Or should they be a separate driver?

For example Cloudlare R2 has a working driver already. On the other hand Cloudflare R2 HTTP driver is currently missing and this could solve #318

[pi0]

@MickL yes it makes sense for unstorage to have explicit vendor drivers, even if they are wrappers but in fact, this driver is auto "compatible" with cloudflare R2.