v3 roadmap

[acro5piano]

I think typed-graphqlify could do more than the current type alias.

While I was working on Apollo and Apollo Codegen instead of typed-graphqlify, I feel it inconvenient in the following points:

• Importing a lot of code from __generated__ directories
• Multiple schemas, in terms of microservices
• No serializer concept

And typed-graphqlify lacks the following features:

• Params are not type-safed (How to get params type？ #52)
• More elegant syntax (Typing array elements #67, enum like array, close #74, #67 #68)
• Validate schema according to the actual schema

And I would like to add a feature, requesting and type inference from query.

Currently we have to write

import { query, types } from 'typed-graphqlify'

const query = {
  users: [{
    id: types.number,
    name: types.string,
  }]
}

export type ReturnTypeOfQuery = typeof query

export const usersQuery = query('GetUsers', query)

// in other file
import { usersQuery, ReturnTypeOfQuery } from './path/to/query'

const res: ReturnTypeOfQuery = (await apolloClient.query(usersQuery)).data

This is bothering, so if we can request like this:

import graphql from 'typed-graphqlify'

graphql.init({ baseUri: '/graphql' })

const res = await graphql({
  query: {
    users: [{
      id: types.number,
      name: types.string,
    }]
  },
  variables: {
    email: '@gmai.com',
  },
})

// and `typeof res` is like this:
interface res {
  users: {
    id: number,
    name: string
  }[],
}

This feature looks too much for this library, so I'm thinking splitting into other library though...

[acro5piano]

And actually I don't like the syntax of id: types.number as it is different from the original GQL syntax.

I want to do like eventually:

const query = gql`
  query GetUsers {
    user {
      id: ${types.number}
      name: ${types.string}
    }
  }
`

However, the structure is apparently impossible without codegen. So I'm thinking what is the least verbose syntax.

[albertcito]

Hello @acro5piano I made a small library based in your library. Maybe it's a good idea to add these features to your library (or maybe not XD)

https://github.com/albertcito/typed-graphql-class

[acro5piano]

Hi @albertcito !
We are still on the way to find the best combination GraphQL + TypeScript. Good luck!!

[acro5piano]

Considering these hacks to omit params:

expect(
  mutation("BulkInsertUsers")({ $objects: "[user_insert_input!]!" })(q => {
    q("insert_users")({ objects: "$objects" })({
      returning: {
        id: q.types.number
      }
    });
  })
).toEqual(gql`
  mutation BulkInsertUsers($objects: [user_insert_input!]!) {
    insert_users(objects: $objects) {
      returning {
        id
      }
    }
  }
`);

expect(
  mutation("BulkInsertUsers")({
    insert_users: {
      returning: {
        id: q.types.number
      }
    }
  })
).toEqual(gql`
  mutation BulkInsertUsers($objects: [user_insert_input!]!) {
    insert_users(objects: $objects) {
      returning {
        id
      }
    }
  }
`);

[bkniffler]

typed-graphqlify looks very promising. I especially like that it doesn't try to be a client, but only a transformer for queries/mutation.

In terms of querying API, I really liked this one: https://www.npmjs.com/package/graphql-typed-client

As long as there is no code generation involved, it will be hard to allow for proper typing of input params and typed-graphqlify will be just half useful. Looking at projects like Hasura, input params can get very complex themselves and I'd like them to be type safe too.

[acro5piano]

@bkniffler
Thank you for your opinion.
I agree with you. Proper typing and validation could be good features, whereas client library is too much. Client library should be a separated library.

[fwh1990]

https://github.com/redux-model/graphql

I'm watching your idea, and feel free to watch mine.

import { types, graphql } from '@redux-model/graphql';

const tpl = graphql.query({
  getUser: {
    id: types.number,                 // number
    name: types.string,               // string
    bankAccount: {                    // object
      id: types.number,
      branch: types.string.number,    // string | number
    },
    logs: types.fn(['page_Int', 'size_Int'], types.array({
      id: types.number,
      title: types.null.undefined.string,  // string | undefined | null
    })),
  }
});

type Response = typeof tpl.type;

const { query, variables } = tpl({
  page_Int: 1,
  size_Int: 10,
});

console.log(query);
// query GetUser ($page: Int, $size: Int) {
//   getUser {
//     id
//     name
//     bankAccount {
//       id
//       branch
//     }
//     logs (page: $page, size: $size) {
//       id
//       title
//     }
//   }
// }

console.log(variables);
// { page: 1, size: 10 }

It's es5 based. No Symbol and Map

[fwh1990]

By the way, I am using redux model which is base on redux. And I don't like apollo client.

[acro5piano]

@fwh1990
Thanks for your opinion. Redux Model looks interesting.

[fwh1990]

@fwh1990
Thanks for your opinion. Redux Model looks interesting.

Yep, its goal is saving people's life. And it will let people know that TS can be coding faster, not slower.

[acro5piano]

I have been missing this syntax. We don't have to use params if we embed it into key.

  mutation('BulkInsertUsers($objects: [user_insert_input!]!)', {
    'insert_users(objects: $objects)': {
      returning: {
        id: types.number
      }
    }
  })

  mutation BulkInsertUsers($objects: [user_insert_input!]!) {
    insert_users(objects: $objects) {
      returning {
        id
      }
    }
  }

This could be enabled by template literal types TS 4.1.

[acro5piano]

v3 is released.

#72