Introduction

Imagine you're tasked to build a Single Page Application. To implement the app, you would have to fetch data from two REST APIs, one of which is from a third party, the second one is internal. You'd also have to use a legacy GraphQL API, provided by another team. Additionally, you'd also have to integrate three new GraphQL Services which use federation.

Without WunderGraph, you'd have to figure out a way to integrate all these services together. Here's an overview of questions you might be asking yourself.

• Should you do the integration in the front-end or the backend?
• Should you build a backend for frontend?
• Where should store API keys?
• How do you authenticate your users?
• How do you prevent malicious Requests?
• How do you implement authorization?
• What protocol should your client and server speak?
• What client implementation should you use?
• Do you need caching? If so, how and where should you cache data? Do you have users in different regions?
• Does your application require high availability?
• ... the list goes on

As you can see, there are a lot of decisions to be made and you can get easily distracted from your actual goal. Your boss, a product owner, yourself in case you're self-employed, etc. might or might not know all the problems we've listed above. However, they have a clear goal, they need their application. They need it on time, it should secure and performant. While it might be interesting to solve all these problems on your own, it's clearly a distraction from your business goal, building the actual app!

Here's how WunderGraph can help...

By using a simple configuration, we're creating a Virtual GraphQL API for all your services. This is also the reason why we call ourselves the package manager for APIs. With WunderGraph, you're able to treat APIs & Services like dependencies. You can easily share them with others or integrate them into your own projects.

Just to make it extra clear, we take all your REST- and other APIs and generate a unified GraphQL schema for them. We can automatically turn REST APIs specified using OpenAPI Specification (OAS) into GraphQL. If you're not 100% satisfied with the result, you can always hook into the process by writing some Typescript code.

Now that all API dependencies for our project are assembled, it's time to define our data requirements for the application. You do this by simply writing GraphQL Queries, Mutations & Subscriptions.

Allowing arbitrary GraphQL Operations at runtime opens up endless possibilities for attackers. That's why WunderGraph, by default, doesn't communicate with clients using GraphQL. Instead, WunderGraph uses a simple JSON-RPC protocol for communication. This drastically reduces the attack surface and makes client applications more performant by reducing unnecessary overhead.

WunderGraph automatically persists all GraphQL Operations and turns them into JSON-RPC endpoints. By doing so, it's very easy to define authorization rules for each endpoint. Additionally, because we're using JSON-RPC and not GraphQL at runtime, we're able to use standard Cache-Control Headers with directives like "stale-while-revalidate" that are supported by every browser. All this reduces unnecessary overhead and increases performance while it reduces possible attack vectors. But that's not all there is.

API Management vendors usually stop at the Gateway level. They might help you with server-side security and Caching but what about the client? This is where WunderGraph makes the difference. We care a lot about developer experience. That's why we don't just solve the above-mentioned problems for the backend side of things. We also solve the integration problem for the frontend-developer!

As we said above, we turn every GraphQL Operation into a JSON-RPC endpoint. As a user of WunderGraph, this might be an interesting detail we're happy to share with you, but you don't actually have to know. That is because with all the information we have about your APIs, the Virtual GraphQL Schema as well as the GraphQL Operations, we're able to generate a typesafe client.

This generated Client makes integration extremely easy because it's super smart. Setting up the client is one line of code, using one of the persisted Operations another line of code. Our super-smart client is not just capable of authenticating your users. It also knows if a user needs to be authenticated to use an Operation or not and can start or stop Queries & Mutations automatically based on their login state.

Sounds awesome? We're not yet done! Let's touch briefly on architecture to get the full picture.

As you can see from the architecture diagram, our client application uses the generated WunderGraph client to talk to one of the WunderNodes. WunderGraph manages Nodes in more than 20 regions for you. Each of your Environment will get its own Domain Name, usually "environment-name.wundergraph.dev" (custom domains are possible) backed by an Anycast IP address. This means that clients always connect to the nearest WunderNode to keep latency at a minimum. Alongside the WunderNodes, we have Cache-Servers in all regions. Combining JSON-RPC, generated clients and Cache-Servers in every region, we're able to offer the most efficient and developer-friendly Edge Caching solution imaginable. Simply configure cache & invalidation rules and the WunderNode plus generated WunderGraph client does the heavy lifting.

Coming back to our scenario and the list of questions we had in the beginning. With WunderGraph, you're able to mark the whole list as done and get back to your original task, building the Single Page Application.

We've been there too many times ourselves. There's simply too much boilerplate involved in building applications for the modern web. Users expect a lot and resources are scarce. We didn't want to build another app without having these problems solved once and for all. That's why we created WunderGraph in the first place. Let us do the boring parts so you can focus on what's important, your users!