Create a new project for consuming data with Javascript

[mortenson]

Looking at the example consumers for this project, there have been a few attempts at parsing JSON API data coming from contenta_jsonapi:

1. In contentacms/contenta_vue_nuxt, a new service was created using d8-jsonapi-querystring and jsonapi-parse packages. This allows you to generically query JSON API data, using a well-structured query object.
2. In contentacms/contenta_angular, a new service was created using ngrx/store. This allows you to query for recipes abstractly and parse the JSON API response into recipe models, and change the app state when recipes are loaded.
3. In contentacms/contenta_react, a new Redux action was created to make/parse a recipe response and dispatch another action to load the front page.
4. In contentacms/contenta_ionic, a new service was created using angular2-jsonapi to abstractly query models from JSON API that are defined by their attributes and endpoint. These attributes can also define relationships to other models, which angular2-jsonapi will parse automatically from the JSON API "relationships" object. angular2-jsonapi is, unfortunately, not maintained anymore.

The various consumers are welcome to query JSON API data in any way they choose - but what do we recommend for developers starting new projects with Contenta?

I propose that we create a new project either documenting best practices for making requests to Contenta, or providing a generic service that everyone can use.

Here are some example requirements for a consumer-solution, which we can discuss and redefine here:

1. Can use query objects instead of concatenating query strings
2. Supports authentication methods provided by Contenta
3. Handles sub-requests (both sending and receiving them)
4. Allows (but not requires) users to model data and not query Contenta directly with HTTP. i.e. something like recipe.save() or recipe.image.uri should be possible.
5. Works with all frameworks/libraries, so that existing state handling in consumers could still happen. Alternatively we can write multiple docs/services.
6. Implements or documents client-side cache, to support offline-first implementations.

[mortenson]

On Twitter @mattgrill mentioned that waterwheel.js already has JSON API support, and is planning to support sub-requests.

[yann-yinn]

I did not try waterwheel with contenta : I thought it was only working with core REST module and not JSON API standard. Maybe we should start here ...
Waterwheel seems to work with axios http request library, which is a good thing for vuejs + nuxtjs, as it works both on Server Side Rendering and the browser.

[mortenson]

I filed acquia/waterwheel.js#60 to potentially add resource modeling to Waterwheel

[yann-yinn]

I'm currently switching to waterwheel instead of "d8-jsonapi-querystring" npm package on contenta_vue_nuxt. I keep using "jsonapi-parse" npm package to resolve relationships / included objects.

[e0ipso]

Would it make sense to move the parser into waterwheel?

[mortenson]

I mentioned it in acquia/waterwheel.js#60, it would be a good first step to get everyone using it.

[yann-yinn]

I did the full switch now, works very well : https://contentavuedemo.github.io/
Would recommend waterwheel to beginners because of its authentication support (did not try it yet)
Works well from Browser AND server-side , perfect for me.

[e0ipso]

That looks like a nice resolution.