51–60 of 121 posts
> 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.
I've used Microsoft Graph to manage emails, and I'd be very surprised if they use if for Outlook...
Earlier quoted context omitted.
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…
Thanks, that makes sense for that use case. My question is probably a more general one around the use case for writing an API spec (in a format like OpenAPI or TypeSpec), and then translating and writing the server implementation to match that. As opposed to being able to create the API spec automatically based on server implementation (and being able to easily refresh it). Understand that writing the spec and then t…
See my comment below to another question [0]
That's the upside that instead of generating specs from comments of methods, you actually generate the methods from the formally verified/linted and crafted spec.
Codegen is annoying and error prone.
Would be nice if you could just import those typespec files in typescript (and other languages?) and get automatic typescript types from them. Codegen is annoying and error prone.
The "annoying" part I do get -- it's obviously nicer to have instant feedback than being forced to rebuild things -- so for things where you iterate a lot, that does weigh in the other direction.
Would be nice if you could just import those typespec files in typescript (and other languages?) and get automatic typescript types from them. Codegen is annoying and error prone.
Looks like the Typescript version of WSDL: https://en.wikipedia.org/wiki/Web_Services_Description_Langu... Perhaps it will last longer than WSDL did?
WSDL issue was that it was designed by a committee of several huge companies. So it was inconsistent and bloated. Same could be said about many XML-related standards. Nowadays big companies rarely work together and prefer to throw their own solutions to the market, hoping to capture it. That results in a higher quality approaches, because it's developed by a single team and focused on a single goal, rather than tryin…
WSDL 1.0's list of editors reads [2]:
> Erik Christensen, Microsoft; Francisco Curbera, IBM; Greg Meredith, Microsoft; Sanjiva Weerawarana, IBM
IOW, TypeScript is by the same company as SOAP and WSDL.
> Nowadays big companies rarely work together [...] That results in a higher quality approaches
[Citation needed]
[1]: https://en.wikipedia.org/wiki/SOAP>
[2]: http://xml.coverpages.org/wsdl20000929.html>
I failed to find an answer to the main question: what output languages are supported. The only way is to emit OpenAPI and then using one of their terrible generators?
So 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…
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 libraries so I see no place for this. The spec itself is simply a vehicle for code generation, and serves little purpose otherwise and I'd be happy to be rid of it.