recentpopularlog in

versioning

« earlier   
Staying on Top of Changes in GraphQL | GitHub Developer Guide
"Staying on Top of Changes in GraphQL
May 3, 2018 xuorig
To provide a more seamless experience we prefer to continuously evolve our schemas rather than using API versioning. Continuous evolution allows us to iterate faster and provide our integrators with new schema members more often. We do our best to avoid breaking changes, but sometimes it's necessary to offer an unversioned API.

We strive to provide the most stable APIs to our integrators and to provide transparency about new developments. This is why we recently shipped the brand new Breaking Changes page, which announces future breaking changes to our GraphQL schema.

Internally, our engineers mark certain schema members as deprecated using a Ruby API on top of the graphql-ruby gem. Using the changes metadata provided by our engineers, we automatically compute removal dates and generate this breaking changes page, meaning you'll always get up to date information."
github  graphql  versioning  schemas  apis  omgwtf 
2 days ago by earth2marsh
Breaking Changes | GitHub Developer Guide
"Breaking changes are any changes that might require action from our integrators. We divide these changes into two categories:

Breaking: Changes that will break existing queries to the GraphQL API. For example, removing a field would be a breaking change.
Dangerous: Changes that won't break existing queries but could affect the runtime behavior of clients. Adding an enum value is an example of a dangerous change.
We strive to provide stable APIs for our integrators. When a new feature is still evolving, we release it behind a schema preview.

We'll announce upcoming breaking changes at least three months before making changes to the GraphQL schema, to give integrators time to make the necessary adjustments. Changes go into effect on the first day of a quarter (January 1st, April 1st, July 1st, or October 1st). For example, if we announce a change on January 15th, it will be made on July 1st."
github  changes  apis  breaking  versioning  graphql  omgwtf 
2 days ago by earth2marsh
GraphQL Best Practices | GraphQL
"Versioning
While there's nothing that prevents a GraphQL service from being versioned just like any other REST API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.

Why do most APIs version? When there's limited control over the data that's returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.

In contrast, GraphQL only returns the data that's explicitly requested, so new capabilities can be added via new types and new fields on those types without creating a breaking change. This has lead to a common practice of always avoiding breaking changes and serving a versionless API."
versioning  apis  graphql  schemas 
2 days ago by earth2marsh
Why The New York Times TL;DR’d its own 14,218-word Trump investigation » Nieman Journalism Lab
at the same time that it published the investigation that was a year in the making, it also aggregated itself — publishing “11 takeaways from the Times’s investigation into Trump’s wealth.” The TL;DR version is by the same authors as the full investigation (Russ Buettner, Susanne Craig, and David Barstow), and, at over 2,500 words, it’s pretty much a longread of its own. There’s also this much shorter interactive version, with audio and video.
longform  listicle  nytimes  interactive  versioning  chunking 
13 days ago by paulbradshaw
Versions — Git for Designers
Система версионирования макетов и шаблонов для дизайнеров от Sympli. Её анонсировали в прошлом году, теперь она доступна для всех.
UX  collaboration  versioning  tools 
14 days ago by jvetrau

Copy this bookmark:





to read