Run loader/action from the client, not wasting server resources.

[luispuig]

Sorry if my question makes nonsense.

I am working on a Remix app, Remix is helping me a lot!!! Since I am working with a public API from the loaders and actions, I realised that most of my routes are not actually "private" and use server resources.

I wonder if there is a way to define if the loader when revalidating and/or the action should be run in the front end when the developer considers it.

I noticed that most of the loader/action logic is placed in React Router (client), the fact that the fire the server is a Remix part.

[sergiodxa]

No, Remix loader and action functions always run server side and at least right now there’s no way to change that.

And even if you fetch a separate API using the loader/action server side would let you remove extra data or combine data from requests making the data the user download smaller than if you fetched the API client side.

[luispuig]

Thanks a lot for the answer, it makes sense. My use case is probably an edge case, the data comes from a GrpahQL API, in the same environment as Remix. So, the Remix loaders/actions are kinds of proxy, making remix more complex with client action is probably not worth it at all.

[penx]

For our use case, which I don't think would be niche/edge case, it would help a lot to be able to mark a loader or action as client-safe, or alternatively export a loaderClient function that returned the same data as the server side loader.

If this feature was added, I would expect Remix to only run the loader client side once JS has loaded and fall back to the server side if there are any JS failures.

Our use case is that most of our loaders and actions are connecting to a REST API in a way that we can reveal the token to users. The API (the Firestore REST API) is very fast and distributed. Of course it makes sense to do the initial API calls server side in order to render the page, but subsequent calls would be faster if done client side connecting direct to the Firestore REST API.

If our Remix application was deployed to the edge in a way that was as fast and as close to the users as the Firestore API is, then perhaps there would not be a significant impact, but if our Remix instance was running further away from the user that the Firestore API then it is going to slow things down.

I have just deployed our application with Remix to a Netlify preview environment with edge cloud functions. Page transitions for the Remix version are significantly slower than the client side version that is using react-router@6.4.0-pre.2, and is calling the Firestore REST API directly from the client.

Our API calls via Remix are 284-731ms whereas for the client side version they were 37-85ms.

When running traceroute I think this is because the Netlify preview environment is based in the US (I'm in the UK) so I am guessing this won't be as big an issue if I configure it correctly or it was on a production environment, but not all users of Remix would be able to deploy to the edge (or have a Remix instance that was as fast as their API) so would still face this issue.

One thought I'd had was to look in to the code in remix/react-router that is calling the loader function client side and see if there's a way for us to override this to call a loaderClient export ourselves rather than it being a out of the box feature from Remix - I'll look in to this if we continue to get the speed issues described above.

[penx]

Related:

• RFC: Static Pages / Browser Only Fetching #2853
• A mechanism to execute the loader (or action) function on the client #1312 (comment)
• RFC: Static Pages / Browser Only Fetching #179

[luispuig]

Maybe, my case is not such an edge case and it could be interesting to let the developer decide if the loader/action should be executed in the client or in the server. From my understanding, they should be used on the server side during SSR.

[penx]

Now covered by #7634