This is a thoughtful point. It is true that Read concerns can be drastically different from Write concerns. For example, full text search may be very important for reads, but is excess baggage when processing use cases (writes). No style of API is going to solve this problem for you, since it has more to do with the underlying data structures. But message-based does have a couple of tricks.
For example, SearchCourses { Search: 'foo', Page: 1, PageSize: 20 } might return multiple rows with only a few columns, just enough for displaying in a list. Whereas GetCourse { CourseId: 123 } might return the full details for exactly one course. Another one GetCourseDashboard {} might return several sets of statistical data. For APIs which service applications, I tend to tailor every (query) message and its returned data to the specific screen that uses it.
I can also tell you what I do to solve the data structure problem: I no longer try to use a one-size-fits-all data model. I create multiple models of the same data to suit different purposes. One of the models needs to be authoritative (probably the write model), but others (probably read models) can be projected off of that one. For example, shipping your data to Elastic Search for indexing. Another example is an executive summary report (which is just an aggregated version of the data). These are obvious cases, but also think about each of the queries I mentioned in the paragraph above being backed by their own tables.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a thoughtful point. It is true that Read concerns can be drastically different from Write concerns. For example, full text search may be very important for reads, but is excess baggage when processing use cases (writes). No style of API is going to solve this problem for you, since it has more to do with the underlying data structures. But message-based does have a couple of tricks.
For example,
SearchCourses { Search: 'foo', Page: 1, PageSize: 20 }might return multiple rows with only a few columns, just enough for displaying in a list. WhereasGetCourse { CourseId: 123 }might return the full details for exactly one course. Another oneGetCourseDashboard {}might return several sets of statistical data. For APIs which service applications, I tend to tailor every (query) message and its returned data to the specific screen that uses it.I can also tell you what I do to solve the data structure problem: I no longer try to use a one-size-fits-all data model. I create multiple models of the same data to suit different purposes. One of the models needs to be authoritative (probably the write model), but others (probably read models) can be projected off of that one. For example, shipping your data to Elastic Search for indexing. Another example is an executive summary report (which is just an aggregated version of the data). These are obvious cases, but also think about each of the queries I mentioned in the paragraph above being backed by their own tables.