技术控

    今日:75| 主题:49471
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] Why I believe GraphQL will come to replace REST

[复制链接]
心情简历 发表于 2016-10-6 04:48:14
59 3

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
GraphQLis a product-developer-friendly and efficient method for fetching structured data from a server, designed to be an alternative to REST. It was developed in 2012 at Facebook, has powered the main iOS and Android apps for over four years, and is now used by dozens of Facebook apps on both native and web. Since it was    publicly announcedand open sourced last year, there has been a lot of activity around implementations and tools for different environments and languages. Companies like Pinterest, Intuit, Coursera and Shopify have already adopted GraphQL in their own apps, and a few weeks ago GitHub announced their    new public GraphQL API. I believe this is just the start, and we’ll see a large uptake of GraphQL over the next year.  
  I’ll be speaking at    ReactiveConflater this month about one of the major ideas underlying the many benefits of GraphQL: the use of a type system to expose the capabilities of a server and improve the client developer experience.  
  RESTful APIs are an uneasy compromise

  With REST, there is a continuous tension between efficiently satisfying the data needs of specific clients, and keeping the number of endpoints manageable. The reason for this tension is that a server defines what data an endpoint returns, and the client merely requests it. Especially in mobile apps, the overhead of performing separate requests or of requesting extraneous data is often unacceptable, so we’re forced to add ad-hoc endpoints with custom response structures.
  This means client and server are closely coupled, because changing client data needs require corresponding changes on the server. At the same time, REST doesn’t give us a formal way to coordinate these changes. A major pain point with REST is evolving an API efficiently while still supporting older clients. This often leads to endpoints returning data current clients no longer need, and has the danger of inadvertently disrupting older clients. It may also make client teams dependent on backend teams, slowing down product development.
  Telling the server what you need

  GraphQL is based on one of those ideas that make obvious sense once you hear about it: let clients specify their own data needs against the capabilities exposed by a server. Gone is the mess of relying on an ever expanding set of predefined REST endpoints to cover all bases, because GraphQL exposes one endpoint that returns the exact data you ask for in a single structured response. To make this work, GraphQL defines an    application query language, a language that has been designed specifically for use by product developers.  
  Instead of coordinating requests and stitching together responses from different endpoints, clients now write queries that describe the exact shape of the resulting data they need, and the server builds up a structured response by evaluating the query.
  How types enable coordination

  What underlies this process is that servers define a schema, a type system that precisely describes what data is available to clients. And clients specify the exact structure they want a response to have in terms of this type system.
  The type system thus acts as a formal coordination mechanism between different systems and teams. This also makes it possible to use validation and other powerful tooling to ensure at build-time that requests can be satisfied by the server at run time. The type system can guarantee that the data we access from our code is actually fetched as part of the query we execute.
  As an example of this kind of tooling, I’m currently working on    a native iOS clientthat uses code generation to generate query-specific model types. In effect, this means you can now rely on the Swift type checker to make sure errors in data access show up at compile time. Similar type checks can be performed using Flow or TypeScript for web clients or React Native apps, and I hope to show some early examples of this as well during my talk at ReactiveConf.  
  Supporting evolving data needs

  GraphQL supports continuous evolution of clients over time in a very natural way. If the schema already contains the data you need, no change to the server is required at all. And if you do need to add a field to the schema, this won’t affect existing clients. In fact, at Facebook they’ve been very careful not to introduce backwards incompatible changes to the schema. Amazingly, Facebook’s GraphQL endpoint still supports 4-year old shipped versions of their iOS and Android apps! There are now over 1000 active versions connecting to the same endpoint, without any major issues.
  Again, the use of a type system is immensely useful here, because it allows you to check at build time that changes to a schema are backwards compatible and won’t break older clients. This is something Facebook does as part of their build process.
  We’d like to hear from you!

  I’m excited to be working with GraphQL, and I believe its architecture holds great promise to help improve the developer experience of data-driven apps. Please join me at ReactiveConf or get in touch if you have experiences to share or would like to contribute to the tools we’re working on as part of    Apollo.  
  Note: There are still some    tickets leftfor ReactiveConf. Use coupon    devtofor a 20% discount off the face value. This coupon is only valid for a few more days.
友荐云推荐




上一篇:How We Built Our Own BI: When Off-The-Shelf Apps Won't Do
下一篇:SQL Sentry is now SentryOne
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

liluo1991 发表于 2016-10-6 08:03:08
心情简历的文笔不错!
回复 支持 反对

使用道具 举报

tywgv9trsf 发表于 2016-10-6 11:39:02
一口气看完了,我要去回味回味了!
回复 支持 反对

使用道具 举报

陈勇NikonD40 发表于 2016-11-14 18:04:46
沙发不是你想抢,想抢就能抢!
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表