3 ms·

I can think of painful examples in REST in my life where I had an endpoint that was being used for something new, and now I had to join with some new data model

by timr 4y ago

I can think of painful examples in REST in my life where I had an endpoint that was being used for something new, and now I had to join with some new data model to solve the new problem which made the old use sub-optimal (or vice-versa). But when that happened, what it really told me was that it was time to introduce a new endpoint and refactor the code to adapt to the change in use case. Painful? Sure. But so are the downstream consequences of converting everything in your system to an arbitrary query executor.

nonethewiser 4y ago
Right. In GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. It separates the API from how it’s used. If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints.
- timr 4y ago
  > GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. Yes, but I'm saying that's a feature, not a bug. It's not absurd to make new endpoints. Each endpoint is a different need. You can optimize them independently...or not. > If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints. In my career, I can count the number of times that a field has mattered in a response on one hand. Usually the problem is the joins, or the total number of queries. Point being: you don't generally write new endpoints just because the number of fields in a response is slightly different.
  - satvikpendem 4y ago
    Or you can use GraphQL and get all of that functionality for free.
    - timr 4y ago
      Where "free" means "lots of developer burden", sure. Let's kill this fly with a chainsaw. It's free!
      - satvikpendem 4y ago
        I've never experienced the problems you say you have with GraphQL, to be honest, and I've been using it for quite a while.

by timr 4y ago

nonethewiser 4y ago

Right. In GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. It separates the API from how it’s used. If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints.

timr 4y ago
> GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. Yes, but I'm saying that's a feature, not a bug. It's not absurd to make new endpoints. Each endpoint is a different need. You can optimize them independently...or not. > If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints. In my career, I can count the number of times that a field has mattered in a response on one hand. Usually the problem is the joins, or the total number of queries. Point being: you don't generally write new endpoints just because the number of fields in a response is slightly different.
- satvikpendem 4y ago
  Or you can use GraphQL and get all of that functionality for free.
  - timr 4y ago
    Where "free" means "lots of developer burden", sure. Let's kill this fly with a chainsaw. It's free!
    - satvikpendem 4y ago
      I've never experienced the problems you say you have with GraphQL, to be honest, and I've been using it for quite a while.