Unifile next steps

[silexlabs]

Unifile next steps

[JbIPS]

I suggest using ESLint to ensure the code style throughout the repository. And I had some docs on good REST API, I'll post them here as soon as I find them.

[JbIPS]

I'm actually reading this a lot: https://developer.github.com/v3/. It's a very well structured API and documentation. This could be an example.

And just to be sure, every service will now be a prototype, right?

[lexoyo]

I'm actually reading this a lot: https://developer.github.com/v3/. It's a very well structured API and documentation. This could be an example.

yes right!

And just to be sure, every service will now be a prototype, right?

what do you mean exactly?

[JbIPS]

Lately I was thinking about splitting this lib. Unifile would only take care of routes declaration and routing. In addition, services (or connector) would be dependencies, loaded at will and declared like a middleware

unifile.use(require('ftp-connector'));

This way, you only embed the connectors you want and creating a new connector doesn't imply any modification on Unifile (= don't publish a new version any time a connector changes).

And for the connector development, this mean we can ask for a clear API to implements and get rid of some internal parameters in connector function (response, next,...).

What do you think?

[lexoyo]

Wow that's a great idea, like they did with connect body-parser etc.

[lexoyo]

👍

[KrishnaPG]

Also, may be some of these connectors can be reused from Browser-FS. Especially the ZipFS, WorkerFS and FolderAdapter types of extensions are valuable in different contexts.

[lexoyo]

👍 nice project!
And the idea of using nodejs API is a very good one !

[lexoyo]

@JbIPS I have looked at your branch and the sample here
https://github.com/JbIPS/unifile/blob/refacto-api/samples/simple-api-server.js

Concerning this part of the API (the commands)

• This is very nice 👍
• You did not take the idea of @KrishnaPG into account and prefered the "promise" version over node nodejs api, is any particular reason?

Concerning the "useConnector" part

• The name could be use don't you think?
• and by the way, I use service more than connector but it is in fact a connector to a service. We should choose a way to call this concept and stick to it

Concerning the "auth" part

• no json here? just the URL?

Concerning the auth callback

• you should move this code to the connector, so that you can know when the callback is for which connector?

[JbIPS]

You did not take the idea of @KrishnaPG into account and prefered the "promise" version over node nodejs api, is any particular reason?

I'm not sure what you're referring to. Callback vs Promise? If so, I hate calling 4 functions with callbacks consecutively and that's often the case with Web API.

The name could be use don't you think?

I thought so after I had to write it numerous time 😉. Connector or service, I don't really care but connector seemed more explicit to me at the time.

no json here? just the URL?

Don't know what you're talking about, the url must be on the wrong line.

you should move this code to the connector, so that you can know when the callback is for which connector?

I was going to but I remembered that I cannot declare route in Unifile. But maybe a dynamic function? Any other idea is welcome!

And thank you for the review, I hope will make a next version universally applauded! 😄

[JbIPS]

Do you think we should use the same API as fs module? Like unifile.createReadStream()?

[lexoyo]

+1 to replicate fs API

Maybe something like

var db = new require("unifile").Dropbox({...}); 
db.createReadStream();

[JbIPS]

Hi guys,

I did some work on my branch to rework the API and use all of the precious inputs in this issue.

Could you take a look at this and give me feedback to ensure we're heading in the right direction? You can find a usage example here and an implementation of the API here. Thanks!