4 ms·

I often miss graphql features when working with rest APIs. But switching over seems very much not worth it when no one in the organisation knows graphql. I fee

I often miss graphql features when working with rest APIs. But switching over seems very much not worth it when no one in the organisation knows graphql. I feel like graphql would be much easier to adopt of it just sticked to rest conventions as much as possible. Like have the query language be pure JSON. It should even be possible to design it so that you could make drop in replacements for most of existing rest APIs.

kandros 7y ago
GraphQL is much easier to pickup and get productive than most people think, most of the times all you have to do is writing resolvers (functions) instead of http handlers (functions) On the client side is the same, following any getting started guide can explain 90% of what you need to know in a single day
- vlozko 7y ago
  Client side GraphQL is harder than REST, though I wouldn’t define it hard in general. Whereas with REST one only needs to update the data model for the response, GraphQL also requires that the request itself is also updated. It gets more complex if the client wants to take advantage of hashed queries and now there’s all this work needed to upload the queries to some backend service. This is from my own experience — I haven’t worked with Apollo to know how much of this process is simplified for you.
  - kandros 7y ago
    The situation you are referring to is actually a great plus, If you change the data model in you backend, you client consume it and thus depend on it, so you still have to change the frontend code anyway, knowing exactly what you can ask and how it will come back makes it a very powerful developer experience with a lot of test that don’t need to be write thanks to tooling around a type system and a faster feedback loop.
    - vlozko 7y ago
      Oh, I’m not suggesting that it’s a worse way to do web requests at all. I genuinely enjoyed working with GraphQL despite all the build/CI headaches it can potentially cause. I was really addressing the sole point of difficulty of working with REST vs GraphQL and I’d unquestionably say REST is easier. It’s not a statement of which one is better or worse.

kandros 7y ago

GraphQL is much easier to pickup and get productive than most people think, most of the times all you have to do is writing resolvers (functions) instead of http handlers (functions) On the client side is the same, following any getting started guide can explain 90% of what you need to know in a single day

vlozko 7y ago
Client side GraphQL is harder than REST, though I wouldn’t define it hard in general. Whereas with REST one only needs to update the data model for the response, GraphQL also requires that the request itself is also updated. It gets more complex if the client wants to take advantage of hashed queries and now there’s all this work needed to upload the queries to some backend service. This is from my own experience — I haven’t worked with Apollo to know how much of this process is simplified for you.
- kandros 7y ago
  The situation you are referring to is actually a great plus, If you change the data model in you backend, you client consume it and thus depend on it, so you still have to change the frontend code anyway, knowing exactly what you can ask and how it will come back makes it a very powerful developer experience with a lot of test that don’t need to be write thanks to tooling around a type system and a faster feedback loop.
  - vlozko 7y ago
    Oh, I’m not suggesting that it’s a worse way to do web requests at all. I genuinely enjoyed working with GraphQL despite all the build/CI headaches it can potentially cause. I was really addressing the sole point of difficulty of working with REST vs GraphQL and I’d unquestionably say REST is easier. It’s not a statement of which one is better or worse.