8 ms·

How is this different from Pothos, type-graphql or typegql? This announcement post doesn’t really have much to show for. I’d expect some comparison with other p

• pixelready 3y ago
  Another one I saw recently that looks really promising in this vein is gql.tada, which provides some very nice LSP support. Anything in the TS space endorsed by Matt Pocock immediately gets my attention!
  • captbaritone 3y ago
    gql.tada is indeed very impressive and I think shares many of the same values as Grats. That said, I believe that today they only support the client path. Editor features and type generation for queries/mutations and fragments, although they do have interest in having a server story as well: https://github.com/0no-co/gql.tada/issues/10 https://github.com/0no-co/gql.tada/issues/10
    • pixelready 3y ago
      Thanks for clarifying and may I say it warms my heart to see the spirit of open, enthusiastic cross-project collaboration represented in that issue thread.
• captbaritone 3y ago
  Grats author here. It's spiritually similar to type-graphql or typegql, except that it's able to see the TypeSCript types as well as the class/method names. So, there's less duplication, less overhead, and a less confusing API (specifying argument types and return in type-graphql for example is pretty confusing. Unlike Pothos, this implementation-first approach is able to leverage simple type script names and types, whereas Pothos requires you to explicitly define all the names and types using their builder-pattern-for-graphql-SDL API. More here on why Grats does not use decorators like type-graphql: https://grats.capt.dev/docs/faq/why-use-comments/ https://grats.capt.dev/docs/faq/why-use-comments/