This post explains why we've started building WunderGraph, what problems we're trying to solve, and how. It also helps you to understand the differences between WunderGraph and existing tools.
What Problem is WunderGraph solving?
A common problem that you're faced with when building web applications is that each application requires a unique composition of internal and external APIs, databases, file storages and authentication providers. Once you've created such a composition, it needs to be enriched with business logic and data transformations using Middleware functions.
Companies keep inventing their own solutions to this problem, the most famous one is based on the BFF pattern (Backend for Frontend), where you create a specific backend for each individual frontend. But even with the BFF pattern, the flow is still not standardized, so companies are re-inventing the wheel over and over again.
WunderGraph set sail to solve this problem. We're building on open standards, like GraphQL, REST, OpenAPI OpenID Connect, OAuth2, AsyncAPI and more to create a standardized approach to creating API Compositions and Integrations.
Aside from simply solving this problem, we're also changing the workflow of the development process. We've figured that existing tools in the market don't really fit into the Lifecycle of Software Development.
API Management that blends into existing Development Workflows
The problem with existing tools like Kong, Apigee or Tyk can be very easily observed when you go through their "Getting Started" docs. From their perspective, you should start by Deploying an API Gateway, followed by adding & securing your first API to the gateway using their user interface.
This Workflow is completely disconnected from how Developers work nowadays. Software Development is organized around git repositories, infrastructure is configured using code, not dashboards, and deployments are done using CI/CD Automation, not mouse clicks in dashboards.
Gateway-Less API Management doesn't mean there's no gateways, but we've abstracted away the Gateway part
To solve the problem, we've developed a new way of managing APIs: Gateway-Less API Management.
It's widely known that API Gateways are very powerful to manage cross-cutting concerns like authentication, authorization, security, rate limiting, etc... But that doesn't mean that Developers should give up their existing WorkFlow, just to be able to use a Gateway. WunderGraph abstracts away the Gateway, allowing you to configure and manage your APIs by writing code that's part of your git repository. Combined with CI/CD Automation, you're back to the old Workflow, but now you're managing APIs in a declarative way.
Made a mistake? You can easily revert your changes. Want to see how a change might affect the application? Deploy a preview version by creating a new branch and committing your code. There are no Gateways or dashboards you have to worry about. It's the next generation of API Management.
The right level of abstraction to create the best possible Developer Experience
When your goal is to compose a number of APIs into a single API, existing tools expect you to solve this problem on your own, e.g. by creating a BFF. Once you're done with the BFF part, you can expose the API through a legacy API Gateway.
The next step is to integrate the API into your Frontend application, but again, you're on your own. Legacy API Gateways don't care about how you're using your APIs. They give you a middleware to validate JWTs, but it's your own problem how the Frontend acquires the JWT. That's not End-To-End thinking, it's not the right Experience to really enable Developers to ship fast and focus on the essential parts.
In contrast, WunderGraph gives you an End-To-End experience, from composing your APIs, Databases, File Storages and Auth Providers into a single unified API, to integrating the API into your Frontend application.
Through configuration, you're not just configuring your API Endpoints, Middleware and so on, but also generate TypeSafe client libraries which handle Authentication, API Calls, File Uploads, etc...
With WunderGraph, Developers can really focus on what matters: Business Logic and a great User Experience.
Declarative API Dependencies - A new way to think about APIs
Another problem we've seen in most Web Applications is that Developers manage their API dependencies implicitly.
We're using Package Managers like NPM, Maven or Go Modules to manage our "Code Dependencies" for many years now. Yet, when it comes to managing APIs, we're still in the Stone-age.
Sometimes, we're installing SDKs to use an API, but more often than not, we're simply making up HTTP Requests to use an API. Secrets and API Credentials are spread across the codebase. The end result is that our code might be clean, but we've got absolutely no idea what APIs we depend on.
WunderGraph on the other hand allows you to declare your API dependencies explicitly. You can feed WunderGraph with a list of Services you'd like to use. We'll use Introspection to discover the APIs and turn them into what we call the "Virtual Graph".
The Virtual Graph is a composed GraphQL Schema of all your APIs. We currently support OpenAPI, GraphQL, Apollo Federation, Various Databases and more for Introspection, with gRPC, Kafka, and many others on the list.
The Virtual Graph allows Developers to talk to any Service of the Composition through a single unified Interface, while making it explicit what services and endpoints you depend on.
How a Unified Graph of API Dependencies improves your Architecture
This single unified API is a great way to improve your Architecture.
Without WunderGraph, your Frontend depends on multiple APIs and Services directly. In the worst case scenario, N APIs might depend on M Services, while M Services depend on N APIs. Each individual connection can be managed by an API Gateway, but the composition of connections is not.
With WunderGraph, you compose multiple APIs into a Bundle, which is then connected to a single Frontend Application. API Dependencies in this case are clearly defined, and policies for Authentication, Authorization, Caching, etc... can be configured for the whole Composition.
It might not be obvious, but being able to define Security Policies for a Composition of OpenAPI, GraphQL, Kafka and PostgreSQL at the same time makes a Developer's life much easier. Logs and Metrics become so much more meaningful if applied to the Composition as a whole, and not just to individual API Endpoints.
We live in a world full of internal (Micro-) Services and external 3rd Party APIs. For each individual problem, there's an API that can solve it. WunderGraph makes it so that all the pieces of the puzzle fit nicely together.
Now it's up to you, the Developers, to leverage the benefits of API Composition and build great Applications on top of it!