Question regarding SWR for unusual "proxy" scenario.

[aboveyunhai]

As far as how I understand SWR, it's work pretty neat with direct communication.
But I wonder what happen if SWR can only contact with a "pseudo" proxy middleware.
For example,
SWR -> next.js Api -> next.js Api will use （For example）axios call remote backend Api, the data from backend Api will be passed all the way back to client side via next.js Api.

Assume we cannot directly call remote backend Api via SWR.
Will this still make SWR viable comparing to regular fetching api like axios.

[shuding]

You can surely do this, but I'm curious about the reason behind it. Mind sharing why you add this proxy layer?

Also SWR is not comparable to something like Axios, they can be used together.

[aboveyunhai]

@shuding Sure.
One of the reason is that the server is existing for a while but its Api endpoints are newly but poorly crafted due to migrations, etcs.
So the next.js Api (at least, currently) somehow acts as a middleware/encapsulation, or an extra layer to protect the server until it's mature.
By this weird way, though it brings a lot of overhead to frontend side, all the "true" Api endpoints are completed blackboxed from client-side.
Of course, it also handle a lot of other stuffs but I cannot share.

But it indeed sacrifices a lot of benefits/performances.

[shuding]

Gotcha! But still, SWR can provide a lot of extra features (caching, auto revalidation, etc.) other than just axios. It doesn't depend on the API implementation.

[aboveyunhai]

Exactly! It's also funny that the example in the doc SWR tried to solve has the almost identical codes I had written with the exact naming.
The UI is indeed much more fast and reactive. Thanks for your hard work