Here's the Universal API ORM for REST, SOAP and GraphQL and more - WunderGraph
CEO & Co-Founder at WunderGraph
May 15, 2023·12min read
Archive Notice
This article is archived and no longer maintained. It describes an earlier version of WunderGraph, including experimental features that are no longer part of the current product. The concepts and examples may not work as described. For current documentation and guidance, see WunderGraph Cosmo: WunderGraph Cosmo
What was a pipe dream for a long time is now a reality.
We're proud to announce the first release of the WunderGraph ORM. The WunderGraph ORM is a TypeScript ORM that gives you a single unified API to access all your data sources, from REST, SOAP, GraphQL, SQLite, MySQL, PostgreSQL, and more. This is a huge step towards our vision of making data and APIs more accessible to everyone.
At the same time, this marks the first time where we worked together with an outside OSS contributor. In that sense, all credits go to Tim Kenndal for making this possible. Without him, his in-depth knowledge of TypeScript, and his dedication to make this happen, this would not have been possible. Thank you, Tim! 🙏
State of GraphQL Federation 2026
How are teams governing schema changes, handling production traffic, and measuring Federation success? Share your experience and get early access to the full report. For every valid survey completed, we'll donate $30 to UNICEF.
What's the WunderGraph universal API ORM all about and how does it work?
Before we dive into a more lengthy explanation, let's take a look at a simple example. Let's fetch some data about a country, including the capital, and then fetch the weather for that capital city from another API.
import { createOperation } from '../../generated/wundergraph.factory'
export default createOperation.query({
handler: async ({ graph }) => {
const germany = await graph
.from('countries')
.query('country')
.where({ code: 'DE' })
.exec()
const weather = await graph
.from('weather')
.query('getCityByName')
.where({ name: germany.capital || '' })
.select(
'weather.summary.icon',
'weather.summary.description',
'weather.summary.title'
)
.exec()
return {
germany,
weather,
}
},
})
The first API call fetches data from the "countries" API, the second one has typesafe access to the response of the first API call and fetches the correlated weather data from the "weather" API. In addition, we're using the select method to reduce the response payload, which simultaneously reduces the TypeScript types of the response.
The whole operation is wrapped in a createOperation.query function call, which uses the TypeScript AST in a compile-time step to generate not just TypeScript models for a generated client, but also a JSON-Schema for the response which will be used to generate an OpenAPI Specification (OAS) as well as a Postman Collection for the resulting API.
Why is this a big deal and how is it better than using SDKs?
1. SDKs from different vendors & API styles have different ergonomics
No two SDKs are the same, especially when they are provided by different vendors or the underlying API style is different.
2. SDKs have varying levels of quality
Vendors like Stripe or Twilio provide great SDKs, but not every vendor has the resources to provide a great SDK.
3. SDKs are not always available
Not every API vendor provides an SDK, and this can lead to challenges when working with multiple APIs.
4. SDKs might come with a performance penalty
Using multiple SDKs could lead to a bloated bundle size and longer cold start times.
5. SDKs lock you into a specific vendor
Using an SDK may make it harder to switch to another vendor without incurring a high cost.
12. SDKs introduce inconsistent API key management
Handling API keys across multiple SDKs can lead to confusion and inconsistency.
How does the universal API ORM help build composable Applications?
Traditionally, we've been building monolithic applications. This means that we can call into any part of the application with a function call. Over time, we've started splitting up our applications into smaller composable parts, (micro)services. Both trends, Microservices and SaaS, have led to a distributed system architecture. To communicate with these distributed systems, we're using APIs.
Conclusion and Outlook
As you can see, the universal API ORM together with the reverse API Gateway pattern is a powerful combination to integrate APIs into your application. This approach comes with many benefits compared to the traditional approach of using SDKs.
If you're equally excited about the future for APIs, you can follow me on Twitter or join our Discord Community to stay up to date or get in touch.