17 ms·

John Resig: Introducing the GraphQL Guide

506 points by sbr464 8y ago

drcode 8y ago
Good on him to be so flexible- I don't know that much about John Resig, but he was clearly a pioneer with jquery+rest, so it's great to see him being equally enthusiastic about a project based on graph query languages and React, arguably replacements for this earlier tech!
- polynomial 8y ago
  He always said JQ was only a temporary solution.
- thinkingkong 8y ago
  REST was Roy Fielding but I agree. Much like the concept of Apache Cordova, the best jquery would be no jquery at all.
  - gkoberger 8y ago
    John didn't invent REST (nor AJAX), however jQuery made it feasible and easy for people to use. Yes, you're right, the best jQuery would be no jQuery. jQuery was basically a prototype for the next generation of browser features.
    - benatkin 8y ago
      It didn't encourage REST either. It provided $.post but not $.del (since delete is a keyword in JavaScript) so one could even say it went against REST. I think it was orthogonal to REST, though. Here's the docs for jQuery 1.3 from when REST was starting to take off, with jQuery.post but no delete method: https://api.jquery.com/category/ajax/shorthand-methods/ https://api.jquery.com/category/ajax/shorthand-methods/
      - anothergoogler 8y ago
        REST had taken off before jQuery existed.
      - abritinthebay 8y ago
        It provided $.ajax({method: “DELETE”}) however... so...
        anothergoogler 8y ago
        Making a DELETE XHR was never the issue, browser support was. It's an issue that was impossible to paper over with a JS library alone, you needed backend integration. That's why Rails and similar frameworks at the time spoofed DELETE and PUT requests by creating a POST request with a special param set.
        benatkin 8y ago
        It was also an issue on backends. Backbone had an emulateHTTP option: http://backbonejs.org/#Sync-emulateHTTP http://backbonejs.org/#Sync-emulateHTTP
        abritinthebay 8y ago
        All browsers supported the verbs for years. IE7 had mostly full support (not PATCH though, annoyingly). The problem was mostly backend related: most servers didn't support them. DELETE for example has been supported for over 12 years in all major browsers.
        anothergoogler 8y ago
        Ah, interesting, my memory is dusty. Now that I think about it, the limitations of <FORM> were front and center too: A Rails app wanted a "delete $X" page that didn't rely on JS, and the only way that was going to happen was with a <FORM>, which only supports GET and POST methods.
        8y ago
wwweston 8y ago
As I often do with new-ish things these days, I've been quietly weighing what degree of investment I want to put into GraphQL for a year or so. John's vote of confidence means a lot to me. The software industry has lots of abstractions that are different ways of arranging the chairs on the deck, shuffling the work around while providing marginal productivity magnifiers. jQuery's been somewhat superseded because it isn't an application-organizing framework, but it's still one of the best conceived and fitted abstractions for the problems it was meant to solve I've encountered in the entire time I've worked in software. If the person who conceived it thinks GraphQL yields productivity benefits, then I want to check it out.
- sbr464 8y ago
  I agree. I think it's good for the overall GraphQL community to have John's support. I purchased the book out of support for his work mainly, but I know it will be a good read as well.
- wnevets 8y ago
  >John's vote of confidence means a lot to me. by selling a $80 book?
  - tomnipotent 8y ago
    Considering the street cred John has earned for creating jQuery, it says a lot for him to endorse GraphQL and to even write a book about it.
  - sigzero 8y ago
    It starts at $39. So just like a book?
- acjohnson55 8y ago
  I personally strongly believe so: http://artsy.github.io/blog/2018/05/08/is-graphql-the-future/ http://artsy.github.io/blog/2018/05/08/is-graphql-the-future... Don't get me wrong, some aspects of today's GraphQL are still a little rough around the edges, but I think it's a strong pointer towards the future of service integration.
tfigment 8y ago
Hate to complain about GraphQL in general and not specifically this guide but I ran into to major issues with it and really wanted to like it but ultimately gave up on it until they fix some core issues. I don't see how I can implement complex object hierarchies that are not rigid. Only list is supported as an unbounded data type and for some reason there is no unbounded map/dictionary data type even with simple restrictions like requiring string key type. There is not even good advice on what key/value pair naming convention should be for all languages. The other is that there is very poor support for more general include/exclude/where filters. The idea being arbitrary complex join/filter clauses to function like sql statement with multiple joins and where clauses. Have to rely on implementation specific conventions like what sequelize does to get that but not for arbitrary object graphs. Solve some of this and it might actually become as powerful as it is frequently claimed to be.
- maktouch 8y ago
  Hmm, our API is pretty big and we never had an issue where GraphQL couldn't solve it (https://player.me/api/graphiql https://player.me/api/graphiql) > I don't see how I can implement complex object hierarchies that are not rigid. I'm not sure I understand what you're trying to do, but did you try the JSON scalar type? https://github.com/taion/graphql-type-json https://github.com/taion/graphql-type-json With that, it just returns JSON but you can't pick and choose what keys gets returned. We never had to use that though. We prefer to use interfaces or unions.
  - tfigment 8y ago
    My understanding is the json type stuff is a language specific workaround and not part of the standard. I have .NET, go, node.js, and others and while I could make any one of those languages work with specific changes they would not necessarily inter-operate for free or per the standard. I would hate to build heavily on workarounds that I feel should be in-built. At some point we just reinventing the wheel but in a more fragile way. I dont believe the arbitrary json was in the .NET version I was using which is what would expose data to be consumed via node.js (and other .net clients). Frankly it was easier to just implement a simple rest api that did exactly what was expected. What I sort of what is to be able to craft a query against a large set of objects like a customer/location/asset hierarchy and filter on different levels like sql query without it being in a database. I might have 10 different orthogonal dimensions with foreign keys than can be returned and filtered against. I'm trying to avoid pulling the complete object hierarchy only for it to filter out some of the data after the fact and then finally return the expected json format. Accessing some objects might be very expensive so being able to filter data as part of the query request rather than afterwords would speed things up. These actions are usually quite hard to do in libraries I've used. Maybe if you only use javascript/node.js, I don't know its not what I've need to start with. I may have misinterpreted what GraphQL was for if it is not for querying nearly arbitrary object graphs and returning json that the client wants returned.
westoncb 8y ago
Anyone know what framework the book uses (if any)? I tried doing a GraphQL project in Python/Django recently, using Graphene for the GraphQL bits. I didn't end up getting that far because the documentation was so lacking, as were examples generally (for graphene-python I mean; I could find stuff on GraphQL in the abstract). I'm thinking about giving it another shot, maybe on node.js this time, largely because I get the impression that the supporting tech for it is more mature there—but I'd love to hear opinions on what the most mature lib for using it is at the moment (whatever language)!
- sbr464 8y ago
  From what I've seen by glancing through, it's mostly JS -- Node.js (express-graphql), React, and packages from the Apollo GraphQL team (react-apollo). I've been using these over the last year and can recommend checking them out.
- mazlix 8y ago
  I believe the book is all in NodeJS. As for the most mature lib, I’d say Apollo.
  - westoncb 8y ago
    Apollo is client-side though, no? I mean for integrating with server code.
    - sbr464 8y ago
      The Apollo team has apollo-server and apollo-engine-js. I've had good results with both of those.
- lorendsr 8y ago
  It's node: `apollo-server-express` https://www.apollographql.com/docs/apollo-server/ https://www.apollographql.com/docs/apollo-server/
- tlrobinson 8y ago
  It says right there in the post: "We’ll be looking at the core fundamentals of GraphQL along with strategies for how to implement it (client-side with Apollo and server-side in Node.js)"
maktouch 8y ago
We deployed our GraphQL July 4th 2016. It'll almost be 2 years. Documentation sucked back then (and apollo was non-existent), so a lot of we had to dig by ourselves. I hope this book will cover some topics for others that was real head scratchers for us - DataLoaders - Authentication example - Unions and Interfaces are your friend. Use them early. - Try to define your custom Scalars early (especially DateTime format) - return Connections (edge/node) instead of List cause you probably want to paginate at some point - Folder structure (we redid ours 4 times lol) - Naming convention (we redid ours 3 times lol) - Subscriptions After 2 years of using it and hacking it, we're still impressed. Once you get past the learning curves and have set conventions, writing GraphQL is a lot faster and better. Define your types, and some custom root queries, and done. The neatest thing is that we made a schema validator -- compile all the graphql queries from the frontend and mobile, and validate them against the server schema. It really help when we changed folder structure and naming convention to see if we'd break something on the frontend. I can't vouch for this book yet, but I'll swear my life on GQL. It's been a real game-changer.
- dev1n 8y ago
  Regarding folder structure, we developed saturn-gql [1] to help out with that. Have a look if you're still battling this. [1]: https://github.com/electric-it/saturn-gql https://github.com/electric-it/saturn-gql
  - maktouch 8y ago
    Hey, that's cool! Thanks for that, will try it out on a new service/pet-project one day. In our current service, I think we're pretty happy with the way our structure is. It's almost similar to saturn-gql but with raw javascript instead of parsing with `graphql-tools`.
- misschresser 8y ago
  I'd be curious to hear more on your schema validator. We've been using GQL for a little over a year and have felt some serious pain when doing big shifts in our GQL layer and even just when we're trying to clean out dead code / assess which resources are being used in which FE apps.
jsnk 8y ago
I hope John will divide up the book later. I am interested, but as a guy working more on backend systems, frontend and mobile will not help me very much. I don't want to pay $40 for majority of content I cannot make use of.
- pofilat 8y ago
  It isn't $40 for content you don't use; it's $40 for the content you do use.
- kbutler 8y ago
  Smaller computer books tend to not be mich cheaper. So the majority of the cost is for the minority of the content you want. Maybe $10 for the rest of the content you may want someday.
simplecomplex 8y ago
Why spend time building an API at all? Just point Postgrest at your PostreSQL database and you get a REST api for free. There’s similar projects for graphql and other DBs.
- stuartaxelowen 8y ago
  Totally agree. Sprinkle in some row level security and you've got an app server with data isolated at the DB level, and get the power of SQL for building out endpoints. Compared to this graphql feels a little like engineering theatre.
  - CodesInChaos 8y ago
    Which leaks a lot of implementation details through the public API, preventing changes without breaking existing clients. Which in practice means that you can't change anything anymore once you have more than a handful of customers. At least if you don't have the market power of a facebook who can say "Adapt your client code or it'll stop working. We don't give a fuck." Another big issue is that it forces the client to understand a lot about how your application works. While an API can abstract that and conveniently offer various computed properties which output what the client needs.
- lsorber 8y ago
  Anyone from the GraphQL camp care to weigh in against this argument?
  - tzahola 8y ago
    If your endpoints are backed 100% by a db, then you can get by with the postgrest approach. However GraphQL resolvers can do much more beyond a simple DB query. E.g. you can call other services and combine their reponses. Or calculate the n-th digit of Pi. Or whatever you want to do.
    - steve-chavez 8y ago
rapfaria 8y ago
Why is rate limiting only part of the $289 package? Edit: And wasn't it cheaper earlier? I was pretty sure it was $29 for the basic version, maybe that rounding up market trick got me.
rhacker 8y ago
The author and his introduction definitely has a compelling story to tell. It is making re-think our recent strategy shift in which we evaluated GRPC and GraphQL. We chose GRPC but I'm starting to see that it's not really any better than REST + Swagger. I think I might need to actually just go ahead and buy this book and re-think if the GRPC route is worth it. Our investment in Grpc at this point has been slow - mostly because I figured the Grpc-Web project would be moving a lot faster by now. It's not and I don't see the team doubling down, whereas it looks like Apollo and GraphQL seems... ready now. Edit: Does anyone know if he goes over typescript?
- sbr464 8y ago
  No TypeScript on basic search currently, but book is not finished, can’t speak for the author.
- lorendsr 8y ago
  Would definitely recommend GraphQL over GRPC! We'll go over how to generate types or add them manually, but the rest of the book is in ecmascript.
- andrewingram 8y ago
  When I interviewed at Improbable (authors of gRPC Web) last year, we spoke a little about gRPC and GraphQL. The interviewer didn't really explain their choice beyond the fact that half the company came from Google and were already fans of gRPC.
dudus 8y ago
I want to buy it but feel annoyed by these payment options. Tier 1: $39 - Full book when released and early access Tier 2: $89 - Tier 1 + updates for 2 years + extra chapters Tier 3: $289 - Tier 2 + free updates for life + more extra chapters This is an oversimplification with only the things I care about. The actual packages include more stuff. What really annoys me is why would you call tier 1 the full book and say tier 2/3 has "extra chapters". I just want all the chapters + early access + updates (2 years is fine). And I want to pay less than $100. Am I being too entitled? Buying books used to be simpler.
- Void_ 8y ago
  Some 10 years ago I bought a huge book about Ruby on Rails for $50. It had at least 400 pages. This last week I ordered "App Architecture", also for some $50, and I was amazed by what I got - a tiny book that fit in a small envelope... And now $89 for a PDF?? I love books, but no thank you.
  - bryanrasmussen 8y ago
    which of those two books was better though? if I'm getting a voluminous tech book with a generic 'name of technology' title it's a pretty safe bet that a third of it is useless to me.
  - intrasight 8y ago
    If you considered it an online training course vs a book, would you consider it a fair price?
    - jhall1468 8y ago
      No, because an "online training course" in full text is a book.
- blub 8y ago
  Yes, it's like some horrible IAP concept for books. Normally a technical book costs around 40-60 EUR and one gets all the chapters. Updates are called "editions" and are published when there's demand and the information has become outdated.
nsstring96 8y ago
One of the problems I've noticed while using GraphQL (late last year) was that although there are 'officially supported' libraries in a number of languages, there isn't really feature parity between them. In particular, I remember that the Ruby implementation we were using required manually parsing the AST to do fairly basic operations described in the spec. I wonder if this situation has improved in the last few months.
zumu 8y ago
Is Apollo the be all end all GraphQL client these days? I tried it roughly 1.5 years ago and was turned off by all the component wrapping. Is it bad form to just fetch data via GraphQL and put it in Redux (or other store)? I'd like to buy in, but I'd like to keep my data fetching separate from my view layer if possible.
- lorendsr 8y ago
  Apollo has been in the lead for a while—it currently has 125k weekly downloads on npm, vs Relay's 20k. You can use the new render prop API instead of the HOC API if you don't like wrapping. The data fetching itself is separate from the view layer—it's all done by Apollo. From a maintenance perspective, listing data needs is great to have in the view layer, colocated with the components that use them. You can manually fetch data via GraphQL and put in Redux, but there are a ton of benefits to having a library like Apollo manage the store for you. Automatic normalization, querying from either store or server (or both), optimistic mutation updates, etc.
- maktouch 8y ago
  While transitioning away from Redux, we actually fetched Data via GraphQL and put it in stores. Honestly, it was a pain, but it's because we abused Redux. We progressed by doing the HOC and bypassing Redux but it still was a pain, because HOC. We're now at a stage where we updated Apollo versions, and started converting to the Query components. It feels and work a lot better. When we started, we thought the same thing -- keeping data fetching separate from the view layer if possible. We realised that it didn't make that much sense. Keeping everything in React components is a lot more maintainable and easier to comprehend.
- jlu 8y ago
  Fellow redux-abandoner here, be sure to check out Apollo client v2 and it’s various middleware options like link-state and link-rest, those in essential let you pull in data via graphql and REST-api and manage it via in memory store (just like redux store). Also the subscription via websocket story there is really sweet, you basically get real-time update for nothing ;) In short, just as John stated, it’s a huge boost of productivity on both front and backend, we verified it ruthlessly and love it.
tpetry 8y ago
Call me old school but i like my books printed and with on-demand printing services its not conplicated for a publisher. Can‘t read hundreds of pages on a screen... But without seeing the content the pricing looks insane. It has to be worlds better than online resources for 289$ (!).
- Hendrikto 8y ago
  The 39$ version would be closest to an actual book. You get every chapter once the book is finished, and that’s that. The more expensive versions include updates and additional features.
  - sakarisson 8y ago
    Every chapter except the extra chapters included in the more expensive options.
TeeWEE 8y ago
While GraphQL has it uses, i can't seem to see how putting the query logic in your frontend is a good thing: How do you control scaling, and writing performant queries? When you make an API endpoint you have control over the queries you make and how you make them. With GraphQL you lose that control right? Maybe its good for internal projects, where you own the client and server. But often just exposing the internal DB directly to GraphQL is probably not a good idea. Maybe writing the DataLoaders yourself is better. But then you are already close to the effort of writing a simple endpoint. For simple API's graphql seems like overkill.
- sbr464 8y ago
  With GraphQL you have the flexibility to utilize both REST and RPC patterns, with the added benefit of a type system and ability to choose the fields returned on the client. You can write common CRUD queries/mutations similar to how you would with REST (allUsers/allProjects. If you have a query that you know ahead of time will be inefficient, you can add in a more RPC or dedicated endpoint style query that you can optimize how you see fit on backend (getAllCrazyThings(filters) etc). For the performance aspect, check out Apollo Engine, which allows you to track the latency and implications of using different fields within your queries and mutations over time: https://www.apollographql.com/docs/engine/performance.html https://www.apollographql.com/docs/engine/performance.html
- true_religion 8y ago
  GraphQL endpoints are API endpoints. You have to write the resolver yourself, which will do things like query the DB. GraphQL is just a schema specification like Swagger. It doesn't come with a server or a client. Those are implementation details left up to you, just like in REST.
GedByrne 8y ago
I think he is making a mistake selling this as a book. These prices just don’t work for a book. He should be selling it as a knowledge community. Members get access to the resources, conversations, training, etc. Add levels of membership that have to be earned through merit somehow and membership at a higher level becomes valuable on the CV.
neoeldex 8y ago
Why is all the GraphQL documentation so tightly coupled with either Apollo or Relay? Apollo doesn't work nice with a non-react setup (imhe), not to start about Relay itself. All the Relay server side stuff makes the client also really boilerplaty. I don't think i'd buy this book, since it's also apollo stained. Does someone have good resources on how to use vanilla GraphQL without the bloated Apollo/Relay stuff? I'm currently working on a GraphQL server (using Graphene), and thankfully I'm able to not use Relay (with which it tightly integrates). So I'm able to implement my own pagination and filters.
- Waterluvian 8y ago
  Also if it's the new REST then it absolutely cannot be language specific, let alone library specific.
- andrewingram 8y ago
  Relay (Modern) doesn't require any of the Relay-specific schema patterns. But most of them (connections, the node interface) are useful enough to want to use anyway. That said, I agree that too much of the documentation/articles/tutorials about how to use GraphQL assumes using a particular implementation. I'm far more interested in talking about higher-level concerns like best practices and data modelling.
- lorendsr 8y ago
  Chapters 1-5 are apollo-free! And the queries and mutations used in the apollo client chapters are applicable outside apollo.
Dowwie 8y ago
Adopters of GraphQL are quick to call it game-changing, but is it a game worth playing? It has to add value above the standards already in place. Is it accomplishing that? How is it more valuable than whatever it is that it replaces (REST, whatever)?
- worldsayshi 8y ago
  I think I came to this conclusion the other day: GraphQL truly shines when the variation of ways that you want to access data is significantly more complex than the complexity of the stored data. In other words, if you want to look at 10 tables in a twenty or forty or more different views (counting the times when a view is composed into another), then I believe using GraphQL will begin to show order of magnitude efficiency rewards. If the number of views is only slightly more than the number of tables then the rewards are more a matter of taste. It will give you a nice typed interface to your data and an interactive query GUI. But other tools provide that as well.
  - dmitriid 8y ago
    > if you want to look at 10 tables in a twenty or forty or more different views (counting the times when a view is composed into another), then I believe using GraphQL will begin to show order of magnitude efficiency rewards. How will it show order of magnitude efficiency?!! It means that you will have 20-40 views towards a database that only contains 10 tables. Which will inevitably result in highly inefficient queries towards said database. Especially if a view is composed into another. There's no magic in GraphQL that suddenly makes that go away.
    - Chyzwar 8y ago
      Imagine you have a cross-platform app with multiple teams. You have a lot of data-driven components like different feed types. You want to avoid situations that change in backed API needs to be synced with every team/app. You want to give power to app developers to define efficient queries. Unless you develop multiple apps or data-driven application there is very little reason to use GraphQL. Personally, I am in favor of building two APIs: public/third party REST and JSON-RPC for the frontend. Getting REST right is difficult and after you create your resources your frontend needs to workaround incomplete/superfluous data.
sakarisson 8y ago
So let me get this straight. For the low price of $39 I will get the full book in ebook and HTML formats when it is done. But for the price of $89 I will get extra chapters on Server-side rendering, Offline data and mutations, Serverless and Stripe integration. So I am clearly not getting the full book for $39. I just recently refused to buy a game for employing the same dishonest sales tactics, so this is an easy no thanks from me.
- tgtweak 8y ago
  Day-0 DLC has arrived to technical literature. John really is ahead of the curve.
  - btown 8y ago
    Errata can only be accessed via microtransactions. And loot boxes have a chance to drop full code samples... the F2P version leaves everything as an exercise for the reader.
    - ygjb 8y ago
      Oh, oh no. There is a missed opportunity here. Common lootboxes drop a line of code, uncommon an entire method, rare, a full object, and legendary are working samples.
      - btown 8y ago
        Hmm, you know, people want to forge their own legendary objects. Double the drop rate on working samples, but they’re obfuscated until you collect 3 of each code block. And you can sacrifice 10 useless one liners to be able to discover a block of your choice.
  - rapfaria 8y ago
    And if he takes as much time as he took with "Secrets of the JavaScript Ninja", we may never even see DLC
- 8y ago
nek4life 8y ago
I'm skeptical that this book will ever be finished. The last time I bought an unreleased book authored by John Resig it took two and a half years before it was published. If I remember correctly another author had to take over in order to complete it. I'm super interested in GraphQL, but I wouldn't consider purchasing this ebook until it is 100% complete.
codingdave 8y ago
If nothing else, the conversation around this has shown that applying a subscription-based, tiered pricing model to a book is not appreciated by the consumers.
- nkassis 8y ago
  I think it's against the usual expectation for a book. If they had split it into volumes then it would have matched better people's expectations. Also the videos and extra should be part of a course package. Messaging just make it sound like you are getting short changed.
dmitriid 8y ago
> The end result is a vastly simplified backend GraphQL specs offer none to zero of the following: - caching - authentication, authorization and handling data access - protections against ad-hoc arbitrarily nested and complex queries - routing How does this “vastly simplify the backend”? If anything, it makes the backend hideously complex (IIRC Apollo’s approach to caching is parsing requests and responses every time, do some magic, and handle caching manually).
ozten 8y ago
Once you pay $39 you have to Github OAuth to receive the book. Currently, there are no other authentication options. Just an FYI as I didn't know that before I had paid.
snarfy 8y ago
Why should I use Facebook's GraphQL over OData which is an ISO standard? I've found a few comparisons but I'm curious what the HN crowd has to say.
- nkassis 8y ago
  Feels like GraphQL has more momentum behind it now than OData. OData seems to have suffered from the fact that it originated in the .Net world which is pretty much ignored by those outside of it.
pier25 8y ago
> GraphQL offers a way to push all of the logic for specifying data requirements onto the client, and in return, the server will execute the (highly structured) data query against a known schema. The end result is a vastly simplified backend that also empowers the client to execute whichever queries they need. Why is empowering the client a good thing? Why is moving complexity from the backend to the front end a good thing?
- williamdclt 8y ago
  because the client knows exactly what it needs and it makes abstracting the data-fetching pretty easy
- kbutler 8y ago
  Because you can have one server efficiently servicing multiple clients with different, unanticipated needs.
  - pier25 8y ago
    So, reducing server load? OTOH if the complexity is offset to the client, and you have multiple clients, then there is more complexity. No? (assuming you have multiples types of clients)
    - kbutler 8y ago
      It allows a server produced by one organization to provide an API that remains efficient for future clients produced by other organizations without either changing the API to meet the needs of the other clients or anticipating every client's needs. More to be economical in API design, rather than just server load and bandwidth.
    - sken 8y ago
      But the client already had to consider what data it needed. The only difference is that in a REST world it needed to make several calls to fetch all the data (often waiting for resource references in the nth response before being able to build the (n+1)th query) whereas now it can fetch them all in a single query. So if anything it reduces the client complexity, as well as making it much easier to extend the API to support new client requirements without having to resort to REST-style versioning.
ilaksh 8y ago
Looks nice but why would I use GraphQL over JSON queries to a simple document database directly? I guess it comes down to how important schemas are to you. Which I know suggesting they might not be important sometimes is for some people a sin punishible by death. But for me that's a belief system that doesn't hold up for everyones application.

506 points by sbr464 8y ago

Good on him to be so flexible- I don't know that much about John Resig, but he was clearly a pioneer with jquery+rest, so it's great to see him being equally enthusiastic about a project based on graph query languages and React, arguably replacements for this earlier tech!

polynomial 8y ago
He always said JQ was only a temporary solution.
thinkingkong 8y ago
REST was Roy Fielding but I agree. Much like the concept of Apache Cordova, the best jquery would be no jquery at all.
- gkoberger 8y ago
  John didn't invent REST (nor AJAX), however jQuery made it feasible and easy for people to use. Yes, you're right, the best jQuery would be no jQuery. jQuery was basically a prototype for the next generation of browser features.
  - benatkin 8y ago
    It didn't encourage REST either. It provided $.post but not $.del (since delete is a keyword in JavaScript) so one could even say it went against REST. I think it was orthogonal to REST, though. Here's the docs for jQuery 1.3 from when REST was starting to take off, with jQuery.post but no delete method: https://api.jquery.com/category/ajax/shorthand-methods/ https://api.jquery.com/category/ajax/shorthand-methods/
    - anothergoogler 8y ago
      REST had taken off before jQuery existed.
    - abritinthebay 8y ago
      It provided $.ajax({method: “DELETE”}) however... so...
      - anothergoogler 8y ago
        Making a DELETE XHR was never the issue, browser support was. It's an issue that was impossible to paper over with a JS library alone, you needed backend integration. That's why Rails and similar frameworks at the time spoofed DELETE and PUT requests by creating a POST request with a special param set.
        benatkin 8y ago
        It was also an issue on backends. Backbone had an emulateHTTP option: http://backbonejs.org/#Sync-emulateHTTP http://backbonejs.org/#Sync-emulateHTTP
        abritinthebay 8y ago
        All browsers supported the verbs for years. IE7 had mostly full support (not PATCH though, annoyingly). The problem was mostly backend related: most servers didn't support them. DELETE for example has been supported for over 12 years in all major browsers.
        anothergoogler 8y ago
        Ah, interesting, my memory is dusty. Now that I think about it, the limitations of <FORM> were front and center too: A Rails app wanted a "delete $X" page that didn't rely on JS, and the only way that was going to happen was with a <FORM>, which only supports GET and POST methods.
        8y ago

wwweston 8y ago

As I often do with new-ish things these days, I've been quietly weighing what degree of investment I want to put into GraphQL for a year or so. John's vote of confidence means a lot to me. The software industry has lots of abstractions that are different ways of arranging the chairs on the deck, shuffling the work around while providing marginal productivity magnifiers. jQuery's been somewhat superseded because it isn't an application-organizing framework, but it's still one of the best conceived and fitted abstractions for the problems it was meant to solve I've encountered in the entire time I've worked in software. If the person who conceived it thinks GraphQL yields productivity benefits, then I want to check it out.

sbr464 8y ago
I agree. I think it's good for the overall GraphQL community to have John's support. I purchased the book out of support for his work mainly, but I know it will be a good read as well.
wnevets 8y ago
>John's vote of confidence means a lot to me. by selling a $80 book?
- tomnipotent 8y ago
  Considering the street cred John has earned for creating jQuery, it says a lot for him to endorse GraphQL and to even write a book about it.
- sigzero 8y ago
  It starts at $39. So just like a book?
acjohnson55 8y ago
I personally strongly believe so: http://artsy.github.io/blog/2018/05/08/is-graphql-the-future/ http://artsy.github.io/blog/2018/05/08/is-graphql-the-future... Don't get me wrong, some aspects of today's GraphQL are still a little rough around the edges, but I think it's a strong pointer towards the future of service integration.

tfigment 8y ago

Hate to complain about GraphQL in general and not specifically this guide but I ran into to major issues with it and really wanted to like it but ultimately gave up on it until they fix some core issues. I don't see how I can implement complex object hierarchies that are not rigid. Only list is supported as an unbounded data type and for some reason there is no unbounded map/dictionary data type even with simple restrictions like requiring string key type. There is not even good advice on what key/value pair naming convention should be for all languages. The other is that there is very poor support for more general include/exclude/where filters. The idea being arbitrary complex join/filter clauses to function like sql statement with multiple joins and where clauses. Have to rely on implementation specific conventions like what sequelize does to get that but not for arbitrary object graphs. Solve some of this and it might actually become as powerful as it is frequently claimed to be.

maktouch 8y ago
Hmm, our API is pretty big and we never had an issue where GraphQL couldn't solve it (https://player.me/api/graphiql https://player.me/api/graphiql) > I don't see how I can implement complex object hierarchies that are not rigid. I'm not sure I understand what you're trying to do, but did you try the JSON scalar type? https://github.com/taion/graphql-type-json https://github.com/taion/graphql-type-json With that, it just returns JSON but you can't pick and choose what keys gets returned. We never had to use that though. We prefer to use interfaces or unions.
- tfigment 8y ago
  My understanding is the json type stuff is a language specific workaround and not part of the standard. I have .NET, go, node.js, and others and while I could make any one of those languages work with specific changes they would not necessarily inter-operate for free or per the standard. I would hate to build heavily on workarounds that I feel should be in-built. At some point we just reinventing the wheel but in a more fragile way. I dont believe the arbitrary json was in the .NET version I was using which is what would expose data to be consumed via node.js (and other .net clients). Frankly it was easier to just implement a simple rest api that did exactly what was expected. What I sort of what is to be able to craft a query against a large set of objects like a customer/location/asset hierarchy and filter on different levels like sql query without it being in a database. I might have 10 different orthogonal dimensions with foreign keys than can be returned and filtered against. I'm trying to avoid pulling the complete object hierarchy only for it to filter out some of the data after the fact and then finally return the expected json format. Accessing some objects might be very expensive so being able to filter data as part of the query request rather than afterwords would speed things up. These actions are usually quite hard to do in libraries I've used. Maybe if you only use javascript/node.js, I don't know its not what I've need to start with. I may have misinterpreted what GraphQL was for if it is not for querying nearly arbitrary object graphs and returning json that the client wants returned.

westoncb 8y ago

Anyone know what framework the book uses (if any)? I tried doing a GraphQL project in Python/Django recently, using Graphene for the GraphQL bits. I didn't end up getting that far because the documentation was so lacking, as were examples generally (for graphene-python I mean; I could find stuff on GraphQL in the abstract). I'm thinking about giving it another shot, maybe on node.js this time, largely because I get the impression that the supporting tech for it is more mature there—but I'd love to hear opinions on what the most mature lib for using it is at the moment (whatever language)!

sbr464 8y ago
From what I've seen by glancing through, it's mostly JS -- Node.js (express-graphql), React, and packages from the Apollo GraphQL team (react-apollo). I've been using these over the last year and can recommend checking them out.
mazlix 8y ago
I believe the book is all in NodeJS. As for the most mature lib, I’d say Apollo.
- westoncb 8y ago
  Apollo is client-side though, no? I mean for integrating with server code.
  - sbr464 8y ago
    The Apollo team has apollo-server and apollo-engine-js. I've had good results with both of those.
lorendsr 8y ago
It's node: `apollo-server-express` https://www.apollographql.com/docs/apollo-server/ https://www.apollographql.com/docs/apollo-server/
tlrobinson 8y ago
It says right there in the post: "We’ll be looking at the core fundamentals of GraphQL along with strategies for how to implement it (client-side with Apollo and server-side in Node.js)"

maktouch 8y ago

We deployed our GraphQL July 4th 2016. It'll almost be 2 years. Documentation sucked back then (and apollo was non-existent), so a lot of we had to dig by ourselves. I hope this book will cover some topics for others that was real head scratchers for us - DataLoaders - Authentication example - Unions and Interfaces are your friend. Use them early. - Try to define your custom Scalars early (especially DateTime format) - return Connections (edge/node) instead of List cause you probably want to paginate at some point - Folder structure (we redid ours 4 times lol) - Naming convention (we redid ours 3 times lol) - Subscriptions After 2 years of using it and hacking it, we're still impressed. Once you get past the learning curves and have set conventions, writing GraphQL is a lot faster and better. Define your types, and some custom root queries, and done. The neatest thing is that we made a schema validator -- compile all the graphql queries from the frontend and mobile, and validate them against the server schema. It really help when we changed folder structure and naming convention to see if we'd break something on the frontend. I can't vouch for this book yet, but I'll swear my life on GQL. It's been a real game-changer.

dev1n 8y ago
Regarding folder structure, we developed saturn-gql [1] to help out with that. Have a look if you're still battling this. [1]: https://github.com/electric-it/saturn-gql https://github.com/electric-it/saturn-gql
- maktouch 8y ago
  Hey, that's cool! Thanks for that, will try it out on a new service/pet-project one day. In our current service, I think we're pretty happy with the way our structure is. It's almost similar to saturn-gql but with raw javascript instead of parsing with `graphql-tools`.
misschresser 8y ago
I'd be curious to hear more on your schema validator. We've been using GQL for a little over a year and have felt some serious pain when doing big shifts in our GQL layer and even just when we're trying to clean out dead code / assess which resources are being used in which FE apps.

jsnk 8y ago

I hope John will divide up the book later. I am interested, but as a guy working more on backend systems, frontend and mobile will not help me very much. I don't want to pay $40 for majority of content I cannot make use of.

pofilat 8y ago
It isn't $40 for content you don't use; it's $40 for the content you do use.
kbutler 8y ago
Smaller computer books tend to not be mich cheaper. So the majority of the cost is for the minority of the content you want. Maybe $10 for the rest of the content you may want someday.

simplecomplex 8y ago

Why spend time building an API at all? Just point Postgrest at your PostreSQL database and you get a REST api for free. There’s similar projects for graphql and other DBs.

stuartaxelowen 8y ago
Totally agree. Sprinkle in some row level security and you've got an app server with data isolated at the DB level, and get the power of SQL for building out endpoints. Compared to this graphql feels a little like engineering theatre.
- CodesInChaos 8y ago
  Which leaks a lot of implementation details through the public API, preventing changes without breaking existing clients. Which in practice means that you can't change anything anymore once you have more than a handful of customers. At least if you don't have the market power of a facebook who can say "Adapt your client code or it'll stop working. We don't give a fuck." Another big issue is that it forces the client to understand a lot about how your application works. While an API can abstract that and conveniently offer various computed properties which output what the client needs.
lsorber 8y ago
Anyone from the GraphQL camp care to weigh in against this argument?
- tzahola 8y ago
  If your endpoints are backed 100% by a db, then you can get by with the postgrest approach. However GraphQL resolvers can do much more beyond a simple DB query. E.g. you can call other services and combine their reponses. Or calculate the n-th digit of Pi. Or whatever you want to do.
  - steve-chavez 8y ago

rapfaria 8y ago

Why is rate limiting only part of the $289 package? Edit: And wasn't it cheaper earlier? I was pretty sure it was $29 for the basic version, maybe that rounding up market trick got me.

rhacker 8y ago

The author and his introduction definitely has a compelling story to tell. It is making re-think our recent strategy shift in which we evaluated GRPC and GraphQL. We chose GRPC but I'm starting to see that it's not really any better than REST + Swagger. I think I might need to actually just go ahead and buy this book and re-think if the GRPC route is worth it. Our investment in Grpc at this point has been slow - mostly because I figured the Grpc-Web project would be moving a lot faster by now. It's not and I don't see the team doubling down, whereas it looks like Apollo and GraphQL seems... ready now. Edit: Does anyone know if he goes over typescript?

sbr464 8y ago
No TypeScript on basic search currently, but book is not finished, can’t speak for the author.
lorendsr 8y ago
Would definitely recommend GraphQL over GRPC! We'll go over how to generate types or add them manually, but the rest of the book is in ecmascript.
andrewingram 8y ago
When I interviewed at Improbable (authors of gRPC Web) last year, we spoke a little about gRPC and GraphQL. The interviewer didn't really explain their choice beyond the fact that half the company came from Google and were already fans of gRPC.

dudus 8y ago

I want to buy it but feel annoyed by these payment options. Tier 1: $39 - Full book when released and early access Tier 2: $89 - Tier 1 + updates for 2 years + extra chapters Tier 3: $289 - Tier 2 + free updates for life + more extra chapters This is an oversimplification with only the things I care about. The actual packages include more stuff. What really annoys me is why would you call tier 1 the full book and say tier 2/3 has "extra chapters". I just want all the chapters + early access + updates (2 years is fine). And I want to pay less than $100. Am I being too entitled? Buying books used to be simpler.

Void_ 8y ago
Some 10 years ago I bought a huge book about Ruby on Rails for $50. It had at least 400 pages. This last week I ordered "App Architecture", also for some $50, and I was amazed by what I got - a tiny book that fit in a small envelope... And now $89 for a PDF?? I love books, but no thank you.
- bryanrasmussen 8y ago
  which of those two books was better though? if I'm getting a voluminous tech book with a generic 'name of technology' title it's a pretty safe bet that a third of it is useless to me.
- intrasight 8y ago
  If you considered it an online training course vs a book, would you consider it a fair price?
  - jhall1468 8y ago
    No, because an "online training course" in full text is a book.
blub 8y ago
Yes, it's like some horrible IAP concept for books. Normally a technical book costs around 40-60 EUR and one gets all the chapters. Updates are called "editions" and are published when there's demand and the information has become outdated.

nsstring96 8y ago

One of the problems I've noticed while using GraphQL (late last year) was that although there are 'officially supported' libraries in a number of languages, there isn't really feature parity between them. In particular, I remember that the Ruby implementation we were using required manually parsing the AST to do fairly basic operations described in the spec. I wonder if this situation has improved in the last few months.

zumu 8y ago

Is Apollo the be all end all GraphQL client these days? I tried it roughly 1.5 years ago and was turned off by all the component wrapping. Is it bad form to just fetch data via GraphQL and put it in Redux (or other store)? I'd like to buy in, but I'd like to keep my data fetching separate from my view layer if possible.

lorendsr 8y ago
Apollo has been in the lead for a while—it currently has 125k weekly downloads on npm, vs Relay's 20k. You can use the new render prop API instead of the HOC API if you don't like wrapping. The data fetching itself is separate from the view layer—it's all done by Apollo. From a maintenance perspective, listing data needs is great to have in the view layer, colocated with the components that use them. You can manually fetch data via GraphQL and put in Redux, but there are a ton of benefits to having a library like Apollo manage the store for you. Automatic normalization, querying from either store or server (or both), optimistic mutation updates, etc.
maktouch 8y ago
While transitioning away from Redux, we actually fetched Data via GraphQL and put it in stores. Honestly, it was a pain, but it's because we abused Redux. We progressed by doing the HOC and bypassing Redux but it still was a pain, because HOC. We're now at a stage where we updated Apollo versions, and started converting to the Query components. It feels and work a lot better. When we started, we thought the same thing -- keeping data fetching separate from the view layer if possible. We realised that it didn't make that much sense. Keeping everything in React components is a lot more maintainable and easier to comprehend.
jlu 8y ago
Fellow redux-abandoner here, be sure to check out Apollo client v2 and it’s various middleware options like link-state and link-rest, those in essential let you pull in data via graphql and REST-api and manage it via in memory store (just like redux store). Also the subscription via websocket story there is really sweet, you basically get real-time update for nothing ;) In short, just as John stated, it’s a huge boost of productivity on both front and backend, we verified it ruthlessly and love it.

tpetry 8y ago

Call me old school but i like my books printed and with on-demand printing services its not conplicated for a publisher. Can‘t read hundreds of pages on a screen... But without seeing the content the pricing looks insane. It has to be worlds better than online resources for 289$ (!).

Hendrikto 8y ago
The 39$ version would be closest to an actual book. You get every chapter once the book is finished, and that’s that. The more expensive versions include updates and additional features.
- sakarisson 8y ago
  Every chapter except the extra chapters included in the more expensive options.

TeeWEE 8y ago

While GraphQL has it uses, i can't seem to see how putting the query logic in your frontend is a good thing: How do you control scaling, and writing performant queries? When you make an API endpoint you have control over the queries you make and how you make them. With GraphQL you lose that control right? Maybe its good for internal projects, where you own the client and server. But often just exposing the internal DB directly to GraphQL is probably not a good idea. Maybe writing the DataLoaders yourself is better. But then you are already close to the effort of writing a simple endpoint. For simple API's graphql seems like overkill.

sbr464 8y ago
With GraphQL you have the flexibility to utilize both REST and RPC patterns, with the added benefit of a type system and ability to choose the fields returned on the client. You can write common CRUD queries/mutations similar to how you would with REST (allUsers/allProjects. If you have a query that you know ahead of time will be inefficient, you can add in a more RPC or dedicated endpoint style query that you can optimize how you see fit on backend (getAllCrazyThings(filters) etc). For the performance aspect, check out Apollo Engine, which allows you to track the latency and implications of using different fields within your queries and mutations over time: https://www.apollographql.com/docs/engine/performance.html https://www.apollographql.com/docs/engine/performance.html
true_religion 8y ago
GraphQL endpoints are API endpoints. You have to write the resolver yourself, which will do things like query the DB. GraphQL is just a schema specification like Swagger. It doesn't come with a server or a client. Those are implementation details left up to you, just like in REST.

GedByrne 8y ago

I think he is making a mistake selling this as a book. These prices just don’t work for a book. He should be selling it as a knowledge community. Members get access to the resources, conversations, training, etc. Add levels of membership that have to be earned through merit somehow and membership at a higher level becomes valuable on the CV.

neoeldex 8y ago

Why is all the GraphQL documentation so tightly coupled with either Apollo or Relay? Apollo doesn't work nice with a non-react setup (imhe), not to start about Relay itself. All the Relay server side stuff makes the client also really boilerplaty. I don't think i'd buy this book, since it's also apollo stained. Does someone have good resources on how to use vanilla GraphQL without the bloated Apollo/Relay stuff? I'm currently working on a GraphQL server (using Graphene), and thankfully I'm able to not use Relay (with which it tightly integrates). So I'm able to implement my own pagination and filters.

Waterluvian 8y ago
Also if it's the new REST then it absolutely cannot be language specific, let alone library specific.
andrewingram 8y ago
Relay (Modern) doesn't require any of the Relay-specific schema patterns. But most of them (connections, the node interface) are useful enough to want to use anyway. That said, I agree that too much of the documentation/articles/tutorials about how to use GraphQL assumes using a particular implementation. I'm far more interested in talking about higher-level concerns like best practices and data modelling.
lorendsr 8y ago
Chapters 1-5 are apollo-free! And the queries and mutations used in the apollo client chapters are applicable outside apollo.

Dowwie 8y ago

Adopters of GraphQL are quick to call it game-changing, but is it a game worth playing? It has to add value above the standards already in place. Is it accomplishing that? How is it more valuable than whatever it is that it replaces (REST, whatever)?

worldsayshi 8y ago
I think I came to this conclusion the other day: GraphQL truly shines when the variation of ways that you want to access data is significantly more complex than the complexity of the stored data. In other words, if you want to look at 10 tables in a twenty or forty or more different views (counting the times when a view is composed into another), then I believe using GraphQL will begin to show order of magnitude efficiency rewards. If the number of views is only slightly more than the number of tables then the rewards are more a matter of taste. It will give you a nice typed interface to your data and an interactive query GUI. But other tools provide that as well.
- dmitriid 8y ago
  > if you want to look at 10 tables in a twenty or forty or more different views (counting the times when a view is composed into another), then I believe using GraphQL will begin to show order of magnitude efficiency rewards. How will it show order of magnitude efficiency?!! It means that you will have 20-40 views towards a database that only contains 10 tables. Which will inevitably result in highly inefficient queries towards said database. Especially if a view is composed into another. There's no magic in GraphQL that suddenly makes that go away.
  - Chyzwar 8y ago
    Imagine you have a cross-platform app with multiple teams. You have a lot of data-driven components like different feed types. You want to avoid situations that change in backed API needs to be synced with every team/app. You want to give power to app developers to define efficient queries. Unless you develop multiple apps or data-driven application there is very little reason to use GraphQL. Personally, I am in favor of building two APIs: public/third party REST and JSON-RPC for the frontend. Getting REST right is difficult and after you create your resources your frontend needs to workaround incomplete/superfluous data.

sakarisson 8y ago

So let me get this straight. For the low price of $39 I will get the full book in ebook and HTML formats when it is done. But for the price of $89 I will get extra chapters on Server-side rendering, Offline data and mutations, Serverless and Stripe integration. So I am clearly not getting the full book for $39. I just recently refused to buy a game for employing the same dishonest sales tactics, so this is an easy no thanks from me.

tgtweak 8y ago
Day-0 DLC has arrived to technical literature. John really is ahead of the curve.
- btown 8y ago
  Errata can only be accessed via microtransactions. And loot boxes have a chance to drop full code samples... the F2P version leaves everything as an exercise for the reader.
  - ygjb 8y ago
    Oh, oh no. There is a missed opportunity here. Common lootboxes drop a line of code, uncommon an entire method, rare, a full object, and legendary are working samples.
    - btown 8y ago
      Hmm, you know, people want to forge their own legendary objects. Double the drop rate on working samples, but they’re obfuscated until you collect 3 of each code block. And you can sacrifice 10 useless one liners to be able to discover a block of your choice.
- rapfaria 8y ago
  And if he takes as much time as he took with "Secrets of the JavaScript Ninja", we may never even see DLC
8y ago

nek4life 8y ago

I'm skeptical that this book will ever be finished. The last time I bought an unreleased book authored by John Resig it took two and a half years before it was published. If I remember correctly another author had to take over in order to complete it. I'm super interested in GraphQL, but I wouldn't consider purchasing this ebook until it is 100% complete.

codingdave 8y ago

If nothing else, the conversation around this has shown that applying a subscription-based, tiered pricing model to a book is not appreciated by the consumers.

nkassis 8y ago
I think it's against the usual expectation for a book. If they had split it into volumes then it would have matched better people's expectations. Also the videos and extra should be part of a course package. Messaging just make it sound like you are getting short changed.

dmitriid 8y ago

> The end result is a vastly simplified backend GraphQL specs offer none to zero of the following: - caching - authentication, authorization and handling data access - protections against ad-hoc arbitrarily nested and complex queries - routing How does this “vastly simplify the backend”? If anything, it makes the backend hideously complex (IIRC Apollo’s approach to caching is parsing requests and responses every time, do some magic, and handle caching manually).

ozten 8y ago

Once you pay $39 you have to Github OAuth to receive the book. Currently, there are no other authentication options. Just an FYI as I didn't know that before I had paid.

snarfy 8y ago

Why should I use Facebook's GraphQL over OData which is an ISO standard? I've found a few comparisons but I'm curious what the HN crowd has to say.

nkassis 8y ago
Feels like GraphQL has more momentum behind it now than OData. OData seems to have suffered from the fact that it originated in the .Net world which is pretty much ignored by those outside of it.

pier25 8y ago

> GraphQL offers a way to push all of the logic for specifying data requirements onto the client, and in return, the server will execute the (highly structured) data query against a known schema. The end result is a vastly simplified backend that also empowers the client to execute whichever queries they need. Why is empowering the client a good thing? Why is moving complexity from the backend to the front end a good thing?

williamdclt 8y ago
because the client knows exactly what it needs and it makes abstracting the data-fetching pretty easy
kbutler 8y ago
Because you can have one server efficiently servicing multiple clients with different, unanticipated needs.
- pier25 8y ago
  So, reducing server load? OTOH if the complexity is offset to the client, and you have multiple clients, then there is more complexity. No? (assuming you have multiples types of clients)
  - kbutler 8y ago
    It allows a server produced by one organization to provide an API that remains efficient for future clients produced by other organizations without either changing the API to meet the needs of the other clients or anticipating every client's needs. More to be economical in API design, rather than just server load and bandwidth.
  - sken 8y ago
    But the client already had to consider what data it needed. The only difference is that in a REST world it needed to make several calls to fetch all the data (often waiting for resource references in the nth response before being able to build the (n+1)th query) whereas now it can fetch them all in a single query. So if anything it reduces the client complexity, as well as making it much easier to extend the API to support new client requirements without having to resort to REST-style versioning.

ilaksh 8y ago

Looks nice but why would I use GraphQL over JSON queries to a simple document database directly? I guess it comes down to how important schemas are to you. Which I know suggesting they might not be important sometimes is for some people a sin punishible by death. But for me that's a belief system that doesn't hold up for everyones application.