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

131–140 of 141 posts

Re: No Abstractions: our API design principle

#131

Post by cylemons »

Pxtl wrote: post #113
lmz wrote: post #61

Earlier quoted context omitted.

Isn't there the issue of modifying the state enough through the low-level API such that it breaks the assumptions of the high-level one?

Yes. But that's the high-level API's problem. That's a problem with any abstraction really. "What if there's something in the thing we're abstracting that doesn't fit the abstraction" isn't really a problem with the "two API" approach, it's a problem with abstraction. The high-level API needs to handle that case, if nothing better than having internal assertions that throw if it hits a case it's not designed to accom…

You did make me search what a buffer underrun was and I think it was a good read

Re: No Abstractions: our API design principle

#132

Post by geophph »

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…

matplotlib seems to have implemented this approach

Re: No Abstractions: our API design principle

#133

Post by Splizard »

I think the point the author is trying to express here, is that it can be a useful in API representation, to couple the design with other representations designed by other parties.

I don't think "No Abstractions" is a good framing for this, although I would have to admit I dislike use of the term abstraction, as it implies there is a hierarchy of representations.

Re: No Abstractions: our API design principle

#134

Post by lwhi »

Supermancho wrote: post #116
lwhi wrote: post #48

So they say parts of the API structure are based 1-1 on externally controlled specifications. What happens if those specifications evolve or change? New API?

https://docs.stripe.com/api/versioning A versioned API. Which means more APIs to maintain, until they are removed.

More complexity is bad imo.

Re: No Abstractions: our API design principle

#135

Post by eru »

lazyasciiart wrote: post #102
eru wrote: post #85

Earlier quoted context omitted.

Just say that you don't support mixing both APIs.

Now you’re telling users to check the source code of any tools they use with your stuff? “We recommend using ToolOne only on content you do not also manage with ToolTwo”

See how libfuse handles it with their low level and high level APIs.

Re: No Abstractions: our API design principle

#136

Post by MaxBarraclough »

cpeterso wrote: post #88
jampekka wrote: post #63

Earlier quoted context omitted.

This. There should be a low level API to be able to do rarer more complicated cases, and a higher level simple API for common cases built on the lower-level API. Just today I was working with the Web File System API, and e.g. just writing a string to a file requires seven function calls, most async. And this doesn't even handle errors. And has to be done in a worker, setting up of which is similar faff in itself. Sim…

My favorite quote about abstraction is from Edsger Dijkstra: ”The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” If only the “A” in API stood for “abstraction”. For many APIs, it probably stands for “accreted”. :)

That's a great quote. This topic turned up a couple of weeks ago in another thread. [0] The excellent talk Constraints Liberate, Liberties Constrain, by Runar Bjarnason, gets at the same point, and even uses this same Dijkstra quote. [1]

[0] https://news.ycombinator.com/item?id=40021696

[1] https://youtu.be/GqmsQeSzMdw?t=874 (this takes you right to the Dijkstra quote)

Re: No Abstractions: our API design principle

#137

Post by MaxBarraclough »

> Visa and Mastercard have subtly different reason codes for why a chargeback can be initiated, but Stripe combines those codes into a single enum so that their users don’t need to consider the two networks separately.

This is indirection, not abstraction. Abstraction raises the semantic level.

Re: No Abstractions: our API design principle

#138

Post by sameoldtune »

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…

“Make the easy things easy and the hard things possible”

Re: No Abstractions: our API design principle

#139

Post by AtNightWeCode »

But the entire API is an abstraction...

So the benefits are:

Audits

Network/infra

Time to market

Single API

Less code

Risk (sometimes)

The downside:

1. Slow or missing propagation of underlying features.

2. Hidden business logic.

3. Risk of changes in pricing models and so on.

4. Single point of failure.

By method, let's talk about the downsides:

1. Not the biggest risk here. But for some reason features that are new or will save you a lot of money does not propagate as fast other things.

2. Many services like payment gateways are expected to hide some aspects of the underlying services. What does this hide?

3. The big risk with something like this used to be vendor lock-in. Today it is almost always acquisitions. Is this really a product? Will it be merged and sold together with something that I don't want?

4. Obvious

Overall I think these types of services are the most useless. Abstractions that are not simplifications should mostly be avoided. I also think one needs to be extra careful if this only sits between you and other services. That is not a product in general.

Re: No Abstractions: our API design principle

#140

Post by jampekka »

f1shy wrote: post #108
metalspoon wrote: post #66

Earlier quoted context omitted.

Tbf Vulkan is not intended for an endprogrammer. It is a deliberately low level standardization to allow directly control GPU hardware. The high-level approach (OpenGL) failed. The endprogrammer is supposed to use a third party middleware, not Vulkan itself.

So OpenGL is a total failure! I learned something today… What should I use?

Late in the game, but OpenGL was not a failure. It was written for fixed GPU hardware pipelines, for which OpenGL was perfectly suitable. And one with which one could write application code for without middleware. And it was a lot nicer API than the contemporary Direct3D, which was forced down people's throats with the usual Microsoft monopoly tactics.

It started to break down with programmable shader pipelines. And got a bit weird, with most of the API being irrelevant for the programmable-pipeline hardware.

As for Vulkan, it's a very different type of API. It's a kind of hardware abstraction layer that's easier to write drivers for. You should not use Vulkan if you're not writing hardware drivers or middleware. It's an extremely verbose and cumbersome API to use for anything.

For a low level API it's probably OK to write other APIs on, although the extreme on-your-face verbosity seems a bit unnecessary. AFAIK widely used higher level APIs have failed to really materialize. Maybe WebGPU, which is still quite low level. Game engines did get Vulkan backends quite quickly, but I wouldn't call game engines APIs as they are nowadays.

So probably you should use a game engine, even if you don't need 95% of their features. Or don't want to use languages and architectures they are married with.

Post reply on HN