Net API Notes for 2021/10/13 - Issue 178

This Net API Notes has the business case for modular architectures observing Conway's Law, some sobering thoughts on GraphQL, and a bevvy of helpful API design reminders. Like the fall squirrels hunting acorns in my backyard, let's get after it!

Net API Notes is a regular, hand-curated digest of impactful news and analysis for busy API practitioners. Are you reading this on the web and not subscribed yet? Sign up today and be the first to get ad-free, actionable info delivered weekly to your inbox.

NOTES

WHY COMPANIES MUST EMBRACE MODULAR THINKING

STRAT / DESIGN / DOC / DEV & TEST / DEPLOY / SECURITY / MONITOR / DISCOVERY

I tend to try and avoid articles behind paywalls; even if the quality is top-notch, not everybody has the means (or temperament) to get nickel-and-dimed in pursuit of their learning path. However, I will make an exception for the article by Mark J. Greeven, Howard Yu, and Jialu Shan on the MIT Sloan website. Titled "Why Companies Must Embrace Microservices and Modular Thinking", it offers a unique perspective on Conway's Law.

Usually, with most of us coming from the technical side of the house, we talk microservices regarding software boundaries, development autonomy, and two-pizza teams. This piece, however, starts with the organizational need for adaptability and speed and derives an architecture to match.

If you're having difficulty pitching microservices to your leadership, try giving the arguments in this piece a chance. They might resonate more with your executive's worldview.

GRAPHQL NOT FIT FOR EXTERNAL USE?

STRAT / DESIGN / DOC / DEV & TEST / DEPLOY / SECURITY / MONITOR / DISCOVERY

With growth comes aches and pains. GraphQL is no exception. The query-language-over-HTTP has been immensely popular for API creators and callers who wish to maximize flexibility and minimize design time. However, given there are no silver bullets, however, it was only a matter of time until articles like "GraphQL Is Not Meant To Be Exposed Over The Internet" began to crop up.

Written by Wundergraph's CEO/CTO Jens Neuse, there's a fair amount of typical rhetorical devices on display, like "You Ain't Gonna Need It" (YAGNI). However, I strongly agree that we often pick an architectural style before even taking with stakeholders.

I also agree that people picking a GraphQL approach need to understand how the security threat model changes. I won't go so far as to say GraphQL is more demanding to secure than REST-ish APIs. However, it is vital to know how securing a GraphQL API works; from schema traversal to query depth exploitation, there are several new wrinkles a GraphQL provider needs to account for.

MINIMIZING TOIL, MAXIMIZING SIMPLICITY

STRAT / DESIGN / DOC / DEV & TEST / DEPLOY / SECURITY / MONITOR / DISCOVERY

The last piece today isn't a blog post but a Twitter thread. Founder and CEO of PulumiCorp, Joe Duffy, had a great riff about what great API design consists of.

Are you actively working to minimize toil and maximize simplicity in your designs? The whole thread is a fantastic, high-level checklist for anyone working in the space.

MILESTONES

WRAPPING UP

Hey, are you looking for an online professional place to gather with like-minded folks and discuss APIs? Check out the LinkedIn API and Web Services Professional Group.

Also, the list of upcoming API meetups and events that I maintain is looking a bit sparse. If you know of any get-togethers in real space or online, let me know! I'd be glad to get them added.


I'll end, as always, with a thank you to my Patreons! Their support helps keep this newsletter is free of advertising, information selling, or paywalls for everyone's benefit. Excelsior!

Till next time, Matthew

@libel_vox and matthewreinbold.com

While I work at Postman, a utopia where the proverbial salt and pepper shakers are always clearly marked, the opinions presented above are mine.

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe