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

@barejs/graphql-client

v6.0.0

Published

GraphQL clients for the Python bareASGI web toolkit

Downloads

34

Readme

@barejs/graphql-client

This is a collection of GraphQL clients which support queries, mutations and subscriptions.

It specifically targets the bareASGI GraphQL module from the bareASGI python web framework. This framework provides two novel features.

Because the ReadableStream api is a feature of fetch, it can provide headers to the server, allowing CORS and authentication to be maintained. This is a relatively new feature; in particular the pipeThrough and pipeTo methods (which are used by the client) are still marked as "experimental". At the time of writing this is supported by most common browsers with the notable exception of FireFox (and Internet Explorer, obviously).

Usage

Queries and mutations

The graphqlFetchClient function is a thin wrapper around fetch. It can be used for queries and mutations.

import { graphqlFetchClient } from '@barejs/graphql-client'

const url = 'http://www.example.com/graphql'
const init {}

const query = 'query { someQuery { someField someOtherField } }'
const variables = null
const operationName = null

graphqlFetchClient(
  url,
  init,
  query,
  variables,
  operationName,
  error => console.error(error),
  data => console.log(data))

Subscriptions

There are three mechanisms provided for subscriptions:

  • Over WebSockets (widely supported),
  • Using server sent events (only supported by bareASGI)
  • Using readable streams (only supported by bareASGI)

WebSockets

This follows the Apollo websocket protocol, which appears to be the most widely used and compatible transport. The main issue with the websocket transport is that authentication is must be implemented separately, as headers and cookie are not available.

import { graphqlWsSubscriber } from '@barejs/graphql-client'

const url = 'http://www.example.com/sse-subscription'

const query = 'subscription { someSubscription { someField someOtherField } }'
const variables = null
const operationName = null

graphqlWsSubscriber(
  url,
  query,
  variables,
  operationName,
  error => console.error(error),
  data => console.log(data))

The maximum number of web sockets is browser dependent, and is in the order of 30 per host, and 256 in total.

Server Sent Events

This sends the subscription as JSON messages over and EventSource. This is a widely supported protocol. Under the hood this is implemented as a streaming GET. This means things like headers are valid, which allows for consistent authentication.

import { graphqlEventSourceSubscriber } from '@barejs/graphql-client'

const url = 'http://www.example.com/sse-subscription'
init = {
  withCredentials: true // This controls CORS behaviour.
}

const query = 'subscription { someSubscription { someField someOtherField } }'
const variables = null
const operationName = null

graphqlEventSourceSubscriber(
  url,
  init,
  query,
  variables,
  operationName,
  error => console.error(error),
  data => console.log(data))

Under http/1.1 most browsers allow up to 6 concurrent connections per session. This is not an issue with http/2 as all http traffic to a host is multiplexed over a single connection.

Readable Streams

Readable streams are essentially a long running fetch. This means they have similar characteristics to server sent events, without the slightly arcane protocol.

The key advantage to this approach is that it works for query and mutation as well as subscription. This means everything works from a single client, which is attractive.

import { graphqlStreamClient } from '@barejs/graphql-client'

const url = 'http://www.example.com/sse-subscription'
init = {} // Anything the fetch takes.

const query = 'subscription { someSubscription { someField someOtherField } }'
const variables = null
const operationName = null

graphqlStreamClient(
  url,
  init,
  query,
  variables,
  operationName,
  error => console.error(error),
  data => console.log(data))

As with server sent events the 6 connection limitation with http/1.1 is an issue.

Clients

By using one of the three "client" functions, queries, mutations and subscriptions can be handled transparently. For web sockets and server sent events this is achieved by the server responding to a subscription with the location of the web socket or SSE endpoint. For readable streams, no redirection is necessary.

The graphqlWsClient can be used for queries, mutations, or subscriptions when using the bareASGI-graphql-next server server, using web sockets as the underlying subscription transport.

import { graphqlWsClient } from '@barejs/graphql-client'

const url = 'http://www.example.com/graphql'
const init = {}

// This could be a query, mutation or subscription.
const query = 'subscription { someSubscription { someField someOtherField } }'
const variables = null
const operationName = null

const unsubscribe = graphqlWsClient(
  url,
  init,
  query,
  variables,
  operationName,
  data => console.log(data),
  error => console.log(error),
  () => console.log('complete'))

// Later ...
unsubscribe()

There are three client functions:

  • graphqlWsClient
  • graphqlEventSourceClient
  • graphqlStreamClient

They take the same arguments as graphqlWsClient.

graphqlWsClient

The graphqlWsClient function uses a WebSocket as the subscription transport. This implements the appolo protocol which is supported by all major GraphQL web servers.

graphqlEventSourceClient

The graphqlEventSourceClient function uses an EventSource as the subscription transport. It is more efficient than the WebSocket transport, but is only supported by the bareASGI-graphql-next server server. The underlying EventSource transport requires the subscription query and parameters to be passed in the url as a query string which can be problematic for large queries.

graphqlStreamClient

The graphqlStreamClient uses a streaming fetch with ReadableStreams as the subscription transport. This is the most efficient transport, but is only supported by the bareASGI-graphql-next server server. The request method is POST so large queries are not a problem.

Installation

npm install @barejs/graphql-client