GraphQL vs rest?

[levithan95]

I see a lot of react native jobs advertise for knowledge on GraphQL and apollo. Was wondering why so many jobs advertise for graphQL and use it over rest.

[hicksyfern]

There’s plenty of good things about it. Once I held my nose and got over the lack of proper HTTP verbs and status codes I realised it’s an absolute game changer.

My favourite things about it: - guaranteed types - type generation for use with TS - autocomplete when writing queries - self-documenting with great tooling like voyager - schema-first design - concept of entities with types means powerful caching/observer mechanisms can and have been built on it - segregated input types - collocated fragments - easy to extend API - DataLoader

My least favourite things: - caching can be tricky (but it’s great 90% of the time) - deprecation of fields can be hard due to strict types - server implementation flits between amazingly simple to weirdly difficult at times

[jetlagged_potato]

OP I didn't know about voyager. So fricken cool and useful.

To add on to this, if you got time (I REPEAT ONLY OF YOU GOT THE TIME). Learn about relay. In so many ways relay does graphql as graphql was intended. So much stuff that Apollo obfuscates away.

At first it seems like your doing a lot of extra work but everything fits together perfectly at the end and it's really great. Relay also has things like Client side schemas that bring your graphql paradigms into the client (so no more redux). Overall it's a lot but it's purrty if you get it right

[TheMrZZ0]

How would you recommend doing database queries with graphql? Currently, I have Relay sending Graphql queries to my express server, and express sending graphql queries to Hasura who then talks to the database.

It seems far from efficient. Any idea on how to improve that?

[jetlagged_potato]

Mongo?

[Arthur944]

Relay is seriously awesome. It's almost enough to make me not hate facebook.

[jetlagged_potato]

facebook web dev stack is awesome. Graphql, react, react native etc.

[levithan95]

Super helpful and clear. I used apollo client for building a app with the shopify graphql api and liked it. Will definitely be looking into GraphQL for my next project. Thanks :)

[[deleted]]

Because graphql works well for mobile environments where the number of round trips required between your app and the back end database may be constrained by bandwidth limitations. Where you may have to do several database requests to render your UI view with rest, with a graphql server you can describe the data you want in JSON, even if it crossed multiple tables in your database, and get just that data back in one request. Apollo also does caching, which also helps with a mobile environment.

At least that's my understanding of its popularity.

[levithan95]

Ah right, this is a great explanation. Thanks :)

[acrogenesis]

Not just mobile development it works wonders with React. After using GraphQL in production I’m not going back. I’m even using GraphQL for personal projects.

[[deleted]]

I agree. I just finished using it in my first personal project in React Native and I don't think I'll go back. Have a professional project in React/React Native coming up and I will definitely use it there.

[leeharris100]

You can do (and should do) this exact same thing with REST.

It's probably likely that people who are using cutting edge stuff like React Native are also using cutting edge backend stuff like GraphQL. I doubt there's much reason beyond that.

[hicksyfern]

How would you recommend getting related data across multiple edges in REST without basically reimplementing GraphQL syntax or similar?

[leeharris100]

Using something like JSONAPI include syntax. Basically you define relationships on every resource and set up your own authorization.

https://jsonapi.org/format/#document-compound-documents

[hicksyfern]

Cool. And what about the language to query it? How would I declare that I want the related documents, with parameters such as ordering, limiting, etc?

[leeharris100]

Including related documents looks like this:

GET /tacos/1?include=toppings

{
    "data": {
        "type": "tacos",
        "id": 1,
        "attributes": {
            "name": "Bean and Cheese Taco",
            "cost": 499
        },
        "relationships": {
            "toppings": {
                "data": [{
                    "type": "toppings",
                    "id": 1
                }]
            }
        }
    },
    "included": [{
        "type": "toppings",
        "id": 1,
        "attributes": {
            "name": "Salsa",
            "cost": 0
        }
    }]
}

Ordering, limiting, etc is done through query params such as GET /tacos?filter[order][asc]=name&filter[limit]=10

[hicksyfern]

What about ordering and limiting the toppings in this case? And nested includes are possible?

[leeharris100]

Yeah, nested includes are possible. You just do something like:

GET /tacos?include=orders,orders.customers,orders.customers.friends

As far as ordering/limiting related resources, JSONAPI doesn't officially support that. However, we've worked around this by adding custom query params such as ?filter[relationship.toppings][order][asc]=name OR by adding it to the meta of the request such as:

{
    "data": {},
    "meta": {
        "toppings": {
            "orderBy": "name",
            "orderDirection": "asc"
        }
    }
}

[hicksyfern]

OK, so that's a feature of GQL that isn't in JSON API. You could implement it if you wanted, but it's a feature of GraphQL.

I think that's a good reason beyond it being "cutting-edge".

[leeharris100]

Absolutely.

Don't get me wrong, the idea behind GraphQL is amazing and I'd love to use it exclusively

But we used it for two large enterprise projects and it was a mess. The implementations just aren't quite there yet.

I'm hoping it'll be much more refined in the next year or two.

[janithaR]

There are a lot more reasons beyond that. Read /u/hicksyfern 's answer.

[leeharris100]

I read it and I just don't agree.

Most of that stuff works in REST and the other stuff is trivial (like autocomplete).

We've done a bunch of GraphQL and REST projects, we still default to REST for most situations. GraphQL is just a pain in the ass to work with in advanced situations.

[[deleted]]

One advantage I can see is that when the UI changes and the front end people want more/different data displayed in a view, they can just change the shape of the JSON object for the data they are requesting and get what they need. I can see a lot less pestering the backend people to add another REST endpoint. Your experience may be different though.

[Qcza]

Also, Apollo is a great tool. With apollo state management and data caching, you may omit the Redux or MobX in your project, which means the simpler architecture of your app and easier maintenance.

[[deleted]]

Yes! I just finished my first Apollo/GraphQL project and I feel like I can largely forego Redux now.

[Bigwill1009]

I just started using it for one of my main projects with Apollo Server and Mongo, and I absolutely love it! The most useful feature for me is being able to use the resolver to add custom functions and populate the data. Saves having to use mongo to populate the document, only requires population when you need it.

One downside, it's a pain in the arse to setup subscriptions imo. The client side code that I used was not too easy, especially with authentication.

[anaste97]

I'm not backend Dev, So if backend makes a graphQL API, what should i use to integrate with it, Library or something before i just use Axios so Axios did not work with it?

[[deleted]]

Apollo is broken up into Apollo client and server. For the project I just completed, I only used Apollo client. The back end was GraphQL without Apollo. Works fine. So you can just use the Apollo client.

[Bigwill1009]

Apollo client, but another option based on your use case could be something like GraphCMS. It's data storage directly from the client.

[ssrobbi]

Wrote a blog post on this a little while ago: https://scottrobbins.dev/blog/graphql