feathersjs-ecosystem / feathers-blob

Feathers service for blob storage, like S3.
http://feathersjs.com
MIT License
92 stars 32 forks source link

Could we have the contentType in the create result ? #83

Closed mdartic closed 3 years ago

mdartic commented 3 years ago

This is not a bug, but more a feature request if it sounds useful.

When I upload a new file, that is an image, I would like to create a thumbnail just after it.

By using the returnBuffer option, I can retrieve the buffer and give it to sharp module.

But, I need to do this only if it's an image, and I see that feathers-blob analyze already the uri to retrieve the mime.

Do you think it could be nice to add the contentType retrieved (or initially given for a buffer) in the response ?

This could give this in the response :

{
  [this.id]: id,
  ...(this.returnBuffer && { buffer }),
  ...(this.returnUri && { uri }),
  size: buffer.length,
  contentType
}

Steps to reproduce

When I upload an image, with uri param, I would like to generate a thumbnail by using the buffer retrieved by the feathers-blob service, and I would like to access the contentType (computed or retrieved) in the service. Today, the contentType need to be recomputed, by using the uri param.

Expected behavior

Tell us what should happen

Return the contentType in the service response.

Actual behavior

Tell us what happens instead

No contentType returned.

System configuration

Don't think it's useful.

claustres commented 3 years ago

Hi, I am not sure it is really relevant because the mime type is actually an input of the create operation so that the caller should already know it. It's directly specified for a buffer and part of the URL for a data URL.

It should not be a big deal for you to extract the mime type from the data URL, it's basically a substring to get: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs#syntax.

However, if there is a couple of upvotes for this we can add it anyway ;-)

mdartic commented 3 years ago

Indeed we can extract it, but this could have the advantage to be consistent in the method, As you can create with an uri param without the contentType (needed by buffer), you would receive the contentType found by the parseDataURI or the default one application/octet-stream ? Maybe this idea, if useful, need to be applied to the get method too, for consistency.

claustres commented 3 years ago

Yes it should be consistent with get, it does not seem to me a big deal so we can add it I think. However, I will not have time for this before a couple of weeks. As usual, a PR is welcome!

mdartic commented 3 years ago

I take the time for it ;-)

claustres commented 3 years ago

Always good to have new contributors ! Good work, many thanks!

mdartic commented 3 years ago

Could you publish a new version of the package ? Thanks :-)

claustres commented 3 years ago

released as v2.5.0.