koop-retired / koop-provider

Koop provider toolkit.
http://koopjs.github.io/docs/providers.html
Other
2 stars 1 forks source link

what is actually required #2

Closed calvinmetcalf closed 7 years ago

calvinmetcalf commented 8 years ago

I'm having a bit of trouble understanding the relationship of model, controller, and route, it looks like any sort of query by id would be on model, but any sort of query that would provide more then one record would be in controller and route seems to be a way to add new paths to the sever, which I'm not completely sure what the point of is as isn't a provider a sort of backend way of getting data in? why would they need to add routes?

jgravois commented 8 years ago

please take this answer with a grain of salt, but my understanding is that routes are what allow you to map both additional capabilities and to navigate directories.

for example, in koop-agol and koop-github routes are used to dictate what business logic is invoked (for example so that Esri Geoservices JSON or a geohash will be returned instead of GeoJSON).

calvinmetcalf commented 8 years ago

ok the github one is especially instructive as it shows mapping github specific parameters,

dmfenton commented 8 years ago

@calvinmetcalf

It looks like this:

Routes => Controller Function <=> Model <=> Remote API

A request comes in via HTTP and is passed to the controller function that is mapped to the first route the request matches. The controller will then call a function against the model. The model's job is to handle the data from the remote API and/or the cache. It will return either geojson or an error and the controller will pass the appropriate response back to the requester.

The most instructive examples of this (to me) are https://github.com/koopjs/koop-yelp and https://github.com/dmfenton/koop-craigslist.

You can think of a provider as an adapter to some arbitrary 3rd party API. In order to fetch the data the user wants, a set of parameters needs to be passed back to that API. The provider's job is to take those parameters and return geojson.

Any time a provider is added it's going to need it's own set of routes in order to handle that translation with the 3rd party API.

Does that make sense?

calvinmetcalf commented 8 years ago

That is a fantastic answer

dmfenton commented 7 years ago

Closing in favor of https://github.com/koopjs/koop-sample-provider which has been overhauled for Koop 3.0. It specifically states whether files are mandatory or optional. Provider docs go into a lot more detail about each filie.

Koop 3.0 also dramatically simplifies what's needed for a provider. If you want to use the /FeatureServer endpoint, all you need to do is create an index.js file and implement a function called getData in model.js.

Happy Kooping!