search

acquia / reservoir

A back end for your front end: a content repository. Powered by Drupal 8, JSON API and OAuth2.
245 stars 30 forks source link

Seems JSON API Extras is incompatible with Reservoir #25

Open dakala opened 7 years ago

dakala commented 7 years ago

It seems as if Reservoir and JSON API Extras don't play together. I get this error:

Recoverable fatal error: Argument 3 passed to Drupal\jsonapi_extras\JsonapiResourceConfigListBuilder::__construct() must be an instance of Drupal\jsonapi_extras\ResourceType\ConfigurableResourceTypeRepository, instance of Drupal\reservoir_ui\ReservoirResourceTypeRepository given, called in ....

The full message gives an indication as to what might be wrong. Would the features provided by that module be useful in Reservoir please?

Sample output on a vanilla D8 site:

json_api_resource_config

Thanks.

wimleers commented 7 years ago

Looks like this is a bug in https://www.drupal.org/project/jsonapi_extras. Working on a fix.

wimleers commented 7 years ago

Out of curiosity, why did you want to install the JSON API Extras module? (We'll get the bug fixed anyway, but still, just asking.)

wimleers commented 7 years ago

Yep, it's a bug in https://www.drupal.org/project/jsonapi_extras. Created an issue: https://www.drupal.org/project/jsonapi_extras. This is now blocked on that issue being fixed.

dakala commented 7 years ago

Hi @wimleers. Thanks for the quick response and confirming it's a bug.

I'm only evaluating/studying Reservoir for decoupled Drupal projects - maybe a POC to write about, if the study goes well. There's a couple of areas I haven't seen addressed yet e.g.

I'd like to have everything managed in the backend (content editors, site builders etc can do their work) so that the frontend will only deal with delivering content. All of this may just be a dream or lead to alternative solutions.

I know custom entities can solve the problem of not having "field_" prefix in field names but I found it interesting that JSON API Extras allows the data exposed by the API to be massaged too. Also menu links are content entity so exposing menus to the API might not be too difficult.

In the meantime, for menus, I found out something in Wordpress - https://wordpress.org/plugins/wp-api-menus/ which I'd like to have a play around with to see what it's about. At least it shows that exposing menu structure through an API is a possible solution that may be worth pursuing.

Sorry if all this doesn't make much sense :)

wimleers commented 7 years ago

I'd like to have everything managed in the backend (content editors, site builders etc can do their work) so that the frontend will only deal with delivering content. All of this may just be a dream or lead to alternative solutions.

99% of decoupled sites don't allow the back end to configure the front end. They just change the code in front ends. So unless there's lots of requests for things like menus, that won't happen. Focus & simplicity are important.

I know custom entities can solve the problem of not having "field_" prefix in field names but I found it interesting that JSON API Extras allows the data exposed by the API to be massaged too. Also menu links are content entity so exposing menus to the API might not be too difficult.

Actually, removing the field_ prefix is highly risky. See https://www.drupal.org/node/2846872.

In the meantime, for menus, I found out something in Wordpress - https://wordpress.org/plugins/wp-api-menus/ which I'd like to have a play around with to see what it's about. At least it shows that exposing menu structure through an API is a possible solution that may be worth pursuing.

Something like that is also possible in Drupal. But there seems to be very very little interest in this: only ~2000 WordPress sites are using it, out of millions. Note that nothing is preventing you from installing the Drupal menu module and then using JSON API to access /jsonapi/menu_link_content/menu_link_content!

Sorry if all this doesn't make much sense :)

No, it all makes sense — you're trying to solve a specific use case!

dakala commented 7 years ago

If Reservoir is only concerned with content in the backend then there's still a missing block from this architecture in order to have a decoupled site. Some site configuration has to be managed "somewhere". If not in Reservoir then a different "backend" system solely dedicated to configuration is required. This kind of scenario of a second backend isn't ideal.

An example of taxonomy was mentioned in one issue on the Reservoir queue but I can't find it. Your suggestion of installing menu follows the line of thinking with those who think taxonomy should be exposed automatically by Reservoir. The response to that was that tags is already supported anyway which is how far Reservoir wishes to support taxonomy anyway.

I mentioned that Wordpress plugin to illustrate that menus can be exposed in an API. We should be comparing the ~2000 with the menu plugin against Wordpress sites that are API-only and not all WP sites since they don't all need menus from an API, right? :-)

My ultimate decoupled site should have 2 main components - backend and frontend. All content and configuration should be done in a single backend and the frontend should only be making API calls to the backend.

Of course Reservoir is Drupal so any module can be installed.