Recently, Twitter has started to rely on GraphQL to provide backend data, so that client engineers are able to quickly build on the mobile and web apps. As implementers of the v2 Twitter API, we wanted to be able to leverage the same GraphQL backend, so that both the clients and the API share the same underlying data graph. This means the public API can remain consistent with client behavior, and gives our external developer community the same experience via a stable REST API. We’ve found that GraphQL and OpenAPI can complement each other to reduce inconsistencies and duplication of work.
In order to see these benefits, we built a platform layer that lets us easily take existing Twitter data and expose it to external developers. The platform requires minimal configuration from internal teams via a standard set of components, and is then able to build GraphQL queries and configure REST endpoints that use those queries to return data. With this platform layer, we are also able to codify our API design, and our end result is a consistent developer experience.
Additionally, we use the set of configuration components to generate the OpenAPI spec. This has reduced the workload for internal teams as well as reduced the inconsistencies between handwritten OpenAPI specs and endpoint behavior due to human error. As a bonus, we also use tooling provided by existing OpenAPI libraries to help with request validation on the platform. The same OpenAPI spec is also published to our users, so they can utilize it in any tools that work with OpenAPI.
