Net API Notes for 2019/07/18

Hello! I came back from vacation, had a quick tête-à-tête with the team in the east coast office, and now I'm in California for meetings and the APIDays SF conference. I need to pull together my impressions from the event for possible inclusion in a future email. Until then, however, here are the latest Net API Notes!



Phil Calçado knows a thing (or 10) about the backend-for-frontend (or BFF) pattern. While other shops doing similar things, it was his discussion of the pattern during his time at SoundCloud that popularized the approach.

Phil is back with an update. In 'Some Thoughts on GraphQL vs BFF', he breaks down the difference between the Back-end for Front-end (BFF) API pattern and GraphQL. On the surface, there may be confusion as to whether GraphQL is the logical successor to current BFF implementations. However, Phil does a great job of going deeper and illustrating, with nuance, why this isn't the case.

There's also a bit on "the perils of data dictionaries" that had me vigorously nodding in agreement, but your-mileage-may-vary.


Webhooks are an exiting pattern for providing more realtime driven behavior to a system without resorting to polling. However, while the benefits may be obvious, how to secure webhooks may be less so. After all, the last thing a company needs is to open up another attack vector for a future DDOS attack.

Lorna Mitchell, in her talk, 'Using Message Signatures to Ensure Secure Incoming Webhooks' provides the details on what she has seen be successful. I love this piece; the solution is straightforward and practical, and Lorna's writing is a delight. While the piece is Nexmo-specific, the process could be abstracted to any platform looking to provide webhook support in the future.


I was going to put Troy Hunt's exhaustive write-up about changes to the 'Have I Been Pwned' API in the 'Milestones' section. However, Troy is a fascinating storyteller. Reading Troy's accounts as his service has scaled to new heights has been enlightening, with numerous practical lessons on CDNs, Azure cloud services, and K-anonymity, for example. This latest piece on the decision to require authentication for the API is no different.


There's an intriguing tiff going on at the moment between the exercise tracking company, Strava, and workout-recap-movie-generation service, Relive. Strava, you might remember, got into PR trouble last year when some clever folks realized you could use data, through its API, to identify secret US military bases ("Hey, why are all these accounts of fit military folks running the same circles in the desert?") So Strava is, undoubtedly, a bit touchy.

The saucy nuance here is who owns the data? Is it Strava, so they are within their rights to restrict access? Or is it the user, who should be able to export it (via API) to a service like Relive? Even if you aren't into the 'quantified self' thing, how this ultimately resolves could have ramifications for the much larger industry.


WRAPPING UP has a newsletter that, recently, celebrated *the 100th edition of this here newsletter. I, honestly, hadn't been keeping count and the total surprised me a bit. I paged through the newsletter archive, and I think this is 104th email. Regardless of the exact number, however, I appreciate the shout out.

As I mentioned at the top, I'm in San Francisco this week and spoke at the APIDays conference. I've posted my script and slides on my website. This was a fun one to put together, combining my software reading of the last six months to last years focus of study, Pace Layers. It is the 3rd of "6 talks in 6 months".

If you are looking for an in-person soiree, check out another site that I update, If you have a meetup, hackathon, or conference you don't yet see listed there, shoot me an email and I would be happy to add it.

Thanks for reading. Till next time,

Matthew @libel_vox and

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.