Decoupled, my friends...it is the way of the future. Everyone wants it. Everyone needs it. There are many contrib (and core) modules that support it. Lightning should take advantage of this.

I propose to add a new feature to Lightning, as a module that is installed by default. This feature will bring in the OpenAPI and JSON API modules (and whatever else is needed to support those) and expose all viewable content entities as JSON, in parallel with normal HTML rendering. Ideally we would also include some support for OAuth-based authentication against this API-first layer.

I'm opening this issue mostly as a placeholder, but also as a spot for people to +1, -1, debate, ask, and generally bikeshed on this.

Comments

phenaproxima created an issue. See original summary.

gustavo.marcante’s picture

gustavo.marcante commented

This would be great!

There is a nice work being made with Reservoir and Contenta, and joining forces would be interesting.

In my point of view, would be interesting to consider not just JSON API, but also GraphQL as an option, that had alpha Drupal module launched yesterday.

balsama’s picture

balsama
he/him
Primary language English
Location boston
commented

I fully support this and agree with everything in the IS.

Ultimately, if Lightning is to be viewed as a viable solution for decoupled apps, it will need quite a bit stripped out of the UI including HTML rendering. Obviously, Lightning can't enable something like that out of the box since it's primary goal as a traditional Drupal distribution haven't changed. So that functionality would need to live elsewhere. Two main questions:

  1. Where that functionality lives (sub-profile? stand-alone, but Lightning-specific module?)
  2. Where we draw the line between what goes in Lightning the distro and whatever the answer to #1 is

If it's a stand-alone module, many sub-profiles could just build off Lightning and require it. If it's a sub-profile itself, then other sub-profiles could just inherit that - which would make Lightning their grandparent profile instead of parent. Or applications could just build off of the profile itselft - which is already common practice. I think I'm leaning towards the latter since it takes advantage of the existing architecture and we can rely on implementors having the same structure. Something like this:

Lightning
 |- Layout
 |- Media
 |- Workflow
 |- API
 |
 |Decoupled Sub-profile
  |- HTML Render remove
  |- Config UI remove
  |- OAuth2
  |- GraphQL?
  |- Others?
  |
  | Application, or sub-profile
  • HTML Render remove (or the subprofile itself) would also exclude Layout
  • Users could build directly off Decoupled Sub-profile or create a sub-sub-profile (and we now have test coverage for that thanks to oriol_e9g)

To be clear, I'm suggesting this issue is concerned with "API" listed under Lightning.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

Nice! The more people using the software the better it will become.

However it sounds like quite some duplication of efforts. Have you considered integrating / collaborating with the distributions that Gustavo mentions?

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Status: Active » Needs review

Pull request created: https://github.com/acquia/lightning/pull/412

  • balsama committed 7bb19e1 on 8.x-2.x authored by phenaproxima 
    Issue #2896267 by phenaproxima: Support delivery of content entities as...
balsama’s picture

balsama
he/him
Primary language English
Location boston
commented
Status: Needs review » Fixed

RTBC and committed based on feedback here: https://github.com/acquia/lightning/pull/412

Thanks!

balsama’s picture

balsama
he/him
Primary language English
Location boston
commented

@e0ipso yes! Super excited about this. We're working with the reservoir folks to see where we can collaborate. Much of this patch was adapted from their code.

This issue in particular doesn't really overlap with the focus of Contenta. Right now, we just want to allow people to interact with the entities in Lightning using a standard JSON-based API ...provided largely by you - thanks! :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.