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

Show HN: Instant API – Build type-safe web APIs with JavaScript

github.com

Post reply on HN
Print view View original

41–50 of 88 posts

Re: Show HN: Instant API – Build type-safe web APIs with JavaScript

#41

Post by catpaddogspot »

deredede wrote: post #22
stagas wrote: post #17

Earlier quoted context omitted.

It's not pedantry, you're using the term wrong. I understand why it can be confusing if you are just using JavaScript and you haven't had the experience of type-safe codebases. Type-safe does not refer to runtime anything, it refers to the developer being able to refactor their interfaces safely, meaning that the type system informs you of any errors across the entire codebase and all of the dependants of that softwa…

Type safety originates from academia, where it refers to the fact that unexpected (ill-typed) operations are prevented. It does not necessarily require any sort of static checking, even though the two are often associated. Type safety means that no operation receives "unexpected" inputs, but the definition of "unexpected" is not fixed in stone and can vary depending on the context, which makes it a fuzzy concept. If…

[dead]

Re: Show HN: Instant API – Build type-safe web APIs with JavaScript

#47

Post by KronisLV »

keithwhor wrote: post #5
tppiotrowski wrote: post #4

I was looking at ChatGPT plugins today and they use the OpenAPI convention. Is it called OpenAPI because it was created by "Open"AI or it's something completely independent of OpenAI that they chose to adopt?

The naming is completely coincidental and probably a little confusing / unfortunate. OpenAPI is a rebranding of Swagger, a really popular open source API specification. Incidentally the OpenAPI initiative only predates OpenAI by a month so I don’t think Sam, Greg & co could have known better at the time. But OpenAPI is the “gold standard” machine readable API specification format so it makes sense that OpenAI would r…

> But OpenAPI is the “gold standard” machine readable API specification format

I remember when that would have been WSDL, with something like SoapUI - where you'd feed in the service description file from whatever service you want to interact with and would get a functional API client. It also had codegen that let you end up with full client stubs in Java or another language, or are able to generate the WSDL file from your server code as well: https://www.soapui.org/docs/soap-and-wsdl/working-with-wsdls...

It's nice to see OpenAPI/Swagger finally catching up, because to me the codegen aspects felt insufficient there for the longest time - if your server code determines what responses to requests it will return, why on earth would you ever want to write the OpenAPI specs manually? It's the same as with ORMs - if you already have a database schema setup on a server somewhere (with SQL migrations, say with dbmate), all of your local entity mappings should be easily generated in a schema-first approach, you shouldn't have to write a single line of code for that.

The latest service I'm building is in .NET and they actually have that covered really nicely: https://learn.microsoft.com/en-us/aspnet/core/tutorials/gett...

And the Rider IDE there also has nice schema-first tooling, even if a bit niche: https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor...

Model driven development and codegen feel like they definitely belong for boilerplate heavy uses cases like this, where you can also almost perfectly describe the end result that you need based on what you have!

Re: Show HN: Instant API – Build type-safe web APIs with JavaScript

#48

Post by codemusings »

Seems like you put a lot of work into this and as such I'm hesitant to criticize. But what in the world made you think this is superior to using an actual type-safe language like TypeScript?

  /**
   * Streams results for our lovable assistant
   * @param {string} query The question for our assistant
   * @stream {object}   chunk
   * @stream {string}   chunk.id
   * @stream {string}   chunk.object
   * @stream {integer}  chunk.created
   * @stream {string}   chunk.model
   * @stream {object[]} chunk.choices
   * @stream {integer}  chunk.choices[].index
   * @stream {object}   chunk.choices[].delta
   * @stream {?string}  chunk.choices[].delta.role
   * @stream {?string}  chunk.choices[].delta.content
   * @returns {object} message
   * @returns {string} message.content
   */
Is a developer supposed to type that out for every single endpoint that uses the chunk type?

Also do I understand it correctly that you need to use Instant API everywhere in order to get this "type safety" and as such any consumer implementation would be basically limited to JavaScript?

Re: Show HN: Instant API – Build type-safe web APIs with JavaScript

#49

Post by keithwhor »

codemusings wrote: post #48

Seems like you put a lot of work into this and as such I'm hesitant to criticize. But what in the world made you think this is superior to using an actual type-safe language like TypeScript? /** * Streams results for our lovable assistant * @param {string} query The question for our assistant * @stream {object} chunk * @stream {string} chunk.id * @stream {string} chunk.object * @stream {integer} chunk.created * @stre…

No not necessarily! I just haven’t written type import support yet; though you’re welcome to help.

And no — type safety is applied at the HTTP interface. API consumers need no special library to get all the benefits.

Re: Show HN: Instant API – Build type-safe web APIs with JavaScript

#50

Post by codemusings »

keithwhor wrote: post #49
codemusings wrote: post #48

Seems like you put a lot of work into this and as such I'm hesitant to criticize. But what in the world made you think this is superior to using an actual type-safe language like TypeScript? /** * Streams results for our lovable assistant * @param {string} query The question for our assistant * @stream {object} chunk * @stream {string} chunk.id * @stream {string} chunk.object * @stream {integer} chunk.created * @stre…

No not necessarily! I just haven’t written type import support yet; though you’re welcome to help. And no — type safety is applied at the HTTP interface. API consumers need no special library to get all the benefits.

> And no — type safety is applied at the HTTP interface.

So it's basically validation middleware. The HTTP protocol does not define any such thing.

Post reply on HN