1. 4
  1.  

  2. 7

    The grammar of the questions asked in this article irks me. You can either say “Why development teams are adopting GraphQL”, as a statement, or you can say “Why are development teams adopting GraphQL?”, as a question. But what the author is doing is a strange mishmash of both. It would only be correct if it was meant as a quote with a follow-up: “Why development teams are adopting GraphQL? I have no idea!”.

    1. 5

      Or with an extra comma as an interjection:

      Why, development teams are adopting GraphQL? What a preposterous notion!

      1. 5

        I assume Tomek’s first language is not English.

      2. 2

        I think GraphQL is just laziness, since you have a single endpoint. And as we all know, laziness always wins for coders :D And with that single endpoint, comes better tooling from standardization, and the snowball grows over time.

        1. 8

          At first, it feels easy and good for lazy devs, but then you take Dragon book from the shelf, because you are required to make optimizing transformer from GraphQL AST to SQL queries. And to make your own query complexity estimator to prevent instant DoS with single query.

          GraphQL is like having SQL available to outside world, but with different syntax. I don’t understand attractiveness of this approach.

          1. 3
            1. 2

              GraphQL is like having SQL available to outside world, but with different syntax. I don’t understand attractiveness of this approach.

              As someone working on a GraphQL implementation for a pretty big website (we have hundreds of software engineers) I feel like I can talk a bit about why it’s working for us. You’re right that it’s a bit like SQL, but it’s designed specifically for business objects. Instead of worrying about the normal form of our data, we specify the schema of those objects as it will be consumed by our clients.

              We then get to write our resolvers in ways that make sense. We can do bulk fetches, use multiple data sources (including caches), compute derived fields or combine data sources… and we can swap those things out without our clients noticing. We get to move logic away from ORM-layer magic, instead specifying a schema for business objects and a way to inflate them. Conversely ORM models represent both business objects, with derived fields, and database rows. There’s no schema for derived fields, and serializing a model instance to send it over the network is fraught.

              The solution to the ORM problem is obvious: use true business objects, which can be serialized and transported easily, and provide a set of tools that can inflate them. Congratulations, you’ve just invented GraphQL.

              I probably wouldn’t choose GraphQL for a small hobby project; but on a project big enough to have multiple caches, multiple canonical data stores, and sharded data, it’s great to work against a standard. Being a standard, we get to take advantage of existing practices and tooling. We get documentation, introspection and query building for free. We can build tooling that can easily read and write schemas, enforcing business rules, keeping things in sync or notifying us of breaking changes. We’re not breaking new ground here either; AirBNB has some great prior art here.

              Hopefully this explains a little bit of why we find it an attractive prospect.

            2. 3

              Maybe someone should go full circle and implement a new database that uses GraphQL as the query language. Then we won’t need to write server back-ends anymore and can just defined a schema + security rules and expose it to the front end.

              1. 3

                Makes sense for API where you don’t know what the UI/client side will look like. So for a headless CMS, or a generic backend as a service. Those use cases make sense. Some people use it for their main app, which just makes things slightly easier in the beginning and impossible to optimize in the long run.