npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@wpe-tkpd/apollo-progressive-fragment-matcher

v1.1.0-alpha.1

Published

A smart alternative to the introspection fragment matcher.

Downloads

17

Readme

Apollo Progressive Fragment Matcher (Forked)

This fork does 2 things:

  1. Adds a way to add initialPossibleTypesMap for SSR support. (7bc355)
  2. Import visit from graphql/language/visitors so it doesn't bring the whole unneeded thing. Inspired by babel-plugin-modular-graphql (5092aa)
    • Before:

      image

    • After:

      image

---- End of forked information ----

Version License bundlephobia Build Status codecov

A smart alternative to the introspection fragment matcher.


Motivation

Error: You are using the simple (heuristic) fragment matcher... :scream:

GraphQL APIs are evolving, and usage of Unions and Interfaces are much more common now then they use to be. Some time ago this kind of feature was considered advanced; I don't think that's true today. The GraphQL clients all need a way to distinguish data between two or more fragments that rely on inherited types (unions & interfaces), what I call the Human and Droid problem.

Apollo has long solved this issue by providing the IntrospectionFragmentMatcher. This fragment matcher, though, requires, that you provide a introspectionQueryResultData, which is your API's introspection query result. Introspection queries result can be huge.

What if we could avoid pre-fetching the introspection? What if we could introspect as we go?

Welcome ProgressiveFragmentMatcher.

Usage

Installation

npm i apollo-progressive-fragment-matcher apollo-link graphql invariant

ProgressiveFragmentMatcher

The Progressive Fragment Matcher has two strategies for matching fragment types:

This strategy transforms the outgoing queries to request introspection information on the requesting types. It does cache the results, meaning if on a second query you use the same fragment type, it won't introspect again (nor transform the query, which can be expensive).

This strategy is much like what ApolloClient normally does to inject __typename fields.

Good:

  • Easy to install;
  • Drop-in replacement for IntrospectionFragmentMatcher;

Bad:

  • Query transforms are expensive;
Usage
import ApolloClient from 'apollo-client'
import { InMemoryCache } from 'apollo-cache-inmemory'
import { from } from 'apollo-link'
import { HttpLink } from 'apollo-link-http'
import { ProgressiveFragmentMatcher } from 'apollo-progressive-fragment-matcher'

const fragmentMatcher = new ProgressiveFragmentMatcher()

const client = new ApolloClient({
  cache: new InMemoryCache({ fragmentMatcher }),
  link: from([fragmentMatcher.link(), new HttpLink()]),
})

This strategy is very performatic on the client side, because it does not depend on query transformation. What this strategy does is send the server an extension flag ({ possibleTypes: true }) to request the server to send possible types of any returned type in the query - regardless of the fragments requested.

This strategy requires you have control of the server, and currently only works with ApolloServer custom extensions implementation.

Good:

  • Fast on client;
  • Persisted queries supported;

Bad:

  • Requires server control;
Usage

client:

import ApolloClient from 'apollo-client'
import { InMemoryCache } from 'apollo-cache-inmemory'
import { from } from 'apollo-link'
import { HttpLink } from 'apollo-link-http'
import { ProgressiveFragmentMatcher } from 'apollo-progressive-fragment-matcher'

const fragmentMatcher = new ProgressiveFragmentMatcher({
  strategy: 'extension',
})

const client = new ApolloClient({
  cache: new InMemoryCache({ fragmentMatcher }),
  link: from([fragmentMatcher.link(), new HttpLink()]),
})

server

import { ApolloServer } from 'apollo-server'
import { PossibleTypesExtension } from 'apollo-progressive-fragment-matcher'

const server = new ApolloServer({
  typeDefs,
  resolvers,
  extensions: [() => new PossibleTypesExtension()],
})

server.listen() // start server

Due to a limitation on ApolloClient's customizing capabilities, both strategies require you append a link created from the fragment matcher instance.

Warning :warning:

Although well tested, this project is in an experimental stage.

About persisted queries

I have not yet stressed it out on complicating circustances such as persistend queries. I've marked the extension strategy as supporting persisted queries due to the nature of this operation - it relies on no query transformation, therefore should be compatible with persisted queries, but no test prove this concept yet.