Return to Answer

But it should be iterated upon and converted to a different format.

 

What are the main axes my decision where this conversion should reside rely upon?

Given the resources array size is 100, it should be fine and reasonable for the conversion to happen on the front end. What about if the resources arrays size is much bigger ? Could there be a threshold where iteration and converting the data from one format to another should happen in the back end ?

 

I do have substantial reasoning for passing the conversion responsibility to the front end, but I wonder whether this will scale ?

But it should be iterated upon and converted to a different format.

What are the main axes my decision where this conversion should reside rely upon?

Given the resources array size is 100, it should be fine and reasonable for the conversion to happen on the front end. What about if the resources arrays size is much bigger ? Could there be a threshold where iteration and converting the data from one format to another should happen in the back end ?

I do have substantial reasoning for passing the conversion responsibility to the front end, but I wonder whether this will scale ?

The question is slightly nonsensical, or at least glossing over certain issues. Conversion happens wherever conversion needs to happen.

The question is slightly nonsensical, or at least glossing over certain necessary consideration. Conversion happens wherever conversion is the most appropriate. That's the short answer, but there is of course a lot of information hidden behind how to consider something "appropriate".

Optimizing for performance

• "Because the frontend data structure is just different" -> Why is it different? Could it not just use the same structure as the backend? Because if it can, then you don't need a transformation at all.
• "Because the server stores the data in a different format" -> This is not something your frontend needs to know about, and therefore you need to convert it as close to the actual storage logic as possible
• "Because the data structure used by the frontend's JS plugin is different from the backend API structure" -> Here it makes sense to transform the data before sending it to the backend

There is a careful balance to strike here. You strike the appropriate balance by observing your situation. If your backend is a pure REST API which exposes your actual data entities, i.e. your backend is purely a database accessing service, then a lot of complexity can be cut out. If your backend performs its own business logic, then the necessity of separating your layers using DTOs becomes more important.

• "Because the frontend data structure is just different" -> Why is it different? Could it not just use the same structure as the backend? Because if it can, then you don't need a transformation at all.
• "Because the server stores the data in a different format" -> Your frontend does not need to know about the storage method your backend has decided to use, and therefore your frontend should not be responsible for transforming the data appropriately
• "Because the data structure used by the frontend's JS plugin is different from the backend API structure" -> Your backend does not need to know about the plugin your frontend has decided to use, and therefore your frontend should be responsible for transforming the data appropriately

There is a careful balance to strike here. You strike the appropriate balance by observing your situation. If your backend is a pure REST API which exposes your actual data entities, i.e. your backend is purely a database accessing service (where the backend API will inherently always expose the exact data entities without business logic inbetween), then a lot of complexity can be cut out. But your backend performs its own business logic, then the necessity of separating your layers using DTOs becomes more important.