index.md

Core concepts

Remote Data Blocks allows you to integrate remote data into posts, pages, patterns, or anywhere else on your site where you use the block editor. This guide will help you understand the core concepts of the plugin and how they work.

What is a remote data block?

A remote data block is a custom block that fetches, caches, and displays remote data from an external data source. For example, using this plugin, you can create a remote data block named "Shopify Product" that fetches a product from your Shopify store and displays the product's name, description, price, and image. Or, you might have a remote data block named "Conference event" that displays rows from an Airtable and displays the event's name, location, and type.

Remote data blocks are container blocks that provide remote data to its inner blocks via the block bindings API or inline bindings. You retain complete control over the layout, design, and content of a remote data block and its inner blocks. You can leverage patterns to enable consistent styling and customize the block's appearance using the block editor's style settings, theme.json, or custom stylesheets. See the example child theme for more details.

Remote data blocks are created and registered by this plugin and don't require custom block development. In addition, helper blocks are also provided to perform specific tasks.

Caching

This plugin offers a caching layer for optimal performance. It will be used if your WordPress environment configures a persistent object cache. Otherwise, the plugin will utilize in-memory (per-page-load) caching. Deploying to production without a persistent object cache is not recommended.

The default TTL for all cache objects is 5 minutes, but it can be configured per query or request. Error responses are cached for 30 seconds to avoid overwhelming the remote data source under error conditions. Multiple requests for the same data within a single page load will be deduplicated even if the requests are not cacheable.

Technical concepts

If you want to understand the internals of Remote Data Blocks so that you can write code to extend its functionality, head over to the extending guide.

Supported use cases

Like WordPress, Remote Data Blocks is flexible. It can be used to enable advanced integrations with external data.

Below, you'll find specific use cases where Remote Data Blocks shines. We are working to expand these use cases, but before you start, consider if Remote Data Blocks is the right tool for the job.

Remote Data Blocks is a good fit if:

• Your remote data represents entities with a consistent schema.
  • Example: Product data representing items of clothing with defined attributes like “Name,” “Price,” “Color,” “Size,” etc.
• You want humans to select specific entities for display within the block editor.
  • Example: Select and display an item of clothing within a marketing post.
• You want to display arbitrary remote data based on a URL parameter and are willing to write a small amount of code.
  • Example: Create a page and rewrite rule for /products/{product_id}/ and configure a Remote Data Block on that page to display the referenced product.
• Your presentation of remote data aligns with the capabilities of block bindings.
  • Example: Display an item of clothing using a core paragraph, heading, image, and button blocks.
• Your data is denormalized.
  • Example: A row from a Google Sheet with no references to external entities.

Remote Data Blocks may not be a good fit if:

• Your remote data is schema-less, or the schema changes over time.
  • Queries for remote data must define a schema for their return data. Schema changes result in broken blocks.
• You want to display remote data outside the context of the block editor.
  • Block bindings are only available in block content—posts, pages, or full-site editing. Using our plugin to define and resolve remote data may still provide some benefit (e.g., caching) but could require significant custom PHP code.
• Your data is normalized (and cannot be denormalized automatically by your API).
  • Some APIs can denormalize data by automatically “inflating” referenced records for you. For example, data representing an item of clothing might reference a color by ID instead of a renderable string like “forest green.” If your API does not denormalize this relationship automatically, you will need to write custom code to perform additional queries and stitch the responses together.
  • This can lead to a large number of API requests that your API may not tolerate. Airtable’s API, for example, imposes a rate limit of five requests per second, making multiple calls impractical.
• You have multiple remote data sources that require interaction with each other. Or, you want to implement a complex content architecture using Remote Data Blocks instead of leveraging WordPress custom post types and/or taxonomies.
  • These two challenges are directly related to the issues with normalized data. If you have data sources that relate to one another, you must write custom code to query missing data and stitch them together.
  • Judging complexity is difficult, but implementing large applications using Remote Data Blocks is not advisable.
• Your use case requires complex filtering of remote data or your API uses non-standard pagination.
  • Our UI components for filtering and pagination are still under development.

Over time, Remote Data Blocks will grow and improve and these guidelines will change.