Is it better to send normalized or denormalized API response back for React+Redux applications

Question

I'm writing a react-redux application. At the beginning it calls a single endpoint, which returns a good amount of data as a heavily nested JSON. I then normalize it and put it into my redux-orm schema.
To me it seems silly to create the nested data on the backend just to loop through the nested data on the frontend in order to normalize it, considering it's coming from a normalized PostgreSQL database.

Database = Normalized --> 
API = Denormalized --> 
Frontend = Normalized

Is it best practice to just send back a normalized API response?

Answer 1

It would help; as you said, it's recommended to have normalized data in state: https://redux.js.org/faq/organizing-state#how-do-i-organize-nested-or-duplicate-data-in-my-state

If you still want to send nested data from the API, e.g. to only send what is needed or if it's an existing API, you can normalize on the client side before adding the data to the store. For example with this library: https://redux.js.org/faq/organizing-state#how-do-i-organize-nested-or-duplicate-data-in-my-state

Answer 2

I don't understand why anyone would normalize on the front. The whole reason I do normalization is to get rid of repetition. Instead of sending the same nested data, say user object, multiple times, i nest the user id, and in a separate property called "users", I would send all the users needed with their ids as keys for quick and easy access as follows:

"users": {
    "1": { "id": "1", "name": "user_name", ...rest_of_user_details},
    ...
}

After all, it's easier for the front to deal with non-normalized data. It takes less code to just list data with nested objects as-is rather than access those objects inside other properties using the object ids.

Answer 3

I'm not sure there is a "good" way to do so. If you have to deal with an existing API, then deal with it, and use proxy/parsers in your frontend code to map your backend payload into your redux-orm store, and on the other side too.

I won't pretend here to give an answer, but rather a feedback, after nearly a year of production of our React/Redux/Redux-orm application Wisembly Jam.

When we started from scratch, we chose to use the JsonAPI spec for our API. We liked that as it exposed objects and relations in a way that fitted well with our PostgreSQL scheme, and also our redux-orm one.

That way, no model relation nesting needed both way, only plain objects handled in data field, included relations in included field. It appeared to work very nicely together.

You might inspect our application Network tab to look into our api payload responses, and also our redux-orm store (using Redux Chrome extension).

Hope that helped a bit, despite my english and not being properly an answer :)