Best practices for uploading image in multipart/form-data

[sprhawk]

For now I think loopback is great for simple model and apis

But in real life the situation is more complex. I want some best practices for two examples.

First, 

Say I want to send a post to a timeline

I need some metadata ( content , tags, author, related friends) and one or more media.

If in an express backend, I can just handle all the request and do some post-process before creation ( eg, image processing ).

But in loopback I need to upload via component-storage service then a client (Client SDK all operate on the model object via REST ) need to handle how to reference the images from Post instance.

When I get the list of posts, an express backend can do pre-process, eg transform image reference with a real / CDN cached image url, but I think loopback may do it naively ( with file object by component-storage ) ?

So can I do this more intuitively ( like an express backend do ? )

Second, nosql db can construct model more complex, eg embeded document. Say I save all image references in Post instance as embeded documents. But in loopback it  cannot change the embeded document easily ? So I have to do it more like a sql db ?

I am struggling with image upload and complex model for many days.

For now I concluded loopback is pretty good for simple model / api generation but not much customizable. 

Due to loopback doesn't expose many internal APIs ( such as database api, request handling hook , so I cannot hack it ), only one or two reasons can cause I to drop it.

The only reason I need loopback for now is its built-in ACL and user mechanism.

[Raymond Feng]

Thank you for the feedback. Handling file uploads with metadata is always tricky. From the developer experience perspective, we have a roadmap item to make it part of the remoting capabilities. Here is the rough idea:

1. We allow remote method parameters to be typed as ‘File’. If one of the parameters is typed as ‘File’, only ‘multipart/form-data’ content type is supported.

2. The incoming http request will be handled by https://github.com/expressjs/multer (or similar middleware) with a custom storage that allows the files/fields to be passed to strong-remoting.

3. strong-remoting will invoke the remote method with values/streams from the multipart/form-data.

4. The code in the remote method implementation handles the business logic, possibly a mixture of model CRUDs for metadata and Storage Connector for media.

Thanks,

---

Raymond Feng

Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

--
You received this message because you are subscribed to the Google Groups "LoopbackJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loopbackjs+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/loopbackjs/fd7cf104-8301-43b8-a79b-beeed1916ce2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sprhawk]

Thank you.

I want to ask one another question.

Is loopback more like client centric, not server centric.

I mean whether in loopback, best practices are developers do simple server tasks such as  create model. leave more tasks to do in client side (CRUD )?

If so, is this approach less manageable ? client developers have more responsibilities to do the job done ?

But it also cause many logics are done in client side which caused less flexible when the system is online ?

[Raymond Feng]

LoopBack tries to be the bridge between front-end and back-end. You can decide how much to be done on each side. Typically, the API designs are driven by client sides and matched with backend capabilities. To optimize for clients, some of the logic should be done by the backend to avoid chattiness and unnecessary data exchange. For LoopBack, you can define custom remote methods for more complicated logic to integrate with multiple backends. The scaffolding of CRUD APIs provides basic building blocks, and such blocks can be assembled at both backend and frontend.

Thanks,

---

Raymond Feng

Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

On Jul 21, 2015, at 10:12 AM, sprhawk <spr...@gmail.com> wrote:

Thank you.

I want to ask one another question.

Is loopback more like client centric, not server centric.

I mean whether in loopback, best practices are developers do simple server tasks such as  create model. leave more tasks to do in client side ?

If so, is this approach less manageable ? client developers have more responsibilities to do the job done ?

But it also cause many logics are done in client side which caused less flexible when the system is online ?

On Tuesday, July 21, 2015 at 11:15:43 PM UTC+8, sprhawk wrote:

For now I think loopback is great for simple model and apis

But in real life the situation is more complex. I want some best practices for two examples.

First, 

Say I want to send a post to a timeline

I need some metadata ( content , tags, author, related friends) and one or more media.

If in an express backend, I can just handle all the request and do some post-process before creation ( eg, image processing ).

But in loopback I need to upload via component-storage service then a client (Client SDK all operate on the model object via REST ) need to handle how to reference the images from Post instance.

When I get the list of posts, an express backend can do pre-process, eg transform image reference with a real / CDN cached image url, but I think loopback may do it naively ( with file object by component-storage ) ?

So can I do this more intuitively ( like an express backend do ? )

Second, nosql db can construct model more complex, eg embeded document. Say I save all image references in Post instance as embeded documents. But in loopback it  cannot change the embeded document easily ? So I have to do it more like a sql db ?

I am struggling with image upload and complex model for many days.

For now I concluded loopback is pretty good for simple model / api generation but not much customizable. 

Due to loopback doesn't expose many internal APIs ( such as database api, request handling hook , so I cannot hack it ), only one or two reasons can cause I to drop it.

The only reason I need loopback for now is its built-in ACL and user mechanism.

-- 
You received this message because you are subscribed to the Google Groups "LoopbackJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loopbackjs+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/loopbackjs/43b12fda-04cf-431a-9026-f97a870cd7d4%40googlegroups.com.

[Akshay Singh]

I tried creating a sample remote method based on your description. but the param are coming as undefined when I try to upload a file through swagger. Could you let me know what am I missing here:

Book.upload = function(file, cb) {
  console.log(file);
  cb(null, file);
};

Book.remoteMethod('upload', {
  "accepts": [{arg: 'epub', type: 'file'}],
  "returns": {},
  "http": {verb: 'post'}
});

[ega...@myprojectecho.org]

Thanks for the idea of the roadmap item.  I'm relatively new to Loopback.  Suppose you are already using loopback-storage-component for file upload.  It looks like there is no way to view or change the filename on a request made to a remote method in Loopback, before that request is passed along, that is, to physically upload a file to the container.  Creating "custom storage" for multer merely to parse multipart/form-data so metadata can be viewed and changed seems redundant.  That is, the loopback-storage-component should handle storage, not multer.  Do you have experience of other middleware,not multer, that can view/change metadata, while leaving storage to loopback's component?  Thanks.