wilkerlucio / pathom3-graphql Goto Github PK

View Code? Open in Web Editor NEW

17.0 2.0 3.0 121 KB

GraphQL Integration for Pathom 3

License: MIT License

JavaScript 1.08% Clojure 97.73% Shell 1.19%

pathom3-graphql's Introduction

Pathom 3 GraphQL

This library provides an implementation to integrate GraphQL services in Pathom environments.

Example setup

(ns com.wsscode.pathom3.graphql.test.swapi
  (:require
    [clojure.data.json :as json]
    [com.wsscode.misc.coll :as coll]
    [com.wsscode.pathom3.connect.built-in.resolvers :as pbir]
    [com.wsscode.pathom3.connect.indexes :as pci]
    [com.wsscode.pathom3.graphql :as p.gql]
    [com.wsscode.pathom3.interface.eql :as p.eql]
    [org.httpkit.client :as http]))

(defn request [_ query]
  (-> @(http/request
         {:url     "https://swapi-graphql.netlify.app/.netlify/functions/index"
          :method  :post
          :headers {"Content-Type" "application/json"
                    "Accept"       "*/*"}
          :body    (json/write-str {:query query})})
      :body
      json/read-str))

(def env
  (-> {}
      (p.gql/connect-graphql
        {::p.gql/namespace "swapi"}
        request)))

(p.eql/process
  env
  [{:swapi.Root/allFilms
    [{:swapi.FilmsConnection/films
      [:swapi.Film/director
       :swapi.Film/title]}]}])

(p.eql/process
  env
  {:swapi.Film/id "ZmlsbXM6Mg=="}
  [:swapi.Film/title])

Check the demos folder for more example setups.

pathom3-graphql's People

Contributors

Stargazers

Watchers

Forkers

cjsauer sheluchin tyba-energy

pathom3-graphql's Issues

Support queries using ident-map

Nested resolver inputs misbehave beyond a certain level

I'm running into something a little weird with GitHub GraphQL.

This query works fine:

(p/let [result (p.eql/process github-gql-env
                {:github.Organization/login "fulcrologic"}
                ['({:github.Organization/repositories
                    [{:github.RepositoryConnection/edges
                      [{:github.RepositoryEdge/node
                        [:github.Repository/name
                         :github.Repository/nameWithOwner
                         {:github.Repository/owner [:github.RepositoryOwner/id]}]}]}]}
                   {:first 1})])]
  (doto result tap>))

Returning:

#:github.Organization
{:repositories
 #:github.RepositoryConnection
 {:edges
  [#:github.RepositoryEdge
   {:node
    #:github.Repository
    {:name "fulcro",
     :nameWithOwner "fulcrologic/fulcro",
     :owner #:github.RepositoryOwner
            {:id
             "MDEyOk9yZ2FuaXphdGlvbjMwMTAyODIz"}}}]}}

But when I try this nearly identical query through a resolver, I get an error:

(pco/defresolver shortcut
 [{{edges :github.RepositoryConnection/edges} :github.Organization/repositories
   :as input}]
 {::pco/input [{'(:github.Organization/repositories {:first 1})
                [{:github.RepositoryConnection/edges
                  [{:github.RepositoryEdge/node
                    [:github.Repository/id
                     :github.Repository/name
                     :github.Repository/nameWithOwner
                     {:github.Repository/owner [:github.RepositoryOwner/id]}]}]}]}]
  ::pco/output [{:github.Organization/all-repos
                 [:github.Repository/id
                  :github.Repository/name]}]}
 {:github.Organization/all-repos (mapv :github.RepositoryEdge/node edges)})

"Pathom can't find a path for the following elements in the query: [:github.RepositoryOwner/id] at path [:github.Organization/repositories]"

If I remove {:github.Repository/owner [:github.RepositoryOwner/id]} from the resolver input, it works. It seems like joins on other fields in the same location don't work either. For example, {:github.Repository/issues [:github.IssueConnection/totalCount]}.

Any idea what I'm doing wrong here?

Index schema to Pathom 3 indexes

This task will use the new idea of auxiliary dynamic resolvers from Pathom 3 to encode the schema.

In the previous version, we had to manually write each index, which makes it a challenge to ensure they are consistent. The new method uses extra resolvers instead, which makes indexing more consistent and easier to implement.

Error handling

Propagate back errors from GraphQL to Pathom

Support for GraphQL field aliases

Pathom doesn't currently support GraphQL field aliases. Adding support for them would enable batching some queries into a single request, like this:

{
  x: search(query: "torvalds", type: USER, first: 1) {
    edges {
      node {
        ... on User {
          createdAt
        }
      }
    }
  }
  y: search(query: "richhickey", type: USER, first: 1) {
    edges {
      node {
        ... on User {
          createdAt
        }
      }
    }
  }
}

Otherwise, omitting the aliases (x: and y:), GitHub returns an error:

{
  "errors": [
    {
      "path": [],
      "extensions": {
        "code": "fieldConflict",
        "fieldName": "search",
        "conflicts": "{query:\"\\\"torvalds\\\"\",type:\"USER\",first:\"1\"} or {query:\"\\\"richhickey\\\"\",type:\"USER\",first:\"1\"}"
      },
      "locations": [
        {
          "line": 7,
          "column": 3
        },
        {
          "line": 16,
          "column": 3
        }
      ],
      "message": "Field 'search' has an argument conflict: {query:\"\\\"torvalds\\\"\",type:\"USER\",first:\"1\"} or {query:\"\\\"richhickey\\\"\",type:\"USER\",first:\"1\"}?"
    }
  ]
}

I'm just creating this issue to document that there is no current support for this and to explain how it could be useful.

[{:github.Query/viewer
  [{(:github.User/repositories {:first 1})
    [{:github.RepositoryConnection/edges
      [{:github.RepositoryEdge/node
        [:github.Repository/name
         {:github.Repository/issues
          [:github.IssueConnection/totalCount]}]}]}]}]}]

This currently generates the following GraphQL query:

query {
  __typename
  ... on Query {
    viewer {
      __typename
      ... on User {
        repositories(first: 1) {
          __typename
          ... on RepositoryConnection {
            edges {
              __typename
              ... on RepositoryEdge {
                node {
                  __typename
                  ... on Repository {
                    name
                    issues {
                      __typename
                      ... on IssueConnection {
                        totalCount
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Fix idea: make the GraphQL generation smarter and avoid using ... of Type when requesting attributes directly from a type (instead of an interface).