Häufig gestellte Fragen
What is GraphQL, explained simply?
GraphQL is an open query language and runtime for programming interfaces in which a calling application specifies via a single endpoint exactly which data fields it needs and receives exactly those in return. The foundation is a typed schema that describes all available objects, fields and relationships as a binding contract between the provider and the consumer of the data. GraphQL was developed internally at Facebook from 2012 onwards and released in 2015 as an open specification with a reference implementation; its further development has been managed since 2019 by the GraphQL Foundation, which was created under the umbrella of the Linux Foundation following the announcement in November 2018. In the ERP context, the language often serves as a flexible data access layer over highly interconnected business data.
What is the difference between GraphQL and REST?
The key difference lies in the structure of access: REST provides data via many individual endpoints, while GraphQL bundles all access through a typed schema and a single endpoint. With GraphQL, the client specifies precisely which fields it wants, which reduces so-called overfetching (too much data transferred) and underfetching (multiple calls needed for one view). REST, on the other hand, scores with simple caching via HTTP caching, broad tooling support and lower entry-level complexity. Which approach fits better depends on the use case and is not a question of general superiority.
When should you use GraphQL instead of REST?
GraphQL plays to its strengths above all with complex frontends that combine data from many interlinked sources in a single view, such as customer portals, mobile apps or dashboards spanning multiple ERP modules. For simple, clearly delimited integrations with few resources, REST is often the more pragmatic choice because caching and tooling are mature and getting started is easier. GraphQL also rarely offers clear advantages for pure machine-to-machine data transfers or established batch interfaces. In practice, the exact design varies depending on the industry, company size and degree of customization of the specific ERP setup, which is why both approaches are also used in parallel.
Is GraphQL faster than REST?
GraphQL is not automatically faster; the performance effect depends heavily on the specific implementation. An advantage arises when several REST calls are replaced by a single nested query, which reduces network round trips and the volume of data transferred. However, poorly optimised resolvers can trigger the so-called N+1 problem, in which one query internally results in many individual database accesses; this is usually countered with batching techniques such as DataLoader. In addition, HTTP caching is easier with REST via individual endpoints, so GraphQL should be evaluated on a per-use-case basis.
What security aspects need to be considered with GraphQL?
GraphQL's flexible, deeply nestable access brings its own security requirements, which must be safeguarded with a well-thought-out permission and role concept. A key vulnerability is complexity and depth attacks, in which clients can formulate arbitrarily nested queries and thereby generate considerable server load; many frameworks do not enable depth limits by default. Common protective measures are therefore query depth limits, query cost analysis, rate limiting and so-called persisted queries, which only allow predefined queries. Introspection, which exposes the entire schema, is also frequently restricted in production environments so as not to hand attackers a detailed map of the data.
Do ERP systems like SAP or Microsoft Dynamics offer GraphQL?
Native GraphQL interfaces are still the exception in classic ERP systems: both SAP and Microsoft Dynamics 365 rely primarily on OData or REST-based web APIs as the standard access route to their data. GraphQL access in these environments therefore usually arises via upstream integration platforms, adapters or translation layers that convert existing OData or REST endpoints into a GraphQL schema. Some more modern, decoupled architectures, such as headless or composable ERP approaches, however, increasingly provide GraphQL natively. When selecting a system, it is advisable to specifically ask about the availability and the manner of provision of a GraphQL interface in the requirements specification (Lastenheft) and functional specification (Pflichtenheft).