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

11–20 of 141 posts

Re: No Abstractions: our API design principle

#11

Post by jackflintermann »

koreth1 wrote: post #6
chowells wrote: post #4

If there's no abstraction, what's your value-add? I don't care enough to read your marketing BS to see where you claim to be special, but... If your API is doing the exact same things as an underlying service is doing, you're just a middleman extracting rents. You might find it more valuable to state your position as "carefully scoped abstractions" to make it clear what value you add.

Based on my previous experience on payment systems, there's a surprising amount of value in not having to maintain direct business relationships with the underlying payment providers. It is much, much easier to work with a company like Stripe than to work directly with Visa and MasterCard and the ACH network, and heaven help you if you're a small company that needs to do automated cross-border payments to a wide rang…

Yes, exactly, the important thing to us is that our users don't need to build an additional mental model between us and the networks we sit atop. If you know the network, we want you to be able to intuit how our API works. There's a very real difference (arguably the fundamental value-add of our company) in the transport layer, though. The actual mechanics of integrating with, say, FedACH, are a bit long to get into here (we get into it a bit here if it's of interest: https://increase.com/documentation/fedach) but suffice to say it doesn't have a REST API.

Re: No Abstractions: our API design principle

#12

Post by OJFord »

exe34 wrote: post #7
koreth1 wrote: post #6

Earlier quoted context omitted.

Based on my previous experience on payment systems, there's a surprising amount of value in not having to maintain direct business relationships with the underlying payment providers. It is much, much easier to work with a company like Stripe than to work directly with Visa and MasterCard and the ACH network, and heaven help you if you're a small company that needs to do automated cross-border payments to a wide rang…

I thought I understood everything you said, but isn't Stripe a middleperson here? > without a middleman.

Yes, GP's point is 'good luck to you doing that yourself, without a middleman [such as Stripe]'.

Re: No Abstractions: our API design principle

#14

Post by koreth1 »

jackflintermann wrote: post #11
koreth1 wrote: post #6

Earlier quoted context omitted.

Based on my previous experience on payment systems, there's a surprising amount of value in not having to maintain direct business relationships with the underlying payment providers. It is much, much easier to work with a company like Stripe than to work directly with Visa and MasterCard and the ACH network, and heaven help you if you're a small company that needs to do automated cross-border payments to a wide rang…

Yes, exactly, the important thing to us is that our users don't need to build an additional mental model between us and the networks we sit atop. If you know the network, we want you to be able to intuit how our API works. There's a very real difference (arguably the fundamental value-add of our company) in the transport layer, though. The actual mechanics of integrating with, say, FedACH, are a bit long to get into…

That's an excellent point too. Some payment systems have abysmal technology. The product I worked on was focused on international payments and in a couple cases, the "API" was literally, "Upload a CSV file via FTP, and at some later point, another CSV file might appear on the FTP server with some of the payment results, but if it doesn't, call us because we probably just forgot to upload it."

Re: No Abstractions: our API design principle

#15

Post by exe34 »

koreth1 wrote: post #10
exe34 wrote: post #7

Earlier quoted context omitted.

I thought I understood everything you said, but isn't Stripe a middleperson here? > without a middleman.

Right, Stripe is a middleman and part of the value they're giving you is that you don't have to work directly with the underlying payment companies. If you had to support the same range of payment options without a middleman, you'd need to have business relationships with a bunch of payment companies, which would be a lot more difficult and time-consuming. Hope that's clearer!

Makes sense thanks!

Re: No Abstractions: our API design principle

#16

Post by l5870uoo9y »

> 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 line.

Re: No Abstractions: our API design principle

#19

Post by jiggawatts »

conroy wrote: post #9
chowells wrote: post #4

If there's no abstraction, what's your value-add? I don't care enough to read your marketing BS to see where you claim to be special, but... If your API is doing the exact same things as an underlying service is doing, you're just a middleman extracting rents. You might find it more valuable to state your position as "carefully scoped abstractions" to make it clear what value you add.

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.

Re: No Abstractions: our API design principle

#20

Post by trevor-e »

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've always seen currencies multiplied by 100 to remove the need for floating point.
Post reply on HN