A mobile field-inspection app needs flexible, client-defined field selection over a graph of related assets instead of a fixed REST resource for every screen. Which API approach fits best?
Select an answer to reveal the explanation.
Short Explanation
The inspector's phone shouldn't download the whole warehouse to read one shelf label. AppSync GraphQL lets each screen ask for just the related asset fields it needs. One REST method per layout, giant S3 blobs, and Logs Insights are blunt tools for a flexible graph query.
Full Explanation
A mobile field-inspection app that needs flexible, client-defined field selection over a graph of related assets—rather than a fixed REST resource for every screen—fits AWS AppSync (GraphQL). Each screen queries exactly the related fields it needs (asset, last inspection, open violations, photos metadata), reducing over-fetch on constrained field networks and avoiding a combinatorial explosion of REST resources as UI layouts evolve.
Exposing only S3 presigned URLs and downloading full JSON blobs for every screen wastes bandwidth and pushes graph joining into the app. Creating one API Gateway REST method per screen layout and redeploying when UI fields change couples backend releases to mobile UX tweaks. Querying CloudWatch Logs Insights from the mobile client for asset relationships is not an application data API and is operationally inappropriate.
Exam caveat: GraphQL resolves need authZ at field/resolver level so inspectors only see authorized districts. AppSync can front DynamoDB/Lambda; design schema around domain graphs, not literally mirroring every table.
Operational check: define a GraphQL schema for assets and inspections; authorize by inspector role; measure payload sizes per screen; and version schema changes carefully for in-field app versions.