What are GraphQL's five built-in scalar types, and how is ID different?

## Scalars are the leaves of the response tree A GraphQL response is a tree, and every branch of that tree has to stop somewhere. It stops at a **leaf type** — a scalar or an enum. These are the only types that carry no selection set: you can write `vehicle { id }`, but you cannot write `id { something }`, because `ID` is a scalar and there is nothing beneath it. A scalar is more than a label pinned on a JSON value. In the type system a scalar is *defined by two coercions*: * **Result coercion** — turning whatever the server holds internally into the value that goes into the response. * **Input coercion** — turning a value a caller supplied, either as a literal written in the document or as a value in the request's variables map, into whatever the server wants to hand a resolver. The five built-ins are simply the five scalars whose coercions the specification writes down for you, so that every server and every client agree on them without negotiating. ## Int `Int` is a **signed 32-bit non-fractional value** — roughly -2.1 billion to +2.1 billion. This is a specified constraint, not an implementation detail, and it is the single most frequently discovered surprise in the list. A fleet telematics graph that types `Vehicle.odometerMetres` as `Int` is fine for years and then is not, because a vehicle's cumulative metres eventually crosses the boundary. `Int` is not "an integer"; it is a 32-bit integer. ## Float `Float` is a **signed double-precision finite value** as described by IEEE 754. "Finite" is doing real work in that sentence: `NaN` and `Infinity` are not representable, so a resolver that computes an average over an empty set of readings and returns `NaN` has produced something the scalar cannot serialize. Input coercion is deliberately forgiving in one direction: an integer literal is a valid `Float` input, so `speedLimitKph: 60` is accepted for a `Float` argument. The reverse is not true — `4.5` is not a valid `Int` input. ## String `String` is textual data represented as a UTF-8 character sequence. It is the default for free text, and also the type every schema reaches for when it has not yet decided whether the value is really an enum, a date or an identifier. ## Boolean `Boolean` is `true` or `false`. Worth saying out loud in an interview: **nullability is a separate axis**. A field typed `Boolean` has three possible response values — `true`, `false` and `null`. If you meant two, you wrote the type wrong; you wanted `Boolean!`. ## ID — the one interviewers actually ask about `ID` represents a unique identifier, typically the value used to refetch an object or as a cache key. Its behaviour is asymmetric, and that asymmetry is the whole question: * **Coming in**, an `ID` argument accepts a string *or* an integer. This exists because backends have numeric primary keys and clients tend to hold strings, and the specification refuses to make you pick. `vehicle(id: 4712)` and `vehicle(id: "4712")` are both valid. * **Going out**, an `ID` is serialized the same way a `String` is. A resolver that returns the integer `4712` for an `ID` field produces `"4712"` in the JSON, not `4712`. A client written against a numeric field will break the day someone types it as `ID`. The specification also states that an `ID` is *not intended to be human-readable*. That is a message to the client: treat the value as opaque, do not parse it, do not sort on it, do not assume it is numeric. It says nothing about uniqueness enforcement — the server guarantees nothing; `ID` is documentation of intent plus a serialization rule, not a constraint. ## What is deliberately missing There is no built-in date, time, decimal, URL, UUID or JSON scalar. Every schema you have seen with a `DateTime` field defined one itself; those names are **widespread convention, not specification**. The absence is intentional: the specification declines to pick a serialization for values whose format is genuinely contested, and leaves you to declare a custom scalar and document it. ## A worked shape A telematics `Vehicle` uses four of the five in one type: an `ID` for the vehicle, a `String` for its plate, an `Int` for a small count, a `Float` for a measured value, and a `Boolean!` for a flag that must never be null. Everything else — a timestamp, a coordinate, a large odometer count — is where a schema starts needing types the specification does not hand you.