Problem/Motivation

One big usecase for jsonapi is using is to write a decoupled frontend.
Most people associate a javascript frontend with that, but there is technical no fundamental reason to not write it in PHP as well.

One thing we could do is to provide a function in twig, for example {% set = jsonapi('/node/article/' {{ node.uuid }}) %}
This implementation could talk to jsonapi via PHP or via HTTP.

@TODO Write a better issue summary

Proposed resolution

@TODO

Remaining tasks

@TODO

User interface changes

@TODO

API changes

Data model changes

Comments

dawehner created an issue. See original summary.

dawehner’s picture

StatusFileSize
new3.42 KB
dawehner’s picture

Status: Active » Needs review

This is just a example implementation to get the conversation started.

Status: Needs review » Needs work

The last submitted patch, 2: 2852272-2.patch, failed testing.

killua99’s picture

I love the idea, might be even better to move it outside the main functionality of JSON API?, like a sort of JSON API extension ? since the JSON API in core I imagine will not have this functionality, will conserve the main functionality that is provide the RESTful resouces.

dawehner’s picture

Status: Needs work » Needs review
StatusFileSize
new6.16 KB
new3.82 KB

This time with some actual test coverage for the new functionality.

Status: Needs review » Needs work

The last submitted patch, 6: interdiff-2852272.patch, failed testing.

hampercm’s picture

I'm not understanding the point of doing this. If you're going to be creating a Twig template to display a node, why use a decoupled architecture at all? Why not just use a single Drupal site and theme?

It also seems like bad practices to be effectively executing code inside a Twig template. Preventing that was one of the reasons why Drupal moved to the Twig template system in the first place. Templates should be used for declaring how to display something in HTML form, nothing more. Mixing in other functionality is very likely to lead to trouble later.

e0ipso’s picture

I like this idea. In theory, I think it makes sense in the context of an isomorphic JS application with a Drupal front end. Is that the intent @dawehner?

why use a decoupled architecture at all?

Think about an isomorphic application where you have your twig templates that are reused in the front-end (via twig.js) and in the back-end via Drupal.

It also seems like bad practices to be effectively executing code inside a Twig template.

I may be wrong, but how I see it is a front-end component declaring its data dependencies. Again, I think it makes sense when you put it in the context of an isomorphic application.

dawehner’s picture

So yeah there are two main factors for me:

Unless we dogfood our own systems we will never be API first. Our HTTP APIs will always be behind. By being able to leverage our systems internally we know that others can do as well, so we can catch a lot of problems of front.

On top of that theoretically providing something like api() inside templates, there is a potential for a improved themer experience, which, let's be honest, is a complete nightmare right now. Unless you know the PHP code underneath an entity object, you won't have an easy life fetching data.

I like this idea. In theory, I think it makes sense in the context of an isomorphic JS application with a Drupal front end. Is that the intent @dawehner?

I have no thought about an isomorphic background to be honest.

I may be wrong, but how I see it is a front-end component declaring its data dependencies.

Yeah exactly. The fact that we use some description could provide some future opportunities.

e0ipso’s picture

I'm very interested to see where this goes. Let me know if you are blocked by anything I can help you with.

dawehner’s picture

@e0ipso
The general functionality is working, now I think we need a concrete project to prove that this is actually working.
One idea I had in mind was to try to reproduce what the default theme/content initiative produces but fetching the data via jsonapi.

Another nice step would be to write a twig extension which provides the same API, but instead does a HTTP request via guzzle, so it can be used completely without Drupal aka. a fully decoupled rendering.

dawehner’s picture

Here is some github repo with a twig only frontend: https://github.com/dawehner/drupal-streetart

e0ipso’s picture

Thanks Daniel. I need to look into the code you are sharing.

damienmckenna’s picture

Two suggestions:

dawehner’s picture

I totally agree, it would be nice to directly call out to it without having to fake a HTTP request.

Iterate over the generation code so it doesn't need a HTTP request.

The really nice part about using an HTTP request is that this actually ensures you can decouple the template completely. If you think you could use a similar kind of twig extension in a PHP library only project which does the actual HTTP request but beside of that works exactly the same.

damienmckenna’s picture

What would you all think about restructuring this to work off #2874509?

damienmckenna’s picture

Status: Needs work » Needs review
StatusFileSize
new5.32 KB
new1.38 KB

WIP, based off #2874509.

damienmckenna’s picture

Status: Needs review » Needs work

Oh, the tests will fail because #2874509 hasn't been committed ;-)

dawehner’s picture

@DamienMckenna
Will your service support also collections?

damienmckenna’s picture

@dawehner: Right now the logic is almost exactly the same as #6, just moved into the main module and wrapped in a new service.

e0ipso’s picture

Status: Needs work » Fixed

@dawehner, @DamienMckenna does the new service that will let you serialize entities programmatically help to this end?

dawehner’s picture

@e0ipso
I'm confused why is this suddenly fixed without having an actual commit?

e0ipso’s picture

Status: Fixed » Postponed (maintainer needs more info)

A new service was added in a different issue. My question above was to make sure it helps in this direction. The status change was an error.

Thanks for catching that!

dawehner’s picture

No worries :)
So yeah the service certainly helps, we could just call it from within the template now ...

wim leers’s picture

Project: JSON:API » JSON:API Extras

There seems to be fairly little interest in this. Last worked on nearly a year ago. Let's move this to JSON API Extras.

e0ipso’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

I'm closing this as part of issue queue cleanup. Please reopen if necessary.