Fifciu
commented
11 months ago @WojtekTheWebDev
I'd first explain the fact that caching is possible only on GET requests and only in case when the request does not depends on the cookies and headers.
You mean here I should start the doc from that?
When it comes to specific methods, I think we should suggest something like whitelist or blacklist instead of if else blocks.
I thought to do it like that at first glance. However, there will be different edge cases per client. Even though we can reduce the amount of code right now I didn't do that. Because you copy-paste it and it's straightforward from the very beginning. What's more, you can customize it very easily. You want to have a bit different conditions and logic for getProduct and even more different for getCategory? No problem. You want to restructure it and have it in multiple files? No problem. You want to have different structure in different projects? No problem. You want to set different values or even different headers per endpoint or in different scenarios for the same endpoint? No problem. And all of that without new syntax/API introduced and maintained by us. Just a simple extension for middleware in node.js.
If we introduce a whitelist and looping through it then we don't have granular control anymore. If we want then we need to create some object describing each endpoint and handler for it, extend it every time when we need some new edge case. It will be harder to maintain and understand at first glance.
I know huge if...else block might seem overwhelming and scary at first but if you read it you can see even though it's long it's very simple and even juniors will understand it easily and what's more important - everyone can extend it easily.
We should also mention that the middleware since 3.5.0 supports GET methods and describe that SDK modules are using the GET method by default for cachable methods like getProducts.
Indeed, I will add it.
Also I'm wondering is there any way to add cache control header by default to all methods? Do we always need an extension?
We could but it's dangerous. Not every GET endpoint can be cached, some are still user-related. I provided a subset of possible cache endpoints for every eComm. But it might change in different ways and the user has to be able to update the caching strategy accordingly. What's more, some endpoints might be cached in some scenarios and in some not. The amount of possibilities goes to infinity and giving end-developers a simple middleware extension shifts liability on them - they will be able to implement any caching strategy they want without asking as for a help all the time because we missed something in our Caching API.
sonarcloud[bot]
🔗 Linked issue
IN-3679
❓ Type of change
📚 Description
General documentation explaining how to cache GET endpoints' responses.
📝 Checklist