Should API DTOs be shaped to client(s) or be universal?

Question

I have a project with an internal desktop client app and a server-side client API service talking to a relational database. I seem to have two choices:

1) shape DTOs to client views, e.g. AccountOverviewInfoDto and AccountFullDetailsDto for a master-detail GUI scenario:

• + optimal amount of data is transferred;
• + server-side database queries are more optimal;
• + less object conversions/mappings are needed (domain -> DTO);
• - DTOs are coupled to different client GUI paradigms (desktop large screen vs mobile small screen);
• - client API is coupled to the client app in terms of changes and deployment.

2) make DTOs "universal" by keeping them close to domain model and then shape them to GUI via viewmodel objects:

• - non-optimal amount of data is transferred;
• - server-side database queries are less optimal;
• - more object conversions/mappings are needed (domain -> DTO -> viewmodel).
• + DTOs are decoupled from different client GUI paradigms (desktop large screen vs mobile small screen);
• + client API is decoupled from the client app in terms of changes and deployment.

What is the best practice if there is any? Are there any other choices?

Answer 1

Make sure you're optimizing the right thing.

If you were writing an MMO, shaving a second off transfer times or a couple bytes off some data might be significant.

For a company-internal app, the most critical resource is your time. If you go with your option 2 (universal DTOs that are not specific to a view) you'll stand a better chance of writing the code once.

If you go with your option 1 (DTOs "tuned" for a specific view), you'll be constantly coming back to this code to write more / tweak the ones you have / add fields / remove fields, and so on.

I strongly recommend you keep the code simple and short (which means generic DTOs) until specific testing has proved that you actually have a performance problem.