[HN Gopher] APIs All the Way Down
___________________________________________________________________
APIs All the Way Down
Author : iamacyborg
Score : 89 points
Date : 2020-12-27 16:11 UTC (6 hours ago)
(HTM) web link (notboring.substack.com)
(TXT) w3m dump (notboring.substack.com)
| ChrisMarshallNY wrote:
| That's a very good article.
|
| I actually believe in the "API" model (I call it the "Dependency"
| or "Modular" model).
|
| Dependencies are how small teams do big stuff.
|
| But dependencies are also where truly Jurassic-scale disasters
| are born.
|
| I think that it is important to exercise moderation in our
| dependencies, and accept that using them is a major decision.
| macintux wrote:
| > But dependencies are also where truly Jurassic-scale
| disasters are born.
|
| It's interesting this link showed up on the same day as How
| Complex Systems Fail.
|
| https://news.ycombinator.com/item?id=25550685
| Ericson2314 wrote:
| Let's remember there's such _huge_ difference between using a
| library, and using some interface operated by different
| organization. One you are in control, the other you aren 't.
|
| Perhaps learned helpless with package management has taught
| people to feel alienated about both of them...
| WC3w6pXxgGd wrote:
| I'm confused as to how this differs for any piece of software. A
| function has a public "API" (its name and parameters), and
| software is primarily conditional logic surrounding functions
| calls.
|
| In other words, yes: it is APIs all the way down. But is this a
| novel framing of software?
| cat199 wrote:
| > APIs are an increasingly important piece of how software is
| built.
|
| API's were always how software has been built .. _Web_ API 's, on
| the other hand ...
| CharlesW wrote:
| > _API 's were always how software has been built .._
|
| For software designed to be used by other developers, sure. For
| software in general, that's not my experience.
|
| > Web API's, on the other hand ...
|
| The ellipses suggests a natural conclusion, but none come to
| mind. Do you mind completing the thought?
| recursive wrote:
| > For software designed to be used by other developers, sure.
| For software in general, that's not my experience.
|
| The only software I can think of for users that doesn't use
| an API is maybe on an embedded microcontroller. Everything
| uses APIs. File system APIs, GUI APIs, timer APIs, network
| APIs. Even standard output is usually exposed via an API in
| most languages.
|
| > The ellipses suggests a natural conclusion, but none come
| to mind. Do you mind completing the thought?
|
| The conclusion is that software _wasn 't_ always built with
| web APIs, in contrast from APIs in general.
| cle wrote:
| According to the article's description of APIs,
| microcontrollers have their own APIs as well, in the form
| of machine code. Of course in a different sense there's a
| technical distinction between APIs and ABIs, but in this
| sense they're the same thing.
| acwan93 wrote:
| This is the future of my company's vision and technical product
| line (an in-house homegrown ERP that is 30 years old). Our
| company used to attempt do _everything_ in-house, mostly due to
| technical (in)expertise and lack of accomplishing what the
| customer truly wants with the tools available. The previous model
| I guess would be "database-driven" design, since every new tech
| stack that was built, whether it was for an e-commerce website or
| warehouse management system, would require database access first.
|
| Since I joined we've been SaaSifying the business model, and
| we're going about it with an API first design. The ERP, running
| legacy code written in Clarion (I would be very surprised if
| anyone here has heard of it!), would expose its procedures and
| functions via a .NET layer, which would open up our ERP via an
| API.
|
| With this approach, we've been able to 1) divide up
| responsibilities extremely clearly within our small team, 2)
| establish new integrations with relevant places we've never been
| able to before such as Shopify and 3) move existing features that
| the ERP has to a subscription model such as shipping rates, EDI
| document transfers, and automatic invoicing.
|
| Needless to say I am very much for API and modular design. It's
| better from a team organization perspective, since the
| responsibilities (and automated testing) is clear. From a non-
| technical perspective, our sales & support reps can see and
| understand when features are missing or where the bottlenecks are
| once we draw out how the API system is architected.
| tmikaeld wrote:
| There's a lot of advantages to API-first.
|
| 1. You're not bound to one supplier, you can integrate multiple.
|
| 2. You don't need to manage the security for a large application,
| instead, the responsibility is distributed to each API.
|
| 3. Scaling becomes a non-issue (unless you abuse the rate-
| limits/grow too fast).
|
| 4. The cost of sysops and development goes waaay down.
|
| The dis-advantages: it might be way more expensive, but at least
| you'll have shipped! (And of course GDPR/data control might be an
| issue)
| toomuchtodo wrote:
| Agree with all of these points, but you'll need the
| understanding and competence to rapidly refactor your pain
| points when you encounter them.
|
| Tangentially, I believe low and no code platforms are perfect
| for prototyping gluing APIs together to prove out concepts, and
| once you've demonstrated traction (whatever that looks like for
| your product), it's time to refactor out into your own business
| line app to control your product's destiny.
| nuclearnice1 wrote:
| which no code platforms have you had success with? I saw AWS
| got in the game with honeycode.
| toomuchtodo wrote:
| Any of the well known products are fine products to be
| using. Which is right for your use case is dependent on the
| use case and product features.
___________________________________________________________________
(page generated 2020-12-27 23:00 UTC)