Search
7 results for “graphql”
Search results
REST vs GraphQL
The real trade-offs between REST and GraphQL, over/under-fetching, caching, versioning, and when each one is the better default for an API.
What problem does GraphQL solve that REST does not, structurally?
Over-fetching and under-fetching. A REST endpoint returns a fixed shape, so a mobile client that only needs a user's name either gets the whole user object (over-fetching) or the API team has to add a new endpoint or query params for every new shape a client needs (under-fetching, solved by proliferating endpoints). GraphQL lets the client specify exactly which fields it wants in the query itself, so one flexible schema serves many different client needs without new endpoints.
Why is caching harder with GraphQL than REST?
REST responses map naturally to HTTP caching because a GET to a specific URL returns a predictable resource, so CDNs and browsers can cache by URL. GraphQL typically uses a single POST endpoint with a query body, which defeats standard HTTP/URL-based caching, most GraphQL setups instead rely on client-side normalized caches (like Apollo Client or Relay) keyed by object id and field, or persisted queries plus a CDN cache keyed on the query hash.
When would you choose REST over GraphQL for a new API?
When the API is simple, resource-shaped, and consumed by a small number of known clients with similar needs, REST's simplicity, mature tooling, and native HTTP caching usually win. GraphQL earns its added complexity (schema design, resolver N+1 management, more complex caching) when there are many different client shapes to serve, several frontends, mobile plus web, or third-party API consumers, where flexible field selection meaningfully reduces the number of purpose-built endpoints.
REST vs GraphQL
How REST and GraphQL differ in fetching, caching, and versioning, and which fits a given API better.
Why might a team deliberately choose IaaS over PaaS even though PaaS requires less operational work?
PaaS trades control for convenience; it constrains you to whatever runtimes, configurations, and scaling behavior the platform supports. Teams choose IaaS when they need capabilities a PaaS doesn't expose (custom OS-level tuning, unusual networking topologies, specific compliance requirements that mandate control over the underlying host), when they're running workloads a PaaS wasn't designed for, or when the cost model of many small PaaS instances doesn't make sense at their scale compared to self-managed infrastructure.
Why does explicitly telling a model it's allowed to say "I don't know" measurably reduce hallucination, and what's a second, complementary technique for the same problem?
Without that explicit permission, a model under an implicit expectation to always produce a confident, complete answer will sometimes fill a real information gap with a plausible-sounding but fabricated one; stating outright that uncertainty is an acceptable answer removes that pressure and lets the model surface "I don't have enough information" instead of guessing. A complementary technique for long documents is asking the model to first extract direct, word-for-word quotes relevant to the task before generating any analysis, grounding its response in verifiable text it actually has in front of it, and then citing which quote supports each claim, rather than generating an answer freely and hoping it stayed faithful to the source.