Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeSpec: A new language for API-centric development

typespec.io

Post reply on HN
Print view View original

91–100 of 121 posts

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

#91

Post by DanielHB »

darylteo wrote: post #60

Spec api code, imo. Feels like it's going backwards - there's really no reason why it has to be a .tsp, instead of a .ts with actual api code. It's even using @annotations. In fact the annotations i see in the screenshot (@route, @query, @path) are practically the same in NestJS. I feel that we should be focusing on enhancing that paradigm instead. In fact I already have a working POC of NestJS -> OpenAPI -> Client l…

the whole point of a DSL for APIs is so it can interop with different languages, frameworks and toolchains. Sure if you all your services are NestJS then you don't need this.

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

#93

Post by ActionHank »

H12 wrote: post #92

Seems like this exists in a similar problem domain as pkl? https://pkl-lang.org/index.html

Yeah, but this one is better because new.

I might be wrong, but I suspect that the crazy hype-driven-development has started to move on from frontend to backend.

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

#94

Post by blowski »

ActionHank wrote: post #93
H12 wrote: post #92

Seems like this exists in a similar problem domain as pkl? https://pkl-lang.org/index.html

Yeah, but this one is better because new. I might be wrong, but I suspect that the crazy hype-driven-development has started to move on from frontend to backend.

The backend has definitely suffered from "crazy hype-driven development" for the last 30 years. Perl, Python, Ruby, Java, PHP, Scala, Clojure, Go, Rust have all had their brief moment as the silver bullet. Not to mention ops tooling - Vagrant, Docker, Kubernetes, Puppet, Chef, Ansible.

I wasn't alive in the 1970s, but I'm guessing that those who were would say it was just as faddish then as well.

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

#95

Post by jen20 »

joelwilsson wrote: post #35

Looks like a competitor/alternative to Smithy, https://smithy.io/2.0/index.html . Since at least one person from the TypeSpec team is here, do you have any thoughts on how they compare?

This was my thought too - since smithy is already out there and used in a similar domain, it would be useful to have a comparison. “Doesn’t have Kotlin and Gradle all over the show” seems like a significant advantage in favour of TypeSpec.

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

#96

Post by nicce »

angra_mainyu wrote: post #89
nicce wrote: post #84

Earlier quoted context omitted.

If you can define single spec and autogenerate everything (client/server/OpenAPI et. al.), then spec first is superior. Looking at https://smithy.io/2.0/index.html which can already generate much more than TypeSpec based on the docs and awesome list.

I'm not sure how I can autogenerate non-trivial logic, which is my point. How would you handle a typical case where based on request data an endpoint fetches some additional information from various sources and depending on that performs several different actions? This is the most common scenario I've encountered outside of extremely trivial CRUD endpoints. EDIT: don't get me wrong, I'm not being purposefully obtuse…

I am still trialing Smithy, but as far as I understand, the code which is generated by Smithy, generates suitable abstractions and you never modify this code yourself.

It leaves the middleware library selection for the user, and with middleware you can do whatever more complex operations you need.

TypeScript server overview: https://smithy.io/2.0/ts-ssdk/introduction.html

> This execution flow allows the service developer to choose not only their endpoint, but the programming model of their service. For instance, all of the shim conversion and handler invocation can be refactored into a convenience method, or the service developer could choose to incorporate their favorite open source middleware library, of which the server SDK would simply be one layer. It also allows open-ended request preprocessing and response postprocessing to happen independent of Smithy. For instance, a developer could add support for request or response compression, or a custom authentication and authorization framework could be plugged into the application before the server SDK is invoked, without having to fight against a more heavyweight abstraction.

The Service type itself also seems to make it possible to define quite complex logic: https://smithy.io/2.0/spec/service-types.html

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

#97

Post by gpderetta »

Savageman wrote: post #51
pjmlp wrote: post #49

> At Microsoft, we believe in the value of using our own products, a practice often referred to as "dogfooding". One would think, unfortunely that is not how it looks like in the zoo of native Windows desktop development, or Xamarin/MAUI adoption in their mobile apps.

It must be a new policy, or maybe only for this product (which makes good marketing). I've used Microsoft Graph to manage emails, and I'd be very surprised if they use if for Outlook...

dogfooding has been a thing at MS probably since its inception. Of course it doesn't mean it is always practiced fully.

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

#98

Post by kkukshtel »

I wish any of Typespec, Cue, Pkl, Dhall, etc. would just implement their core functionality in C with an ABI for other language bindings. Needing to use whatever dep they decided to operate with as part of adoption of the language itself is a big ask. I want to try out your config language, I don't want/need all of node to make this happen.

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

#100

Post by jayd16 »

vbezhenar wrote: post #45
usrusr wrote: post #43

Feels like cheating, next to the yaml of openapi anything will look good. And that's all while I'm still considering openapi one of the best things that have happened. But I've also been kind of holding my breath for typescript making it's breakthrough as a schema language. More specifically its surprisingly big non-imperative, non-functional subset, obviously. And at first glance this seems to be exactly this, "what…

TypeScript type system is very advanced. It won't be possible to generate corresponding bindings for all popular languages, while keeping them idiomatic. I'd prefer API language to be very simple and straightforward.

So what happens if a server in another language uses that feature? You don't want to be able to represent that?
Post reply on HN