reactjsreduxserver-side-renderingisomorphic

React Redux data-fetching : differentiate browser / server-side method in isomorphic app?


Most examples I come across seem to always fetch the data from URL.

But on server side, would it not make sense to fetch data directly from the database ?

So in the action creator it would look something like:

if(typeof document !== 'undefined')
  fetch("url/posts").then(response => dispatch(receivedPosts(response))
else
  db.select("posts").then(response => dispatch(receivedPosts(response))

What are the Pros and Cons of this method relative to other data-fetching methods ?


Solution

  • Most React/Redux applications are built in an environment where there is a separation between API development and UI development. Often these same APIs power mobile apps as well as other desktop apps, thus a direct db query like you've shown wouldn't be available to the server side render.

    In your case it seems your building full stack app with a single codebase. There's nothing wrong with that necessarily however there are some things you should probably consider. First off is establishing a likely lifecycle of the application. There's a big difference between a fun little side project done to learn more about a stack, a startup racing to get and MVP to market, and a large enterprise building a platform that'll have to scale out the gate. Each of these scenarios could lead you to different considerations about how to design the tiers of your app. One important question specific to what your working on is whether other apps/platforms may need to access this same data, and whether different teams may eventually maintain the back-end and front-end. With node and mongo it's very easy to create API endpoints that serve your React app initially but could be used by say a native IOS app later. You also would get the benefit of separation of concerns in maintenance and enhancement of your app. Debugging is often easier when you have data access and UI logic completely separated as you can call your APIs directly with something like postman to identify if they're providing the correct data.

    In your case it seems like may already be serving API data from /posts, so you could potentially get all of those benefits I mentioned but still also skip a network hop by bypassing the API as your code snippet suggests. This would provide one less point of failure in the server render and would be a little faster, but you probably won't gain much speed and if you have network issues with your APIs they'll show up right away on the client side of the app, so the benefits don't go to far.

    I would personally just make the fetch calls in the React app and separate out all my data access/API logic in a way in which moving the back-end and front-end to two separate repos wouldn't be too painful in the future. This will put the app in a good place for it's potential growth in the future. The benefits of the separation of concerns out weight any slight performance bump. If you are experiencing slow page loads, then there are probably numerous places to tune, often starting with the db queries themselves.