Feat: Create / Add Axios Large Response Interceptor

[alexmarqs]

An Axios interceptor designed to handle large responses.

• Global and per-request options;
• Custom callback function to fetch large payloads from a reference data, customisable reference property names, headers, and other options;

[jpinho]

Hey @alexmarqs, I have a fundamental request here, can we switch to not send large response accepts by default?

By default, it assumes that your backend uses @epilot/large-response-middleware

I think it should be the other way around. By default it should fail, it's not ok to have APIs return over 6MB of data, demonstrates likely a bad design in the code.

Would be nice for teams to inspect the failure and then decide to make it enabled:true. We should not have to do this (should be the default):

  axiosLargeResponse(client, {
    enabled: false,
    logger: Log,
  });

[alexmarqs]

Hey @alexmarqs, I have a fundamental request here, can we switch to not send large response accepts by default?

By default, it assumes that your backend uses @epilot/large-response-middleware

I think it should be the other way around. By default it should fail, it's not ok to have APIs return over 6MB of data, demonstrates likely a bad design in the code.

Would be nice for teams to inspect the failure and then decide to make it enabled:true. We should not have to do this (should be the default):

  axiosLargeResponse(client, {
    enabled: false,
    logger: Log,
  });

Hey @jpinho I totally get your point, I thought about that when designing this but ended up with the default being enabled. Happy to have your feedback here and I will change this based on that 🙂!

[jpinho]

Hey @alexmarqs, I have a fundamental request here, can we switch to not send large response accepts by default?

By default, it assumes that your backend uses @epilot/large-response-middleware

I think it should be the other way around. By default it should fail, it's not ok to have APIs return over 6MB of data, demonstrates likely a bad design in the code.
Would be nice for teams to inspect the failure and then decide to make it enabled:true. We should not have to do this (should be the default):

  axiosLargeResponse(client, {
    enabled: false,
    logger: Log,
  });

Hey @jpinho I totally get your point, I thought about that when designing this but ended up with the default being enabled. Happy to have your feedback here and I will change this based on that 🙂!

Yep, that also crossed my mind. It's just that enabling this will bloat our browsers caches, and slow down our MFEs greatly => in a super easy way.

We should log a warning for large responses on the client and make it default:false so that the change is explicit. Otherwise a distracted developer may start using our clients and pulling large response without even realising. We want the engineers to deal with the failure first, and only then use this as a tool to temporarily mitigate if required. Often the solution is to fix the bad code pulling such large responses.

[alexmarqs]

@jpinho I have committed some changes based on your feedback, here is: 0383366

• Change default enabled option to `false
• Add disableWarnings global option to control warnings
• Implement warnings for unset interceptor configuration (no explicit enabled global option set)
• Update types and documentation to reflect new default behaviour

If all good, I will create a new release and bump the version and then merge. If not, let's keep iterating on this!

[jpinho]

TIL!

[jpinho]

Awesome contribution @alexmarqs 👏👏👏 ❤️