Will it translate to yaml for toolchains that want that?
I'd be delighted to have a high-level IDL that gave the same sort of thing that CORBA IDL gave us 25 years ago -- schema and stub generation for multiple languages.
TypeSpec: A new language for API-centric development
21–30 of 121 posts
Re: TypeSpec: A new language for API-centric development
#22Bespoke languages are a hard sell and incur significant extra effort on the team building this. 1. People don't want to learn bespoke languages. 2. You have to build all the ecosystem tools for a language (compiler, docs, language-server, IDE integrations, dependency management) Similar endeavors are WaspLang and DarkLang, which I have yet to see in the wild or (meaningfully) on HN. Better to use an existing language…
It's this or writing openapi ymls... Even for people who know yml picking this up to define and write basic openapi definitions is much simpler than writing an openapi doc from hand, which is really painful
Re: TypeSpec: A new language for API-centric development
#23What is wrong with protobufs and grpc?
Both of them. Both of them are wrong.
Re: TypeSpec: A new language for API-centric development
#24Will it translate to yaml for toolchains that want that? I'd be delighted to have a high-level IDL that gave the same sort of thing that CORBA IDL gave us 25 years ago -- schema and stub generation for multiple languages.
The OpenAPI and Json Schema emitters can produce yaml.
Re: TypeSpec: A new language for API-centric development
#25Earlier quoted context omitted.
Schemas that support multiple languages are useful when you actually use more than one language. This is more common in large organizations and between organizations. But it might also happen if you have code on multiple platforms, for example for mobile apps.
Moreover, compiling an IDL to N languages is substantially easier than compiling implementation code across N languages, especially when generating idiomatic code is a requirement. A language purpose-built for this task is going to produce better results while having substantially lower complexity. (My $0.02 as someone who works on TypeSpec)
Sorry, could you elaborate? If I'm creating an API using, say, ASP.NET Core or Go, I can generate OpenAPI spec out of actual implementation. How this "IDL" fits into the workflow? Is this another output in addition to OpenAPI spec?
Re: TypeSpec: A new language for API-centric development
#26Earlier quoted context omitted.
Moreover, compiling an IDL to N languages is substantially easier than compiling implementation code across N languages, especially when generating idiomatic code is a requirement. A language purpose-built for this task is going to produce better results while having substantially lower complexity. (My $0.02 as someone who works on TypeSpec)
Sorry, could you elaborate? If I'm creating an API using, say, ASP.NET Core or Go, I can generate OpenAPI spec out of actual implementation. How this "IDL" fits into the workflow? Is this another output in addition to OpenAPI spec?
In my (limited) experience so far with TypeSpec - it really shines in an API first approach, so you define your API before you implement it, but not so much the other way around.
Re: TypeSpec: A new language for API-centric development
#27So this is coming from Microsoft. I assume it’s going to be their answer to graphql. If the project is dogfooded internally, the tools may actually be half decent, compared to whatever an open source consortium cobbles together. Not sold yet, but might gain more traction.
(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…
Would you say it's an alternative to Open API?
Re: TypeSpec: A new language for API-centric development
#28Earlier quoted context omitted.
Schemas that support multiple languages are useful when you actually use more than one language. This is more common in large organizations and between organizations. But it might also happen if you have code on multiple platforms, for example for mobile apps.
Moreover, compiling an IDL to N languages is substantially easier than compiling implementation code across N languages, especially when generating idiomatic code is a requirement. A language purpose-built for this task is going to produce better results while having substantially lower complexity. (My $0.02 as someone who works on TypeSpec)
I would have expected a bit more than type specifications, maybe some behavior specifications also? Something like Daan’s type states. But I get why we are still splitting hairs over data types.
Re: TypeSpec: A new language for API-centric development
#29Earlier quoted context omitted.
Moreover, compiling an IDL to N languages is substantially easier than compiling implementation code across N languages, especially when generating idiomatic code is a requirement. A language purpose-built for this task is going to produce better results while having substantially lower complexity. (My $0.02 as someone who works on TypeSpec)
Sorry, could you elaborate? If I'm creating an API using, say, ASP.NET Core or Go, I can generate OpenAPI spec out of actual implementation. How this "IDL" fits into the workflow? Is this another output in addition to OpenAPI spec?
TypeSpec is designed primarily as an API first tool as opposed to being an output. In the context of ASP.NET and HTTP/REST APIs, our goal is that you can write your spec and generate much of the service implementation and clients. From this same source of truth you could also emit clients or service implementations in other API definition formats like OpenAPI, schemas like JSON Schema, and other things besides.
Re: TypeSpec: A new language for API-centric development
#30Earlier quoted context omitted.
(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…
Would you say it's an alternative to Open API?
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.