5 ms·

(I work on the team) I wouldn't say that TypeSpec is like GraphQL, so it would be hard for TypeSpec to become that on its own. GraphQL has a lot of opinions th

(I work on the team) I wouldn't say that TypeSpec is like GraphQL, so it would be hard for TypeSpec to become that on its own. GraphQL has a lot of opinions that are required in order to build a concrete application (protocols, error handling, query semantics, etc.), whereas TypeSpec at its core is just an unopinionated DSL for describing APIs. Bindings for particular protocols are added via libraries, and a GraphQL library is something we have long considered. So in short, if Microsoft invented a set of opinions that solved similar scenarios to GraphQL, it might use TypeSpec as the API description language in that context, but it wouldn't be fair to equate those opinions with TypeSpec itself.

nfw2 2y ago
The graphql spec does include a DSL to describe the api though, so this is similar to that specific piece. The DSL powers a lot of what people like about grapqhql, like auto-generating a client sdk with type safety. This library does seem to cover a subset of the graphql benefits that aren’t baked into REST by default.
- bterlson 2y ago
  Yup, similar to that specific piece, and I definitely agree that GraphQL's DSL shows how much the DX of the description language itself matters, and how codegen is a productivity multiplier. I think gRPC also demonstrates this. You can think of TypeSpec as an attempt to bring these benefits to any protocol, schema vocabulary, or programming language.
sa-code 2y ago
Would you say it's an alternative to Open API?
- bterlson 2y ago
  I think it can be, but it can also be used with OpenAPI to great effect as well. We're not trying to replace OpenAPI, OpenAPI is great in many ways and is useful for many people. In general we believe strongly in being interoperable with the existing API description ecosystem.
la64710 2y ago
It’s probably more like smithy?
- catlifeonmars 2y ago
  That’s what I thought when I saw this: smithy without the need to bring Gradle into your project
  - mtdowling 2y ago
    You don’t have to use Gradle with Smithy. You can also use the self-contained CLI which doesn’t use Gradle: https://smithy.io/2.0/guides/smithy-cli/index.html https://smithy.io/2.0/guides/smithy-cli/index.html
    - catlifeonmars 2y ago
      This gives me an excuse to revisit smithy. Curious if editor support is still poor in VSCode. Last time I cracked it open, I found that (1) there was no AST introspection and (2) existing language support tooling was lacking modern features (click to definition, autocomplete of ambient/imported smithy types). (2) made me attempt to write a language server and I stopped when I realized there was no easy way to hook into the parser.

nfw2 2y ago

The graphql spec does include a DSL to describe the api though, so this is similar to that specific piece. The DSL powers a lot of what people like about grapqhql, like auto-generating a client sdk with type safety. This library does seem to cover a subset of the graphql benefits that aren’t baked into REST by default.

bterlson 2y ago
Yup, similar to that specific piece, and I definitely agree that GraphQL's DSL shows how much the DX of the description language itself matters, and how codegen is a productivity multiplier. I think gRPC also demonstrates this. You can think of TypeSpec as an attempt to bring these benefits to any protocol, schema vocabulary, or programming language.

sa-code 2y ago

Would you say it's an alternative to Open API?

bterlson 2y ago
I think it can be, but it can also be used with OpenAPI to great effect as well. We're not trying to replace OpenAPI, OpenAPI is great in many ways and is useful for many people. In general we believe strongly in being interoperable with the existing API description ecosystem.

la64710 2y ago

It’s probably more like smithy?

catlifeonmars 2y ago
That’s what I thought when I saw this: smithy without the need to bring Gradle into your project
- mtdowling 2y ago
  You don’t have to use Gradle with Smithy. You can also use the self-contained CLI which doesn’t use Gradle: https://smithy.io/2.0/guides/smithy-cli/index.html https://smithy.io/2.0/guides/smithy-cli/index.html
  - catlifeonmars 2y ago
    This gives me an excuse to revisit smithy. Curious if editor support is still poor in VSCode. Last time I cracked it open, I found that (1) there was no AST introspection and (2) existing language support tooling was lacking modern features (click to definition, autocomplete of ambient/imported smithy types). (2) made me attempt to write a language server and I stopped when I realized there was no easy way to hook into the parser.