|
Yup, pretty much. However, the implications of veneer can be significant. Providing a single unified interface which provides granular, unified querying of disparate types has several benefits. In particular, it can simplify logic in the consuming application, and reduce network load (both in terms of the number of requests, and especially in the amount of data returned). For example, a pet website backed by a traditional REST architecture, may have separate endpoints for say `/pets`, `/owners`, and `/purchases `. In this context, the front-end may need to make calls to all three of these endpoints, retrieving the full payload for each - only to discard most of the fields, and keep 2 or 3 relevant ones from each entity. By comparisons, a GraphQL based approach would allow a single consolidate query for just those specific fields (from all entities). Of course this isn't relevant in every use case, and there's no silver bullet - and in many cases, a REST based approach may well be better. |