Points: ① Design Schema around client-specific use cases ② Move business logic to the Backend ③ Close collaboration with Client side engineers Benefits: • Simplified Schema • Reduce Over-fetching • Improved Developer Experience • Easier to Understand and Maintain • Reduce QA cost
Logic needs to be handled on each client (Web, iOS, Android) • More data than needed is requested from the API • QA cost increase to confirm implementation on each client Hotel Card / Spoken Languages
Logic is hidden on the backend • Client implementation is simplified • API tests can be written to confirm use cases • QA cost decrease Hotel Card / Spoken Languages
The client depend on 2 fields to display the price • The format needed to be coordinated between clients and places • QA cost increase Hotel Card / Price
Only one field is needed to display the price • The format is controlled by the Backend, and consistency between apps is simple • QA cost decrease Hotel Card / Price
To know if a Hotel is included inside the authenticated user Wishlist, a different query is needed • The client needs to control the logic • QA cost increase • … Hotel Card / Wishlist
Things that always need to be displayed together are together • Client logic is simplified, and business logic is hidden on the backend • QA cost decreases • … Hotel Card / Wishlist
collaboration with Client side engineers • Prioritize client needs, but not just one client's needs • Client teams should be consulted early on in the API design process. • Schema should be approved by client teams before implementation Spec Check Schema Proposal Mock Implementation Final Implementation Backend + Client engineers involved in all process
schema / 1 endpoint 2) Demand Oriented Schema Design: • Schema Design based on Client use cases • Reduce client-side complexity by moving Business Logic to the backend • Close collaboration with Client side engineers Summary