Test your Absinthe knowledge with a free interactive quiz — 20 questions with answers and explanations. No signup needed to play.
Question 1/12Score 0
Why might a team choose GraphQL (via Absinthe) over a traditional REST API for a Phoenix backend serving a complex frontend?
In this round
Why might a team choose GraphQL (via Absinthe) over a traditional REST API for a Phoenix backend serving a complex frontend?
Why does Absinthe integrate particularly well with the Phoenix web framework?
What does it mean that GraphQL (and Absinthe) queries are typically served over a single endpoint, unlike REST's many resource-specific endpoints?
What does defining a custom GraphQL scalar type in Absinthe (e.g. for a Date) allow?
How does Absinthe typically represent a validation or business-logic error returned from a mutation resolver?
What is the purpose of GraphQL "mutations" in an Absinthe schema, as distinct from "queries"?
Why might overly deep or complex GraphQL queries pose a performance/security concern for an Absinthe-backed API, and what is one way to mitigate it?
When an Absinthe schema evolves over time (e.g. adding a new field), why does GraphQL's design make backward-compatible evolution easier than many REST versioning schemes?
What does the "N+1 query problem" refer to in the context of GraphQL resolvers, and how does Absinthe commonly address it?
What is Absinthe?
What does an Absinthe "interface" type allow a schema to express?
Why would a team enable GraphiQL or GraphQL Playground alongside an Absinthe schema during development?