TK WIP TODO finish this intro. Depending on the size of an organization, there are usually existing practices surrounding the management of the data

While it makes an excellent longer-term goal, GraphQL doesn’t need to stand above the entire data tree in an organization in order to provide value and expending large amounts of engineering effort to switch an entire stack should generally be avoided.

Unlike some technologies, which are difficult to embrace without getting buy-in from all the teams in an organization, GraphQL can be utilized by smaller units (e.g. component by component, team by team) and later integrated into the bigger picture.

Thanks to GraphQL’s ability to fetch data from any data source, it makes sense to keep existing APIs as they are and use GraphQL to “wrap” the data. This can be appreciated by organizations with existing collections of REST (or similar) APIs which power their user experiences since they can lean heavily on their existing investments. This allows small teams to immediately realize many benefits of GraphQL without waiting for deeper adoption and allows existing versions of the application, which have already been deployed and rely on the existing API, to keep functioning uninterrupted.

APIs change as the products which use them evolve and their ideal structure is usually defined by the front-end applications which consume them. While it’s certainly possible, and sometimes desirable, to have a single GraphQL schema which blankets an entire organization’s operational concerns, trying to manage a large schema presents challenges which are avoided by separating the schema into more manageable pieces that align with individual products.

Organizations looking to offer a single API endpoint can assemble the individual product schemas, managed by individual product teams into a monolithic API by “stitching” the various schemas together.

An API implemented using GraphQL allows developers to query the exact information they desire from an API and nothing more. With proper visibility into how the API performs, developers can understand the implications of adding or removing fields, especially those which might be slow (notoriously or otherwise!).

This clarity allows pushing schema changes to production with the confidence of knowing that the API is performing as well as it was before, if not better!

Facebook's reference implementation has been written in JavaScript since its original release and fresh developments in the GraphQL ecosystem have frequently appeared first in JavaScript or languages which transpile to JavaScript, like TypeScript.