I am a little worried about the scope of the backend order book api. Imo there are are three broad categories of apis:

1. Api needed for the system to run. This is roughly what we have implemented right now. It allows users to submit orders, delete orders, get the minimum fee and solvers to get all solvable orders. It operates on low level data that matches how the smart contract works.
2. Api that makes the order book easier to use for people who call it directly (including the frontend). Things like getting all of the orders of a specific user including unsolvable orders (for example because filled), getting denormalized data like a more abstract order state, getting executed trades for an order.
3. Api that implements functionality specific only to our frontend. Things like top traded tokens or other statistics that we want to show in our frontend but that we don't expect other people to use directly. The border to 2. is fuzzy.

The reason I am making this distinction is because I feel that right now we are mixing all three categories together and before we implement further apis we should consider if we want to separate them in some way. The drawbacks I see:

• Individual routes become more awkward as they have to handle more use cases and creates dependencies between unrelated things. For example get_orders from the perspective of the solvers does not need a user filter and OrderMetaData does not need to contain a executedSellAmountBeforeFees field. But of those are useful for the frontend.
• Development is harder. When we change a route we have to consider how this affects all categories instead of just one.
• The deployment is less resilient. If we have a bug or a panic or in for example complicated web socket code for the frontend then that shouldn't bring down the category 1 api.

What I would like to do is at least separate category 1 from the rest on a route and code level. We could have a paths like (ignoring bad naming) /api/minimal/v1, /api/user-friendly/v1 and implement them in different rust modules. This gets rid of the api level entanglement. It will make it easier to move to separate crates / binaries in the future which has more organizational overhead so we might not want to that right now.
I hope that from the perspective of the frontend this would increase our development velocity and potentially allow frontend team members to implement some apis directly in rust themself without probably waiting (probably frustratingly long) for us to discuss and implement the suggestions.

Original issue gnosis/gp-v2-services#297 by @vkgnosis