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

31–40 of 141 posts

Re: No Abstractions: our API design principle

#31

Post by chaos_emergent »

l5870uoo9y wrote: post #16

> Monthly fees for users building on Increase vary by use case. I am currently adding public API access to AI-powered text-to-SQL endpoint with RAG support and the my biggest issue is the pricing. Anybody have a ballpark figure what we could be talking about here? Pricing must account for OpenAI tokens (or perhaps letting them add their own OpenAI token), database usage and likely caching/rate limiting setup down the…

Foundationally, pricing should be based on value, not cost[1] so you should think about what the value is to your customer and go from there.

Ex: I know that Gong costs a ton of organizations over 100k/year, and there's no way that, accounting for storage, CPUs, and all the other OpEx, that the cost comes anywhere close to the cost of compute - it's likely at least an order of magnitude greater. But because sales teams bring in so much revenue so directly, any leverage that they can buy in the form of a tool like Gong is immediately and obviously valuable.

[1]: the exception to avoiding cost-plus pricing is if you're selling a commodity. But you're not in that boat!

Re: No Abstractions: our API design principle

#32

Post by chaos_emergent »

jiggawatts wrote: post #19
conroy wrote: post #9

Earlier quoted context omitted.

In this case, a HTTP API is the abstraction. Integrating with ACH and other payment rails requires a lengthy integration process. Sometime you have to send binary files using FTP!

The article says “no abstractions”, but HTTP is often exactly that: an abstraction over lower-level protocols.

perhaps what you're thinking of is "equal entropy abstractions" - HTTP is just a way of standardizing logic, but the complexity of the shape and behavior of the API remains.

Re: No Abstractions: our API design principle

#34

Post by cratermoon »

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 Federal Reserve, deprecates Input Message Accountability Data and switches to a new thing?

Maybe things are a lot simpler in the payment industry than they are in transportation or networking protocol. If I built a packet-switching product based on X.25 and later wanted to also support tcp/ip, what's the right abstraction?

Re: No Abstractions: our API design principle

#36

Post by tadfisher »

lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

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.

Re: No Abstractions: our API design principle

#37

Post by advisedwang »

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"

The article clearly says it also means "no unifying similar objects", which enables the naming decision.

Re: No Abstractions: our API design principle

#38

Post by rtpg »

spandrew wrote: post #3

Love the article. If you love Stripe (and as a designer and tech entrepreneur I do – Stripe's simplicity and front-end skill is incredible) you might look at them and copy their ability to simplify and deliver polished experiences. But the real mastery of Stripe is that they know their customers — and the simplicity they crave. By this article is sounds like Increase does as well and has forged a similar laser-focus…

Yeah I do think you can see in Stripes API places where there are differing tensions between “let’s make this potentially universal” and “let’s accept that this stuff is going to probably only apply for one payment method in one market”.

Personally I appreciate when the latter happens, but there’s an aesthetic decision there

Re: No Abstractions: our API design principle

#40

Post by xxgreg »

endofreach wrote: post #26
lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

You should never use floats for dinero. And it has nothing to do with JS, though i find it funny that you mention JS.

Don't use floats if you're trying to represent an exact value, i.e. someones bank account. But in financial modelling you're generally dealing in probabilistic "expected values", it's common and fine to use floats.

Having said that, half the world seems to run on Excel spreadsheets, which are full of money values, and Excel is basically all floats (with some funky precision logic to make it deterministic - would be curious to know more).

https://stackoverflow.com/questions/2815407/can-someone-conf...

Post reply on HN