Live data from Hacker News

TypeSpec: A new language for API-centric development

typespec.io

31–40 of 121 posts

Re: TypeSpec: A new language for API-centric development

#31
post #21

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.

I added support for typespec as an input specification to my openapi 3 based code generator a couple of days ago.

They provide an API to convert to openapi documents so it was pretty painless (https://github.com/mnahkies/openapi-code-generator/pull/158)

My focus is on doing both client sdk and server stub generation, though only typescript so far - will hopefully add other languages eventually, when I'm satisfied with the completeness of the typescript templates.

Re: TypeSpec: A new language for API-centric development

#32

Looks like the Typescript version of WSDL: https://en.wikipedia.org/wiki/Web_Services_Description_Langu... Perhaps it will last longer than WSDL did?

You may already know this but:

1. A more exact analogy would be WSDL+SOAP.

2. WSDL and SOAP are defined in XML, and SOAP describes XML.

3. The popularity of these technologies followed the popularity (both rise and decline) of XML generally.

4. TypeSpec describes JSON and protobuf, and will likely also lose popularity if those formats do.

Re: TypeSpec: A new language for API-centric development

#33
post #7

Bespoke 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

FastApi can generate the OpenApi yaml

Re: TypeSpec: A new language for API-centric development

#36

Earlier quoted context omitted.

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

FastApi can generate the OpenApi yaml

not everyone writes Python, and not everyone starts code-first

Re: TypeSpec: A new language for API-centric development

#37
Could someone clarify what's the use case of a tool like this please.

Is this something that helps if you, say, are building a new API and will need to create both the server implementation as well as the client implementations in multiple languages? And so, it can automatically do all of that for you based on an API spec? Or is it something different.

Funnily enough, I developed a Python library recently that allows you to build API clients in a way that very closely resembles the TypeSpec example. But I'm pretty sure they are very different things.

Re: TypeSpec: A new language for API-centric development

#38
post #37

Could someone clarify what's the use case of a tool like this please. Is this something that helps if you, say, are building a new API and will need to create both the server implementation as well as the client implementations in multiple languages? And so, it can automatically do all of that for you based on an API spec? Or is it something different. Funnily enough, I developed a Python library recently that allows…

If you are in a situation where you have a backend and you want to expose an API and then you would eventually want a client, you would need format specs as the starting point where server and clients are generated from that one source.

At the moment, OpenAPI with YAML is the only way to go but you can't easily split the spec into separate files as you would do any program with packages, modules and what not.

There are third party tools[0] which are archived and the libraries they depend upon are up for adoption.

In that space, either you can use something like cue language 1] or something like TypeSpec which is purpose built for this so yet, this seems like a great tool although I have not tried it yet myself.

[0]. https://github.com/APIDevTools/swagger-cli

[1]. https://cuelang.org/

EDIT: formating

Re: TypeSpec: A new language for API-centric development

#39
Looks interesting, but what would be the advantage of this over just writting an openAPI specification? It's more concise, but currently this would require you to increase your toolchain to go from TypeSpec to openAPI to generating code.

Any plans to add code generatio to this project?

Re: TypeSpec: A new language for API-centric development

#40
post #38
post #37

Could someone clarify what's the use case of a tool like this please. Is this something that helps if you, say, are building a new API and will need to create both the server implementation as well as the client implementations in multiple languages? And so, it can automatically do all of that for you based on an API spec? Or is it something different. Funnily enough, I developed a Python library recently that allows…

If you are in a situation where you have a backend and you want to expose an API and then you would eventually want a client, you would need format specs as the starting point where server and clients are generated from that one source. At the moment, OpenAPI with YAML is the only way to go but you can't easily split the spec into separate files as you would do any program with packages, modules and what not. There a…

Whilst it's not as expressive/flexible as typespec, and in my experience it's not always well supported by tooling, you can do $ref's across files in openapi specifications.

Eg: https://github.com/mnahkies/openapi-code-generator/blob/main...

Post reply on HN