Project status

[vicary]

This project is a great idea and I can imagine the fun coding this way.

I have been waiting for mutations and subscriptions to be ready so I can start a project with it.

Have the authors thought of opening a discord server or something else, so people can help out when more of us get to know more about the directions and design concepts?

[samdenty]

I was experimenting on a compiler (mentioned in the readme / scattered across some todos). At a high level it was meant to fix the request waterfall issues, add mutations and allow for an SSR experience similar to React server components.

The compiler implements a partially spec-compliant JS engine. And is able to scan basic JS, as you can see from the tests:

it("can track accessors with variables", () => {
  const files = {
    a: `
      export default u => {
        u.avatarUrl({ size: 100 })
      }
    `,
  };

  expect(scan(files, "props")).toMatchInlineSnapshot(`
    FunctionAnalysis (
      0 -> {
        avatarUrl({
          "size": 100
        }) {}
      }
    )
  `);
});

It becomes way harder keeping track of these GraphQL accessors, inside dynamic react components though. Essentially requiring a full-blown spec compliant JS-engine. https://github.com/facebook/prepack/tree/master/src proves it's possible...

But the biggest challenge... hooks like useState() / useContext() aren't statically analysable, so it'd require a custom "mapping" syntax on how arguments passed to these functions are consumed / returned (summarised in the readme):

gqless's compiler is going to use a combination of different methods to make your app statically analyzable (without new syntax):

• Utilize the Typescript Compiler API - track Generics, auto-infer dynamic usage
• @types/.d.ts alternative - allows people to define how to statically analzye a third-party library
• Manual tagging - allows end-developers to manually define in-code how the static analysis works, using simple declaratives

I experimented around with using ts-morph to be able to "auto-infer" these mappings from your apps type definitions. But the typescript compiler is just waaaaay too slow and isn't designed in a way in which it can be optimised.

[vicary]

Thanks for sharing more of your thought process.

There are existing options backed by giants, I think the niche here is always the fun of coding we shared from your pitching in the landing page.

Looking at the sheer size of the scope laid out in #43, do we have incremental milestones, e.g. a JIT release with mutation & subscription support?

/cc @PabloSzx

[MaxmaxmaximusAWS]

hurray, revolution

[MaxmaxmaximusAWS]

but you will never surpass gqless in popularity, your only chance is to become so popular that he AGREES to work with you: 3

[MaxmaxmaximusAWS]

[PabloSzx]

/cc @vicary

Hi everyone, the new gqless refactor I've been working in since a couple months is completely usable right now (with possible incoming breaking changes, of course), and one of the main core stuff that has changed internally in how it works is that it doesn't make the proxies of the entire schema on generation time, and the proxies are not stateful as the previous/current version, instead, the new gqless has a lightweight json object of the schema and it makes the proxies on runtime, and the state of the everything is saved inside the client instance instead of module level, caching everything it can to improve performance of course. This core change has improved the memory usage greatly, allowed new usage features, and fixed a very hard problem to solve in the first version, which was recursive/deep types/queries (#53).

It's important to note that mutations are officially supported, and after the beta release, supporting subscriptions is completely feasible and planned to be implemented

As I said, the refactor is currently usable, but it has some issues to be fixed first in order to actually publish a official beta, and there isn't any docs other than the types, which have been commented for the most part and trying to make all the names as intuitive as possible.

If you want to help this project at this early state, playing with it would be extremely appreciated, for now they have been published as it follows:

• https://www.npmjs.com/package/@dish/gqless
• https://www.npmjs.com/package/@dish/gqless-cli
• https://www.npmjs.com/package/@dish/gqless-react
• https://www.npmjs.com/package/@dish/gqless-logger

And very important to note, inside the new_gqless repo there are 2 examples, in which the project is being tested and developed, and they are the official way of learning how to use it in the meantime, since there isn't any official docs yet (and the old gqless docs don't apply at all, since there are a lot of usage changes/improvements):

• https://github.com/PabloSzx/new_gqless/tree/master/examples/mercurius
• https://github.com/PabloSzx/new_gqless/tree/master/packages/gqless-react/example

And please, if you are willing to help debug/playing with it, please join the discord https://discord.gg/2gy8ZQxnGk, thank you

[vicary]

Took a quick glance on the source codes. If I'm reading it correctly, there aren't implementations for subscriptions yet.

I think it's a good time to bring this up at this early stage, my projects tend to resides in AWS AppSync and their subscription works a bit different from what Apollo Server does.

I am planning to port aws-appsync-subscription-link here given the chance.

[PabloSzx]

My idea is to implement graphql-ws, I know about AppSync, but I haven't used it personally, could you confirm it works with graphql-ws? @vicary

[vicary]

Yes, with some specific handshakes before you can acquire the dynamic endpoint for each instance of subscriptions.

You may see a brief description of how to do the handshake with exactly graphql-ws in the official docs here https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html

[PabloSzx]

Then I will make the subscriptions implementation using graphql-ws and allowing to give an async function that returns an string of the subscription endpoint, but it's important to keep in mind that for testing purposes I am using Mercurius as API server, which follows the traditional GraphQL over WebSocket Protocol

[vicary]

When comparing all three libraries, apollographql and appsync uses the start message type for subscriptions, while graphql-ws uses subscribe.

The example included in graphql-ws README requires a custom middleware to be applied into Apollo Server to work.

We intentionally leave implementation details empty. - Facebook

As far as my research goes, the spec does not mention how WebSocket messages should be structured, so these two implementations are largely community driven and is followed in a convention manner.

Mercurius explicitly said they follows the Apollo version of the protocol.

This is purely observational and I haven't done any tests so please take this with a grain of salt, but definitely something to keep in mind if graphql-ws is the dependent planned.

[PabloSzx]

Hi everyone, We have just released the new version v2 of gqless, please visit https://gqless.com for instructions, it now has Mutation support, Subscriptions support, Normalization and much more, feel free to enter our discord server, to open an issue or a discussion about anything related, thanks you for your contribution! 🎉