Food for thought

[ds0nt]

Not so much an issue: I just saw this config.json from microsoft azure cloud service video.

Here it is:

Due to the nature of where I found this video, I feel I must explain myself. I was re-evaluating freedom-clouddom, and was forgiving video as a medium of what should be encyclopedic information which is a tangent of actually looking for surveying software, modular, deployable. (know any?).

[simov]

I don't understand what are you saying. Can you structure your question/comment into separate sentences and try to explain your thoughts in more details?

Also I don't see how the above configuration is related to this module. If you are looking for a generic REST API client library, check out Purest.

[ds0nt]

Hey, sorry about that.

I thought you might find it interesting to see an azure configuration file interesting for another perspective/semantic.

Right, like who wouldnt?

Thanks, yeah purest is the thing in my head that gets confused with grant, because I have actually used neither, however when combined, bestow integration superpowers in ds0nt-theory

But anyways, I just contributing a bit of food-for-thought from my azure excapade.

[ds0nt]

for comparison, betterment, and such.

[simov]

That's fine, I just really couldn't figure out your point at first. My best bet was about the REST API client library because I saw endpoints key in the screenshot.

Grant is concerned only with the authorization_code grant type (and OAuth1.0), that's the flow that requires user interaction and a session store on your server. Grant also allows you to use any of the major web frameworks in NodeJS without changes to your configuration (other consumers can be added as well).

Purest on the other hand is a generic REST API client library that builds on top of the request module.

The flow is as follows:

1. Configure Grant and run your server
2. Get the user's tokens and store them somewhere
3. Pass those tokens and any other parameters to Purest to request any endpoint from that provider

BTW, v2.0.0 of Purest is almost complete, and it will be published the next week, so if you are interested in you can check it out by the end of the next week - greatly improved docs, new features, examples and a minor breaking change.

[ds0nt]

So how difficult would it be to recreate zapier, let me pull out some ideas I had way back when...

[ds0nt]

These are some old ideas I still am a bit fond of. :) Any thoughts?

[ds0nt]

"Easy" ways to monetize include... slaps former self wrong! not easy!

[simov]

I got your point with these diagrams. Grant and Purest are built exactly for such cases, but they are on a very low level of a complete system.

From the diagram above:

We can create a common interfaces for a set of APIs ...

That's the first step. Purest's main design goal is exactly that - to help you built such interfaces more easily. You can take a look at the social, mail and the storage example wrappers.

Although overly simplified these wrappers shows you the basic idea. That's the layer that handles the inconsistencies between all of these REST API providers. You have a common set of input options for each provider's method, and a common data structure to return the data from each method.

Once you have that layer, you can build higher level methods if you want. Purest helps with removing the inconsistencies on a very low level, but as you can see in the above three examples, the code in the provider folder have a common API, it's relatively easy to understand, it's declarative and it can be unit and system tested easily.

A little bit about the implementation: not all systems provide HTTP hooks for events that happen on their servers. For such systems you need to have background workers that syncs the data you need on certain interval of time.

All REST API providers have quota/rate/threshold limits, so you have to cache all the data you need on your own local database server. Your users almost never sees the data in real time. That's the case with the public API's that are free.