I am developing an electronic salary diary application. On the backend, I have "entries" entities with "Date" properties.
Now I have a react application that takes all the entries, groups them by month, and then by day. And it seems to me that I do a lot of unnecessary work on the client, because I also have such entities as "payment", "deduction" I also select them, in general, overloaded components are obtained.
Question. How much will it be right if I make a "WorkingMonth" service on the backend, and collect all the information there and issue it through some API endpoint? After all, there is no such entity.
First, how things are stored in your persistence layer shouldn't be a concern in terms of API design. Your data model isn't your object model, your object model isn't your API model. And you're realizing this.
That's why your API code exists, not to simply map columns on a database (or properties of a document) to a JSON (or XML) structure, but to map the model that works well for your code into a model that works well for your API client.
It may make sense to normalize the data and store it in a relational database on the server, while the client wants a bunch of related data together in something that makes sense in a specific context.
One thing you may want to keep in mind, if you're just trying to avoid the HTTP requests because the client code does work well traversing relationships your API exposes (which may be different than tables in a database) you could consider embedding some resources instead of creating a new 'aggregate' resource. But that really depends on the context.
Also, there's absolutely nothing wrong with exposing the same data in multiple resources, if that makes sense for the client.