Live data from Hacker News

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

github.com

31–40 of 88 posts

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

#31
post #24

Earlier quoted context omitted.

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…

I have to stretch my imagination a lot to see how "type-safe" can mean "it throws at runtime".

The term "type safety" was coined in a context where "does random things then ultimately segfaults (if you are lucky)" is a possible alternative.

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

#32
post #30

We tried for years to do things like this, and in the end an approach using typescript is way, way better than anything else I've seen attempted. In my latest project[1], we set up the types for the API. The server and client are both bound by those types, meaning that one cannot change without the other. This fixes an entire class of bugs where backend code gets updated without the corresponding front-end code chang…

Our approach doesn’t preclude TypeScript! In fact I think it would integrate well with it. If you’re interested in a TS approach could you email me at keith@instant.dev ?

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

#33
post #26

Neat! Does this framework have any tools for content negotiation? I get that you could do this in the handlers themselves, but in my experience different representations are often so different in implementation that aside from maybe a tiny bit of shared code to produce some underlying dataset, the actual rendering of that data shares very little. As an example: `application/json` and `text/html` respresentations of a…

I’m not quite sure I grok the use case, can you give a more precise example? Either way, if you’re interested in the approach I *very welcome* issues, PRs and contributors. I think it would be pretty straightforward to create tests for whatever you’re looking for.

Here's a simple use case: human friendly and machine friendly representations at the same path.

For example, let's say I have an api at `/weather` which when requested with the header `accept: application/json` returns something like:

    { "temperature": 25, "unit": "c" }
Now if I open that same path in a browser, I get an html page displaying the day's temperature in a nicely formatted way for humans to read.

Or another case, I want to version an API, such that I can provide different representations based on the version requested. So I look for `accept-version` and if it's `v1` for example I get the `v1` version. GitHub does this, as a real world example: https://docs.github.com/en/rest/overview/api-versions?apiVer...

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

#34
post #33

Earlier quoted context omitted.

I’m not quite sure I grok the use case, can you give a more precise example? Either way, if you’re interested in the approach I *very welcome* issues, PRs and contributors. I think it would be pretty straightforward to create tests for whatever you’re looking for.

Here's a simple use case: human friendly and machine friendly representations at the same path. For example, let's say I have an api at `/weather` which when requested with the header `accept: application/json` returns something like: { "temperature": 25, "unit": "c" } Now if I open that same path in a browser, I get an html page displaying the day's temperature in a nicely formatted way for humans to read. Or anothe…

Entirely possible! I mean right now we restrict endpoint definitions to HTTP methods but in theory you could define unique endpoints for any combination of parameters. What I would want to find is the most effective / used combinations as opposed to unlimited flexibility.

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

#35
post #30

We tried for years to do things like this, and in the end an approach using typescript is way, way better than anything else I've seen attempted. In my latest project[1], we set up the types for the API. The server and client are both bound by those types, meaning that one cannot change without the other. This fixes an entire class of bugs where backend code gets updated without the corresponding front-end code chang…

[deleted]

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

#37
post #27

Earlier quoted context omitted.

That’s good feedback! We can probably do both; if you think it’s cool would you be interested in contributing to TypeScript support to circle the square?

For sure! Do you pay money $$$? :)

Feel free to email keith@instant.dev if you’re legitimately interested :)

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

#39

[flagged]

If you’d like to help build a TS integration, welcome! What’s the MRR of your company? Did you found it or are you an employee? Any specific tips on how TS projects can significantly improve either revenue acquisition or retention over JS projects?
Post reply on HN