Does GraphQL obviate Data Transfer Objects? : <p>To my understanding, <a href="https://martinfowler.com/eaaCatalog/dataTransferObject.html" rel="noreferrer">Data Transfer Objects</a> (DTOs) are typically smallish, flattish, behavior-less, serializable objects whose main advantage is ease of transport across networks.  </p>

<p>GraphQL has the following facets: </p>

<ul>
<li>encourages serving <a href="https://graphql.org/learn/thinking-in-graphs/" rel="noreferrer">rich object graphs</a>, which (in my head anyway) contradicts the "flattish" portion of DTOs, </li>
<li>lets clients <a href="https://graphql.org/learn/queries/" rel="noreferrer">choose exactly the data they want</a>, which addresses the "smallish" portion,</li>
<li>returns <a href="http://graphql.org/learn/schema/" rel="noreferrer">JSON-esque objects</a>, which addresses the "behavior-less" and "serializable" portions</li>
</ul>

<p><strong>Do GraphQL and the DTO pattern mutually exclude one another?</strong></p>

<p>Here's what led to this question: We envision a microservices architecture with a gateway.  I'm designing one API to fit into that architecture that will serve  (among other things) <a href="https://msdn.microsoft.com/en-us/library/microsoft.sqlserver.types.sqlgeometry.aspx" rel="noreferrer">geometries</a>. In many (likely most) cases the geometries will not be useful to client applications, but they'll be critical in others so they must be served. However they're serialized, geometries can be big so giving clients the option to decline them can save lots of bandwidth. RESTful APIs that I've seen handling geometries do that by providing a <a href="https://developers.arcgis.com/rest/services-reference/query-feature-service-.htm" rel="noreferrer">"returnGeometry" parameter</a> in the query string. I never felt entirely comfortable with that approach, and I initially envisioned serving a reasonably deep set of related/nested return objects many of which clients will elect to decline. All of that led me to consider a GraphQL interface. As the design has progressed, I've started considering flattening the output (either entirely or partially), which led me to consider the DTO pattern. So now I'm wondering if it would be best to flatten everything into DTOs and skip GraphQL (in favor of REST, I suppose?).  I've considered a middle ground with DTOs served using GraphQL to let clients pick and choose the attributes they want on them, but I'm wondering if that's mixing patterns &amp; technologies inappropriately.</p>
