0

I understand that Drupal 9 out of box is very capable as a decoupled aka headless Drupal serves as a back-end for other apps (the core REST, JSONAPI capability).

However, I am thinking about the reverse way: having Drupal 9 as a pure presentation layer that pulls and displays data from various external micro-service APIs. For example, an external API outputs a product list JSON and a Drupal page requests that data to shown it on its page.

It might not need to map the pulled data into Drupal entities, but simply display them to Drupal page. (The reason I don't want to map data and store into Drupal is that it would create duplicated dataset, which probably isn't a good practice for micro-services architecture set up.)

Are there existing recommended approaches, modules for such case in the market for Drupal 9? If no modules are suitable for this case, what are the parts of dev I can further look into (for example hooks used by the Views module)?


UPDATED @ 26th Sep 2021

For reference and anyone may be interested in such situation, I end up with Feeds ecosystem.

Below are contributed modules work together for this:

  • Feeds
  • Extensible Parsers
  • Feeds Tamper

Feeds (main) doesn't have JSON format parsing, Feeds Extensive Parsers (feeds_ex) add JSON support, utilize the JsonPath libraries. Always use 'composer' to install these as lots of dependencies to solve. Use Ludwig module to check if any required libraries missing.

A great reference here: https://www.mediacurrent.com/blog/drupal-8-feeds-import-external-json-api/


Updated: Also

https://www.drupal.org/project/views_json_source

1 Answer 1

1

It might not need to map the pulled data into Drupal entities, just simply display them to Drupal page.

If you are pulling from an external source, and not using entities, why even use Drupal at all? The function of the JSON:API module is to expose Drupal entities via JSON:API; that's all it does. So if you go the JSON:API route, you will need to use entities.

Anyway, Views + most other Drupal modules rely heavily on the concept of entities. Entity API was a contrib module in D7, but it is part of core and one of the fundamental concepts of D8/D9.

So if building a display layer, I would start with figuring out how to map your external data into Drupal entities. Then experiment with JSON:API first before REST, because if you already have entities, JSON:API is very fast to set up (since it exposes all entities by default) and give you some space to experiment with.

Some potentially useful modules:

  • Feeds to pull in data externally and Feeds Tamper to tweak it (pre-process)
  • JSON Field or JSONB Field to store external JSON data as JSON, alleviating the need to parse it right away (limited to databases that support JSON)
  • JSON:API Explorer, PHPMyAdmin for JSON:API
  • JSON:API Extras-- despite the name, this module is probably essential. It lets you rename JSON:API resources instead of using the default core names and it also lets you easily disable access to groups of entities (which you want, because exposing everything like JSON:API does by default is probably too much)
  • JSON:API Include to merge (pull in entity references automatically)
  • JSON:API Resources to define your own endpoints to do whatever you want (for all custom processing)
2
  • thanks for these directions, it helps. I realize this is probably a more opinioned discussion rather than a question, it might be closed. But your answer is helpful. thanks!
    – gilzero
    Sep 22, 2021 at 9:41
  • re: "If you are pulling from an external source, and not using entities, why even use Drupal at all?" Because I still want to utilize D9 out of box very powerful subsystems like router, security, seo, caching, theming, etc.
    – gilzero
    Sep 22, 2021 at 9:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.