3 ms·

There is a fair amount of practical gain in terms of specifying fields. Can go a long way in terms of making flexible endpoints that don’t pass around extra dat

There is a fair amount of practical gain in terms of specifying fields. Can go a long way in terms of making flexible endpoints that don’t pass around extra data. This often isn’t necessary. But when it is you would cry at the thought of using REST instead.

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.
DangitBobby 4y ago
You can modify REST endpoints to support selects and filters.

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.

DangitBobby 4y ago

You can modify REST endpoints to support selects and filters.