4 ms·

I don't think you quite did understand - the frontend team didn't actually -need- that, they just happened to have a prebuilt UI component that -used- that, rea

by mst 2y ago

I don't think you quite did understand - the frontend team didn't actually -need- that, they just happened to have a prebuilt UI component that -used- that, reached for that (entirely understandably, to my mind) without considering if it was the right thing to use there, then reverse engineered and abused the API to make it work. What OP did was make a technical change to make that abuse impossible so that the conversation as to whether it was something the UI actually -did- need or if the UI should simply be written to expose the intended capabilities of the API happened naturally, as early as possible in the process. You can't use technical measures to *fix* human problems, but in this case the technical measure exists to *surface* the human problem so it can then be resolved between the humans in question. This is IMO a far better approach than the alternative, which would boil down to micromanaging the UI team's choices in a way that would slow everybody down and likely *would* produce the adversarial dynamic you describe.

rendall 2y ago
> ...they just happened to have a prebuilt UI component With respect, that's not what is described. OP rolled an API, handed documentation to frontend, and "after a week" frontend "came up" with a UI that held different expectations for how pagination works than the API actually worked. I'm being charitable in assuming that there was a good reason that this pagesize, offset pagination style could not work, but as written, there was no communication about that, neither to us the audience nor to OP's colleagues. In fact, frontend apparently expected this. But why not discuss offset, pagination with colleagues? Why just present it as fait accompli and move on to create a library that further locks it in?
- alejo 2y ago
  Maybe this may help. What if we are not talking internal development teams but something different, like a commercial/public API? In those cases you cannot affort or expect to have meetings with folks to explian and communicate, and you also can appreciate more the abuse (unintended or not) that tokens can have. I particularly liked that OP mentioned about expiration, key rotation and more advanced features you can achieve with his proposal, like switching schemes
  - rendall 2y ago
    Agreed: if the situation were completely and totally different to the one described by OP, then yes, different circumstances apply.

by mst 2y ago

rendall 2y ago

> ...they just happened to have a prebuilt UI component With respect, that's not what is described. OP rolled an API, handed documentation to frontend, and "after a week" frontend "came up" with a UI that held different expectations for how pagination works than the API actually worked. I'm being charitable in assuming that there was a good reason that this pagesize, offset pagination style could not work, but as written, there was no communication about that, neither to us the audience nor to OP's colleagues. In fact, frontend apparently expected this. But why not discuss offset, pagination with colleagues? Why just present it as fait accompli and move on to create a library that further locks it in?

alejo 2y ago
Maybe this may help. What if we are not talking internal development teams but something different, like a commercial/public API? In those cases you cannot affort or expect to have meetings with folks to explian and communicate, and you also can appreciate more the abuse (unintended or not) that tokens can have. I particularly liked that OP mentioned about expiration, key rotation and more advanced features you can achieve with his proposal, like switching schemes
- rendall 2y ago
  Agreed: if the situation were completely and totally different to the one described by OP, then yes, different circumstances apply.