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

No Abstractions: our API design principle

increase.com

Post reply on HN
Print view View original

121–130 of 141 posts

Re: No Abstractions: our API design principle

#121

Post by tadfisher »

int_19h wrote: post #100
tadfisher wrote: post #36

Earlier quoted context omitted.

I will be the contrarian: JSON numbers are not floating point values, they are strings of characters matching the format "-?(?:0|[1-9]\d*)(?:\.\d+)?(?:[eE][+-]?\d+)?". You can choose to parse them however you want, and parsing libraries should provide a mechanism to decode to an arbitrary-precision value.

Regardless of what the libraries should be doing, there is the reality of what they are doing.

Luckily, there are not many broken JSON parsers out there, as this is a well-known issue. Just about the only parser that remains broken is Javascript's JSON.parse(), because it doesn't allow for any options to control the parser, which is why we keep having this discussion.

Re: No Abstractions: our API design principle

#122

Post by tadfisher »

meekaaku wrote: post #101
tadfisher wrote: post #36

Earlier quoted context omitted.

I will be the contrarian: JSON numbers are not floating point values, they are strings of characters matching the format "-?(?:0|[1-9]\d*)(?:\.\d+)?(?:[eE][+-]?\d+)?". You can choose to parse them however you want, and parsing libraries should provide a mechanism to decode to an arbitrary-precision value.

Yes, but say in javascript if you do a JSON.parse(), it will give you a double float right?

Yes, because JSON.parse() treats the input as if it were a JS object literal; that is, JSON.parse(JSON.stringify(someObject)) will be idempotent. Usually parser libraries let you construct a parser with options, so you'd make a "let json = JSON({parseNumbersAsBignums: true})" and use that everywhere, but JS doesn't have that built in.

Re: No Abstractions: our API design principle

#123

Post by cratermoon »

Terr_ wrote: post #67
cratermoon wrote: post #34

No Abstractions here really means "just use terms from the underlying system", which is a good naming principle in general. Problems inevitably arise over time when there's multiple underlying systems and they have different names for the same thing, or, arguably worse, use both use a name but for different things. In this example, what if the underlying payment providers have different models? Also, what if the Fede…

> No Abstractions here really means "just use terms from the underlying system" Which sounds a bit like Domain Driven Design, although the "underlying system" in this case may be a bit too implementation-centered to be considered a real business domain. To expand on that a bit: In DDD you generally defer to the names and conceptual-models the business-domain has already created. Trying to introduce your own "improved…

> the "underlying system" in this case may be a bit too implementation-centered to be considered a real business domain.

I tend to agree with this. The domain concepts would be things like charge-backs and the reasons for them. The details of the codes and categories are implementation-specific. Unless, as Increase seems to be implying, their domain is the payment networks and fintech and their customers care about them the same way a kernel programmer would care about the details of memory allocators or schedulers, while most application programmers just want them to exist and work in a consistent way.

Re: No Abstractions: our API design principle

#124

Post by jimbob45 »

Karellen wrote: post #46

> If you’re building an abstraction-heavy API, be prepared to think hard before adding new features. If you’re building an abstraction-light API, commit to it and resist the temptation to add abstractions when it comes along. You could always do both. Provide a low-level abstraction-light API that allows fine control but requires deep expertise, and write a higher-level abstraction-rich API on top of it that maps to…

That sounds like the exact philosophy the Vulkan devs took versus OpenGL.

Re: No Abstractions: our API design principle

#125

Post by eterm »

InvisibleUp wrote: post #65
Karellen wrote: post #46

> If you’re building an abstraction-heavy API, be prepared to think hard before adding new features. If you’re building an abstraction-light API, commit to it and resist the temptation to add abstractions when it comes along. You could always do both. Provide a low-level abstraction-light API that allows fine control but requires deep expertise, and write a higher-level abstraction-rich API on top of it that maps to…

.NET also does this a lot. Here's a recent devblog post looking at file I/O: https://devblogs.microsoft.com/dotnet/the-convenience-of-sys...

That's a fantastic blog post, worthy of it's own HN submission.

Re: No Abstractions: our API design principle

#126

Post by jackflintermann »

gr4vityWall wrote: post #115
jackflintermann wrote: post #28

Earlier quoted context omitted.

I guess the phrase "no abstractions" is specifically valuable to us when designing our REST API resources - our whole stack is certainly an abstraction of sorts, but we don't want to add yet another abstraction in that specific layer.

Just wanted to say that I appreciated the article :) Using well-designed APIs is great, and seeing people putting a lot of thought on it, with the intent of improving dev experience, is very refreshing. I've dealt a lot of technically impressive Free Software projects that didn't focus on this as much, and as a result, using their libraries was harder.

Thank you!

Re: No Abstractions: our API design principle

#127

Post by layer8 »

dkjaudyeqooe wrote: post #107
RobotToaster wrote: post #106

No abstractions? So their API lets me control the individual registers on their CPU then?

No, sorry, registers are an abstraction. The API only lets you set voltages on individual wires.

Do you also have to provide the clock signal for processing? Might become expensive in terms of API calls.

Re: No Abstractions: our API design principle

#128

Post by yixu34 »

Karellen wrote: post #46

> If you’re building an abstraction-heavy API, be prepared to think hard before adding new features. If you’re building an abstraction-light API, commit to it and resist the temptation to add abstractions when it comes along. You could always do both. Provide a low-level abstraction-light API that allows fine control but requires deep expertise, and write a higher-level abstraction-rich API on top of it that maps to…

+1, I like to refer to this post on this topic: https://blog.sbensu.com/posts/apis-as-ladders/

Re: No Abstractions: our API design principle

#129

Post by dkjaudyeqooe »

layer8 wrote: post #127
dkjaudyeqooe wrote: post #107

Earlier quoted context omitted.

No, sorry, registers are an abstraction. The API only lets you set voltages on individual wires.

Do you also have to provide the clock signal for processing? Might become expensive in terms of API calls.

I had to think about it for a sec, but clock signals are indeed an abstraction so you have to provide them.

Re: No Abstractions: our API design principle

#130

Post by crabmusket »

krainboltgreene wrote: post #54
crabmusket wrote: post #50

Earlier quoted context omitted.

This isn't sufficient to represent prices which often include fractional amounts of cents in non-retail scenarios. Think of AWS server prices per hour.

Funny, because that's exactly what Stripe does ( https://docs.stripe.com/billing/subscriptions/usage-based/pr... )

But those are decimal values, not integers. I didn't mean that using cents as a unit was insufficient, I meant that using integers was.
Post reply on HN