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

21–30 of 88 posts

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

#21

Post by stagas »

keithwhor wrote: post #18
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…

Fair enough; if I were to change the qualifiers associated with the project, what’s cool about what exists here and how would you describe it in a way that’s maximally appealing? Is “type-safe” an acceptable generalization given an audience less sophisticated than you or can I use a different framing to the same effect?

For this software to be appealing it would need to really be type-safe, meaning you'd need to use TypeScript. Type-safe means I can change an interface in project B and project A that depends on B now shows me errors in the editor exactly where I need to visit to fix it. If that isn't happening, it can't be called type-safe or generalized to that term. Currently it's a type-unsafe HTTP endpoint runtime type validator.

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

#22

Post by deredede »

stagas wrote: post #17
keithwhor wrote: post #13

Earlier quoted context omitted.

My claim is only type-safety at the HTTP layer. This claim is intentionally specific! As per another comment in this thread, pedantry is the most valuable currency on HN, so this sort of feedback is not only expected but welcome.

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 I only define + on integers, and allow `"a"+"b"`, then that's unexpected and must be prevented somehow to be type safe. If I define + on integers or strings, it is fine.

Here using "type safe" is warranted, because the system prevents you from making HTTP calls with unexpected arguments - even though the validation occurs at runtime and the result may be an exception.

(Edit: well to be strictly fair it's not really type-safe because nothing prevents the HTTP endpoint's expected arguments to change under your feet)

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

#23

Post by keithwhor »

stagas wrote: post #21
keithwhor wrote: post #18

Earlier quoted context omitted.

Fair enough; if I were to change the qualifiers associated with the project, what’s cool about what exists here and how would you describe it in a way that’s maximally appealing? Is “type-safe” an acceptable generalization given an audience less sophisticated than you or can I use a different framing to the same effect?

For this software to be appealing it would need to really be type-safe, meaning you'd need to use TypeScript. Type-safe means I can change an interface in project B and project A that depends on B now shows me errors in the editor exactly where I need to visit to fix it. If that isn't happening, it can't be called type-safe or generalized to that term. Currently it's a type-unsafe HTTP endpoint runtime type validator…

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?

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

#24

Post by stagas »

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…

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

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

#25

Post by keithwhor »

whinvik wrote: post #20

Both the name and intent seem highly inspired from FastAPI!

Interestingly I published a Ruby framework called FastAPI before Python’s FastAPI existed ;) — been thinking about this stuff for a long time.

https://github.com/thestorefront/FastAPI

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

#26

Post by mstade »

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 single resource may render some of the same bits of data, but the actual rendering process is entirely different. Even if the content type is the same, you may render completely different output based on other parameters, like a header used to select between different profiles of said content type, or even just something simple as `accept-language`.

If it's not possible right now, is there any plans to support routing based not just on method and URL, but on headers as well?

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

#27

Post by stagas »

keithwhor wrote: post #23
stagas wrote: post #21

Earlier quoted context omitted.

For this software to be appealing it would need to really be type-safe, meaning you'd need to use TypeScript. Type-safe means I can change an interface in project B and project A that depends on B now shows me errors in the editor exactly where I need to visit to fix it. If that isn't happening, it can't be called type-safe or generalized to that term. Currently it's a type-unsafe HTTP endpoint runtime type validator…

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 $$$? :)

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

#28

Post by keithwhor »

mstade wrote: 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.

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

#29

Post by [deleted] »

stagas wrote: post #12

Type Safety != Runtime Type Validation. Something being Type Safe means that I, the programmer, am Safe from making type mistakes while developing and maintaining the software. For that to be possible, you need a type system that is embedded in the language and the editor and can continously analyze all of your code types to be correct. Type safe means that any breaking change to any interface will immediately error…

[deleted]

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

#30

Post by tsergiu »

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 changing or vice-versa. It also has the nice side-effect that all of the possible return values (including errors) are nicely documented in one file, and that the errors are very consistent. On the frontend we have a "typed fetch" which returns typed results from the API.

We are also using this for typed access to localStorage, another source of many bugs in past projects, where random keys end up being scattered and causing nondeterministic behavior on different devices.

You can see how our API type system is implemented here:

- common types for both client and server: https://github.com/stoarca/presupplied/blob/master/images/ps...

- client's typed fetch: https://github.com/stoarca/presupplied/blob/master/images/ps...

- server's typed endpoint definitions: https://github.com/stoarca/presupplied/blob/master/images/ps...

[1]: We are working on https://app.presupplied.com, a digital home-schooling curriculum to teach 3-year-olds to read. Planning to expand to math, writing, and programming.

Post reply on HN