jackflintermann
Joined 15 years ago
Karma
305
Submissions
29
Member since
Oct 30
Software engineer at Increase, formerly Stripe.
@jflinter
my first name at my employer dot com
View on Hacker NewsRecent submissions
Comment · 6 days ago
I wrote some thoughts on the workflow we use to publish our API documentation and related artifacts. I'm curious if others are doing similar or if there are other ways to do this.
Comment · 2 years ago
I liked this article a lot - information-dense but approachable. It feels like you can understand the entire app using only the code snippets in the article, which speaks to the quality of the design. The only part that made me roll my eyes was the AI piece - I don't think there's any actual AI involved in the app, it seems like the author just used it to figure out what metrics to use, and then hardcoded them into the app? (That's probably how I'd do it, tbh - I just think the AI part distracts from the overall point and doesn't need to be in the post.)
Comment · 2 years ago
Thank you!
Comment · 2 years ago
I appreciate the thorough read!
For deprecations we're lucky in that the underlying systems don't change very much (the Input Message Accountability Data isn't going anywhere). But we'll run into collisions when we, for example, start issuing cards on Mastercard as well as Visa.
We have experimented with a couple of, um, abstractions, and may do so there. One rule we've stuck to, and likely would as well, is to keep the "substrate objects" un-abstracted but to introduce higher-level compositions for convenience. For example, there is no such thing as a "Card Payment" (https://increase.com/documentation/api#card-payments) - it's just a way to cluster related card authorization and settlement messages. But it's extremely useful for users and nontrivial to do the reconciliation, so we tried it. But we think it's essential that the underlying network messages (the "substrate objects") are also accessible in the API, along with all the underlying fields etc.
Unfortunately 100% of the public APIs I have worked on are in payments. I wish I had another lens!
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
Author here - this has been a useful mindset for us internally but I'm curious if it resonates externally. I'd love your feedback!
Comment · 2 years ago
I took a crack at recreating this in javascript once the necessary APIs made their way to mobile safari - https://highphone.app if interested! (iPhones only, sorry)
Comment · 4 years ago
(Increase employee)
We took the approach of starting with an intentionally bad name (in our case, bnk.dev) and using it until a good domain became available to purchase for a reasonable price.
Related: http://www.paulgraham.com/name.html
Comment · 12 years ago
Haha, sorry! I snagged it for a friend. Bought it immediately upon sight - wasn't gonna let it get away after someone got sailbo.at from under me.
Comment · 12 years ago
Wow, this is really good! I'm surprised at how many shortwords are still available given a little creativity.