Meteor-files: Upload via XHR2

[SimonSimCity]

I've until today (because of some issues with my load balancer) been using DDP as the transport mechanism for files and was wondering why nobody implemented an XHR2 compatible upload mechanism here. Is there any particular reason - or has it just not been considered yet?

https://github.com/VeliovGroup/Meteor-Files/wiki/About-Upload-Transports

My primary goal is to skip the splitting of a file into several chunks.

[dr-dimitru]

Hello @SimonSimCity ,

Great idea, so far it wasn't considered yet.
For a long time I have idea of implementing communication module based on request API inside Web Worker, never had time to put my hands on it

[tomtom87]

LB wont work just set a direct upload subdomain that isnt on the LB and upload directly - ensure you have enough swap also

[dr-dimitru]

@tomtom87

1. To avoid SWAP usage, set {streams: 1}
2. Implement "sticky sessions" to "stick" to a server behind LB

Let me know if you require more details.
Also I'd recommend to create separate issue, sounds not related to OP

[dr-dimitru]

Moved to fetch API in v2.0.0

[SimonSimCity]

@dr-dimitru I'd like to have this reopened, as it doesn't fix the main pain-point for me: The amount of messages sent via ddp ... This specially hurts when monitoring the ddp messages and evaluating them.

[dr-dimitru]

@SimonSimCity why? Fetch API is XHR2

My primary goal is to skip the splitting of a file into several chunks.

Without splitting the file we __can not__:

1. Resume upload after connection was interrupted
2. Avoid running into "Max POST size" on many frameworks, proxy servers, and hostings. As a good example using CloudFalre wouls limit such uploads to 100MB on free plans

[dr-dimitru]

@SimonSimCity you might be interested to join discussion here — https://forums.meteor.com/t/new-package-meteor-files-light-need-your-feedback/55061

[SimonSimCity]

After thinking about it for some time, we might be best off with some custom code. When removing the part of resuming downloads, there might not be much left of what this library is focussing to solve, I think. Adding to the soup that we already use Azure Storage for storing the files, there's even less we have in common.

Resuming downloads is not of importance to us in our current use-case, but I can see how this is one of the major benefits of this package. Thanks for the response.

[dr-dimitru]

@SimonSimCity if your use-case is simple you should be good sending classic multipart payload to server