Add Buffer case study#142
Conversation
jdolle
left a comment
jdolle
left a comment
There was a problem hiding this comment.
Thank you for this. You've provided a lot of useful details for what the requirements are for Buffer's API's, and a few ways in which Hive has helped.
We can publish this as-is and update it later, but I recommend a few adjustments to make it more impactful:
You've done a great job telling Buffer's story, but my personal preference is to structure case studies to highlight problems and solutions. This tends to be easier for interested parties to scan.
You can absolutely be open about areas where Hive has fallen short or why you opted to go a different route. I think these are the most useful cases.
For example, reading this it's clear you have a need to expose multiple subsets of schemas, and you opted to use custom directives rather than Hive's contracts. As a reader, who may want to do the same, why would I opt to go this route? Is this a legacy thing? Are there a details about Hive's implementation that weren't sufficient? Do you plan to migrate in the future?
| comes to making decisions that involve API clients. Some examples of these include: | ||
|
|
||
| - While the API was in Beta, the team needed to migrate the structure of some input types before the | ||
| stable release, and were able to do this without affecting clients. Using Hive, Buffer was able to |
There was a problem hiding this comment.
This is very nice. I'd love to see mention of which features/where you got this info. E.g. Since we send usage data to Hive, we could easily view field insights to get a list of clients still using deprecated fields.
| Buffer wasn't building this from scratch, as there was already an established internal GraphQL API | ||
| powering its own apps, so the work wasn't about creating something new but about getting the | ||
| existing API ready to safely expose to the public. THis shaped a lot of the decisions that followed, | ||
| because opening up something that had only ever been built with an internal audience in mind meant |
|
great points from @jdolle I also know you have a lot more interesting content to share, some thoughts I had:
|
Co-authored-by: jdolle <1841898+jdolle@users.noreply.github.com>
Urigo
left a comment
Urigo
left a comment
There was a problem hiding this comment.
added a few suggestions that don't hold back merging in my opinion!
Excited to get this out there!
|
|
||
| Opening up GraphQL introduces a lot of new attack vectors to account for, because queries can be expensive or malicious in ways an internal-only API never really has to worry about, so Buffer wanted to understand that surface and put the right protections in place before letting anyone in. | ||
|
|
||
| On the security side, Buffer guards the API through a combination of complexity scoring, depth limiting, alias limiting, token limiting, and pagination limiting, which together keep queries within reasonable bounds and protect against both accidental and malicious load. Alongside this, rate limiting takes a tier-based approach that depends on the account's plan, along with a trusted partner status for integrations the team has verified, which lets them apply limits appropriate for different types of access rather than putting a single blanket limit on everyone. |
There was a problem hiding this comment.
This is a super interesting area all by itself!
I'm approving the whole article without it, but if you ever get more time to expand on as much details as you can possibly share here, or even create a new article just on that subject, I'm sure many would benefit from that knowledge sharing!
There was a problem hiding this comment.
@Urigo definitely open to creating a separate article to focus on this section :)
|
|
||
| Beyond the Explorer, having API access to Hive has been essential. Buffer is currently building its own deprecation triaging system to stay on top of deprecations for internal clients, which would have been very difficult without an API. | ||
|
|
||
| Buffer is also missing alerts and proactive monitoring, so right now the team has to check Hive manually when they'd rather get notifications when certain events occur, such as error rate or performance changes. Custom policies would help too, as Buffer has specific standards defined for its GraphQL schema with custom ESLint checks written for them, and without a way to express those in Hive, the team is keeping all its checks in one place for now. |
|
|
||
| Buffer limits requests using complexity scoring, but there's no way to see the complexity score for requests in Hive, so it would be great to be able to configure complexity values and then view that data in Hive alongside everything else. Right now the team tracks this using their own internal solutions, which puts API observability data in more than one place. | ||
|
|
||
| Hive has already improved Buffer's experience when it comes to identifying clients, but the team has run into some limits with how little data there is for each client beyond its name and version. Being able to add extra data or tags to clients, and filter by them, would make the observability even more flexible. |
There was a problem hiding this comment.
maybe we can add GH issues links to each of of these suggestions?
|
|
||
| Hive has already improved Buffer's experience when it comes to identifying clients, but the team has run into some limits with how little data there is for each client beyond its name and version. Being able to add extra data or tags to clients, and filter by them, would make the observability even more flexible. | ||
|
|
||
| There are a couple of oppourtunities for Buffer to utilise Hive features. One is schema checks in Hive, which would mean the team could move away from their own implementation of breaking-change checks in GitHub Actions. The other is building Buffer's own MCP server on top of Hive's API, so that folks inside Buffer can easily get at data about the API through Claude. |
There was a problem hiding this comment.
@enisdenjo maybe also here we could link to an issue about Hive Console exposing MCP
a98fd0c to
490b6bb
Compare
4 participants
Adds a case study for Buffers adoption of Hive. Please let me know if there is any feedback and I can push the changes as required 😊