JSON:API on its own gets you decoupled entities: fetch a node, fetch a set of IDs, done. It doesn’t get you the filtering, sorting and pagination that most real content listings actually need – a list of articles by tag, a paginated product catalogue, an events calendar with a date filter. You either reimplement that logic on the frontend, or Drupal ships a hand-written custom resource for every list on the site. That gap is the same regardless of what’s rendering on the other end, React and Next.js, Vue and Nuxt, or anything else that can call an API.
JSON:API Views closes it: whatever a View can already do, a decoupled frontend can ask for over JSON:API, using the access checks and query logic the view already has, no separate endpoint to write or maintain. It’s also, not coincidentally, why I still maintain the module at all: it’s the backend half of DruxtViews, the piece that makes Views work in Druxt, my own Nuxt-based decoupled Drupal framework.
8.x-1.2 lands six fixes, five of which already had a patch sitting in the queue: route building that’s dramatically faster on sites with a lot of exposed views, a preview URL that finally matches what an exposed filter is actually configured to accept, a caching fix so front-end caches actually invalidate, a routing crash tied to numeric bundle names, and a reworked fix for an OpenAPI export crash. Just fixes, no updating required.
JSON:API Views isn’t mine originally. pixelwhip built the module and shipped its first releases; I took over maintenance after that, and 8.x-1.2 is the first release I’ve cut on the 1.x line. Thanks to pixelwhip for building the thing in the first place.
