<article><p>After much requests we are excited to announce the release of the new WunderGraph React Query client. This new client is built on top of <a href="https://tanstack.com/query/v4">TanStack React Query</a>, a powerful data fetching library for React. It allows you to consume WunderGraph queries, mutations and subscriptions fully typesafe with React Query.</p><p>We took all the lessons learned from building our new SWR integration and applied them to this new client. This means that you can use the same features as with the SWR integration, like optimistic updates, invalidating queries, and more with a similar easy to use and typesafe API.</p><p>Currently we only support React, but thanks to TanStack we are now able to add support for other frameworks like Vue, Solid.js and soon Svelte. We would love to have your help in building these integrations. Check out the <a href="https://github.com/wundergraph/wundergraph/tree/main/packages/react-query">React Query source code</a> to get started. ❤️</p><h2>What's new</h2><p>Let's dive a bit into what's new and how some of the React Query features work with WunderGraph.</p><h3>Queries</h3><pre data-language="ts">const { data, error } = useQuery({
  operationName: 'Weather',
  input: {
    forCity: 'Berlin',
  },
})
</pre><p>Conditionally fetching data:</p><pre data-language="ts">const { data: user } = useUser()

const { data, error, refetch } = useQuery({
  operationName: 'ProtectedWeather',
  input: {
    forCity: 'Berlin',
  },
  enabled: !!user,
})
</pre><p>Note that <code>refetch</code> is slightly different from SWR, instead <code>mutate</code> we can call <code>refetch</code> to refetch a specific query.</p><p>Turn queries into live queries, live queries are refetched on a interval on the WunderGraph server.</p><pre data-language="ts">const { data, error } = useQuery({
  operationName: 'Weather',
  input: {
    forCity: 'Berlin',
  },
  liveQuery: true,
})
</pre><h3>Subscriptions</h3><p>Build realtime apps with subscriptions.</p><pre data-language="ts">const { data, error, isLoading, isSubscribed } = useSubscription({
  operationName: 'Countdown',
  input: {
    from: 100,
  },
})
</pre><h3>Mutations</h3><pre data-language="ts">const { data, error, mutate, mutateAsync } = useMutation({
  operationName: 'SetName',
})

mutate({ name: 'Eelco' })

// Async mutate
const result = await mutateAsync({ name: 'Eelco' })
</pre><h3>Invalidating queries</h3><p>Let's say we have a query that fetches the current user's profile in one component and we have a form that updates the profile. We can add an <code>onSuccess</code> handler to the mutation that calls <code>queryClient.invalidateQueries</code> on the <code>GetProfile</code> query and trigger a refetch and update the internal React Query cache.</p><pre data-language="ts">const Profile = () =&gt; {
  const { data, error } = useQuery({
    operationName: 'GetProfile',
  })

  return &lt;div&gt;{data?.getProfile.name}&lt;/div&gt;
}

const FormComponent = () =&gt; {
  const queryClient = useQueryClient();

  const { data, error, mutate } = useMutation({
    operationName: 'UpdateProfile',
    onSuccess() {
      // invalidate the query
      queryClient.invalidateQueries(queryKey({ operationName: 'GetProfile' }));
    },
  })

  const onSubmit = (event) =&gt; {
    e.preventDefault();
    const data = new FormData(event.target);
    mutate(data)
  }

  return &lt;form onSubmit={onSubmit}&gt;&lt;input name=&quot;name&quot; /&gt;&lt;button type=&quot;submit&quot;&gt;Save&gt;&lt;/button&gt;&lt;/form&gt;
}
</pre><p>Now we could even make this fully optimistic by updating the <code>GetProfile</code> cache instead and then refetching it, it would look something like this:</p><pre data-language="ts">const FormComponent = () =&gt; {
  const queryClient = useQueryClient();

  const { data, error, mutate } = useMutation({
    operationName: 'UpdateProfile',
    onMutate: async (data) =&gt; {
      const key = queryKey({ operationName: 'GetProfile' })
      // Cancel any outgoing refetches
      // (so they don't overwrite our optimistic update)
      await queryClient.cancelQueries(key)

      // Snapshot the previous value
      const previousProfile = queryClient.getQueryData&lt;Profile&gt;(key)

      // Optimistically update to the new value
      if (previousProfile) {
        queryClient.setQueryData&lt;Profile&gt;(key, {
          ...previousProfile,
          ...data
        })
      }

      return { previousProfile }
    },
    // If the mutation fails,
    // use the context returned from onMutate to roll back
    onError: (err, variables, context) =&gt; {
      if (context?.previousProfile) {
        queryClient.setQueryData&lt;Profile&gt;(queryKey({ operationName: 'GetProfile' }), context.previousProfile)
      }
    },
    // Always refetch after error or success:
    onSettled: () =&gt; {
      queryClient.invalidateQueries(queryKey({ operationName: 'GetProfile' }))
    },
  })

  const onSubmit = (event) =&gt; {
    e.preventDefault();
    const data = new FormData(event.target);
    mutate(data)
  }

  return &lt;form onSubmit={onSubmit}&gt;&lt;input name=&quot;name&quot; /&gt;&lt;button type=&quot;submit&quot;&gt;Save&gt;&lt;/button&gt;&lt;/form&gt;
}
</pre><p>Check out the reference and example app below to learn more about the new React Query integration.</p><h2>Resources</h2><ul><li><a href="https://docs.wundergraph.com/docs/clients-reference/react-query">React Query reference</a></li><li><a href="https://docs.wundergraph.com/docs/examples/nextjs-react-query">Next.js + React Query Example</a></li><li><a href="https://tanstack.com/query/v4/docs/adapters/react-query">TanStack React Query</a></li></ul><h2>Summary</h2><p>You can now easily integrate WunderGraph with React Query and start building end-to-end typesafe applications with WunderGraph. Thanks go out to Tanstack for making this great data fetching library.</p><p>We would love to know more about your experience with React Query and looking forward to seeying what you build with it. Share it in the comments below or come join us on our <a href="https://wundergraph.com/discord">Discord server</a>.</p><p>Are you ready for the next generation of <s>Serverless</s> Infraless API Development? Join the waitlist for WunderGraph Cloud Early Access and be the first to try it out.</p></article>

Introducing the new WunderGraph React Query client. Consume WunderGraph queries, mutations and subscriptions fully typesafe with React Query.

Introducing the new React Query client

<article><p>Our first Next.js client took a lot of inspiration from SWR, but we choose to build our own fetching library because SWR was lacking a couple of important features that we needed. Most notably built-in support for authentication, mutations (SWR is focused on fetching data, not updating it) and better SSR functionality. This suited us well at first, but along the way we realised that we had to build and maintain a lot of the same features that SWR already had. Why solve a problem that has already been solved?.</p><p>We started experimenting with using our TypeScript client together with SWR while building our cloud alpha. This turned out to be a great match, our TypeScript client is using fetch for making requests to the WunderGraph API, which is serving GraphQL operations over a JSON RPC style API and allows us to benefit from techniques like <code>stale-while-revalidate</code>. Which is exactly what SWR stands for.</p><p>Quickly after that we released our official integration with SWR, so we could start testing with the community. This was well received and it greatly improved the developer experience for our users. It gave us extra features like optimistic updates, invalidating queries, middleware support (more on this later) and it drastically reduced the amount of complexity in our code. This gave us the confidence to make SWR our default data fetching library for React and with the release of SWR 2.0RC it was time to rewrite our Next.js client to use SWR.</p><p>Now let's dive into the details of the new Next.js client. See what's changed and how you can use the new features.</p><p>This post applies to:</p><ul><li><code>@wundergraph/nextjs</code> &gt;= 0.5.0</li><li><code>@wundergraph/swr</code> &gt;= 0.7.0</li><li><code>swr</code> &gt;= 2.0.0-rc.0</li></ul><h2>What's new</h2><p>We tried to keep the new API similar to the previous, but there are some notable (breaking) changes.</p><p>The generated Next.js client no longer creates individual hooks for every operation, but instead we simply have 3 hooks, <code>useQuery</code>, <code>useSubscription</code> and <code>useMutation</code> that are fully typed. This makes the code very lightweight in production bundles while still benefiting from the full power of TypeScript.</p><h3>Queries</h3><p>Instead of:</p><pre data-language="ts">const { response, refetch } = useQuery.Weather({
  input: {
    forCity: 'Berlin',
  },
})
</pre><p>You can now write:</p><pre data-language="ts">const { data, error, mutate } = useQuery({
  operationName: 'Weather',
  input: {
    forCity: 'Berlin',
  },
})
</pre><p>Conditionally fetching data is now also possible:</p><pre data-language="ts">const { data: user } = useUser()

const { data, error, mutate } = useQuery({
  operationName: 'ProtectedWeather',
  input: {
    forCity: 'Berlin',
  },
  enabled: !!user,
})
</pre><p>Note that <code>refetch</code> has been renamed to <code>mutate</code> to be inline with the SWR API. Calling <code>mutate()</code> will invalidate the cache and refetch the query, you can also pass data to <code>mutate</code> to update the cache without refetching, this is useful for optimistic updates for example.</p><p>There is no <code>useLiveQuery</code> hook anymore, this is now just <code>useQuery</code> with the <code>liveQuery</code> option set to <code>true</code>, allowing you to easily turn every query into a live query.</p><pre data-language="ts">const { data, error } = useQuery({
  operationName: 'Weather',
  input: {
    forCity: 'Berlin',
  },
  liveQuery: true,
})
</pre><h3>Subscriptions</h3><p>Subscriptions have a similar API. Nothing significant has changed here, but you can now check if a subscription is being setup or is active with the <code>isLoading</code> and <code>isSubscribed</code> properties.</p><pre data-language="ts">const { data, error, isLoading, isSubscribed } = useSubscription({
  operationName: 'Countdown',
  input: {
    from: 100,
  },
})
</pre><h3>Mutations</h3><p>Mutations are also very similar to the previous API. <code>mutate</code> has been renamed to <code>trigger</code> to prevent confusion with the <code>mutate</code> function from SWR.</p><pre data-language="ts">const { data, error, trigger } = useMutation({
  operationName: 'SetName',
})

// trigger is async by default
const result = await trigger({ name: 'Eelco' })

// prevent the promise from throwing
trigger({ name: 'Eelco' }, { throwOnError: false })
</pre><p>What's great about the new API is that it's now easier to invalidate queries after a mutation.</p><p>Let's say we have a query that fetches the current user's profile in one component and we have a form that updates the profile. We can add an <code>onSuccess</code> handler to the mutation that calls <code>mutate</code> (invalidate) on the <code>GetProfile</code> query.</p><pre data-language="ts">const Profile = () =&gt; {
  const { data, error } = useQuery({
    operationName: 'GetProfile',
  })

  return &lt;div&gt;{data?.getProfile.name}&lt;/div&gt;
}

const FormComponent = () =&gt; {
  const { mutate } = useSWRConfig()

  const { data, error, trigger } = useMutation({
    operationName: 'UpdateProfile',
    onSuccess() {
      // invalidate the query
      mutate({
        operationName: 'GetProfile',
      })
    },
  })

  const onSubmit = (event) =&gt; {
    e.preventDefault();
    const data = new FormData(event.target);
    trigger(data, { throwOnError: false })
  }

  return &lt;form onSubmit={onSubmit}&gt;&lt;input name=&quot;name&quot; /&gt;&lt;button type=&quot;submit&quot;&gt;Save&gt;&lt;/button&gt;&lt;/form&gt;
}
</pre><p>Now we could even make this fully optimistic by mutating the <code>GetProfile</code> cache instead and then refetching it, it would look something like this:</p><pre data-language="ts">const FormComponent = () =&gt; {
  const { mutate } = useSWRConfig()

  const { data, error, trigger } = useMutation({
    operationName: 'UpdateProfile',
  })

  const onSubmit = (event) =&gt; {
    e.preventDefault();
    const data = new FormData(event.target);
    mutate(
      {
        operationName: 'GetProfile',
      },
      async () =&gt; {
        const result = await trigger(data)
        return {
          getProfile: result.updateProfile,
        }
      },
      {
        optimisticData: {
          getProfile: data,
        },
        rollbackOnError: true,
      }
    )
  }

  return &lt;form onSubmit={onSubmit}&gt;&lt;input name=&quot;name&quot; /&gt;&lt;button type=&quot;submit&quot;&gt;Save&gt;&lt;/button&gt;&lt;/form&gt;
}
</pre><h2>SSR</h2><p>The new client also supports SSR and even works with live queries and subscriptions.</p><p>Simply wrap your <code>App</code> or <code>Page</code> with <code>withWunderGraph</code> and you're good to go.</p><pre data-language="tsx">const HomePage = () =&gt; {
  const { data, error } = useQuery({
    operationName: 'Weather',
    input: {
      forCity: 'Berlin',
    },
    liveQuery: true,
  })

  return (
    &lt;div&gt;
      &lt;h1&gt;Weather&lt;/h1&gt;
      &lt;p&gt;{data?.weather?.temperature}&lt;/p&gt;
    &lt;/div&gt;
  )
}

export default withWunderGraph(HomePage)
</pre><p>So how does this work?</p><p>Just like the old client we use <code>react-ssr-prepass</code> to render the component tree on the server inside <code>getInitialProps</code> and collect all fetch promises from the <code>useQuery</code> and <code>useSubscription</code> hooks and wait for them to resolve. This is then passed to the client, which is then passed to the <code>SWRConfig</code> <a href="https://swr.vercel.app/docs/with-nextjs">fallback option</a>. This is all done automatically, you don't have to do anything.</p><p>As I explained in the introduction, <a href="https://swr.vercel.app/docs/middleware">SWR supports middlware</a>, which is a really powerful feature and allows you to add functionality to individual hooks or globally using <code>SWRConfig</code>. The Next.js package uses middleware to add support for SSR to the hooks. Let's go a bit into to details how this works.</p><h2>Middleware</h2><p>Our SSR middleware is added to <code>SWRConfig</code> internally by <code>withWunderGraph</code>, I'll go over the code here to explain how it works.</p><pre data-language="ts">export const SSRMiddleWare = ((useSWRNext: SWRHook) =&gt; {
	return (key: Key, fetcher: BareFetcher&lt;Promise&lt;unknown&gt;&gt; | null, config: SSRConfig) =&gt; {
        // middleware logic
    }
})

&lt;SWRConfig value={{ use: [SSRMiddleWare] }}&gt;
  // your app
&lt;/SWRConfig&gt;
</pre><p>This is how the logic works. First we check if this hook is being called on the server, if SSR is enabled and if it is a WunderGraph operation. If not we just return the swr hook.</p><pre data-language="ts">const swr = useSWRNext(key, fetcher, config)

const context = useWunderGraphContext()

const isSSR =
  typeof window === 'undefined' &amp;&amp; context?.ssr &amp;&amp; config.ssr !== false

if (!isOperation(key) || !context || !isSSR || !key) {
  return swr
}
</pre><p>Now we serialize the key that we need for the ssrCache and to pass it down to the SWR <code>fallback</code>. We check if this is an authenticated operation, if the user isn't logged in we don't need to execute the operation for SSR.</p><p>LiveQueries and subscriptions don't have a fetcher because data is loaded async, but for SSR we create a fetcher that will call the query with <code>subscribeOnce</code> set to true. This will return the subscription data directly instead of setting up an event stream, so we can server side render subscriptions ❤️.</p><pre data-language="ts">const { operationName, input, liveQuery, subscription } = key

const _key = serialize(key)

const { ssrCache, client, user } = context

const shouldAuthenticate =
  client.isAuthenticatedOperation(operationName) &amp;&amp; !user

let ssrFetcher = fetcher
if (!ssrFetcher &amp;&amp; (liveQuery || subscription)) {
  ssrFetcher = async () =&gt; {
    const result = await client.query({
      operationName,
      input,
      subscribeOnce: true,
    })
    if (result.error) {
      throw result.error
    }
    return result.data
  }
}
</pre><p>Now we set the fetcher to our ssrCache with the serialized key. Which is then read in <code>getInitialProps</code>, returned to the client and passed to the <code>fallback</code> option of <code>SWRConfig</code> and SWR + Next.js do the rest.</p><pre data-language="ts">if (ssrCache &amp;&amp; !ssrCache[_key] &amp;&amp; ssrFetcher &amp;&amp; !shouldAuthenticate) {
  ssrCache[_key] = ssrFetcher(key)
}

return swr
</pre><h2>Resources</h2><ul><li><a href="https://docs.wundergraph.com/docs/clients-reference/nextjs">Next.js reference</a></li><li><a href="https://docs.wundergraph.com/docs/clients-reference/swr">SWR reference</a></li><li><a href="https://docs.wundergraph.com/docs/examples/nextjs">Next.js example</a></li></ul><h2>Summary</h2><p>So that's it, we are now using SWR as our default data fetching library, giving you all the benefits, like optimistic updates while consuming WunderGraph APIs. It already improved our internal developer experience a lot and we are excited to hear about your experience with the new clients.</p><p>We're also interested in your experience about this topic in general.</p><ul><li>Are you using SWR? What do you think about it? What are your favorite features?</li><li>Do you use other libraries for data fetching and cache management, like React Query? (hint; we will release a React Query integration soon).</li></ul><p>Share it in the comments below or come join us on our <a href="https://wundergraph.com/discord">Discord server</a>.</p><p>Are you ready for the next generation of <s>Serverless</s> Infraless API Development? Join the waitlist for WunderGraph Cloud Early Access and be the first to try it out.</p></article>

Introducing the new Next.js and SWR clients

<article><p>When I started my career as a developer, my continuous integration workflow looked like this:</p><ol><li>Open FTP client</li><li>Connect to the server</li><li>Drag index.php from left to right</li><li>Close FTP client</li></ol><p>My internet connection was slow, but it only took a few seconds to &quot;deploy&quot; my PHP application. I was new to programming, but I was able to get my code into &quot;production&quot; in just a few seconds. It was a great feeling to see my first website live on the internet. I have to admit, testing wasn't really automated, but my human CD pipeline was fast and reliable.</p><p>If you think about it, this was actually &quot;Serverless&quot;. I didn't have to worry about servers. I just had to upload my code to the &quot;webspace&quot; and it was live.</p><p>Next, I wanted to add a database to my application. Here's the simplest code example I can find today:</p><pre data-language="php">&lt;?php
$servername = &quot;localhost&quot;;
$username = &quot;username&quot;;
$password = &quot;password&quot;;
$dbname = &quot;myDB&quot;;

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn-&gt;connect_error) {
  die(&quot;Connection failed: &quot; . $conn-&gt;connect_error);
}

$sql = &quot;SELECT id, firstname, lastname FROM MyGuests&quot;;
$result = $conn-&gt;query($sql);

if ($result-&gt;num_rows &gt; 0) {
  // output data of each row
  while($row = $result-&gt;fetch_assoc()) {
    echo &quot;id: &quot; . $row[&quot;id&quot;]. &quot; - Name: &quot; . $row[&quot;firstname&quot;]. &quot; &quot; . $row[&quot;lastname&quot;]. &quot;&lt;br&gt;&quot;;
  }
} else {
  echo &quot;0 results&quot;;
}
$conn-&gt;close();
?&gt;
</pre><p>If you copy this file to the webserver, you have a fully functional application that can read and write data from a database. It's incredible how simple this concept was. A complete application in just one file. The &quot;application&quot; starts when the user opens the URL in the browser, and it ends when we're done sending the response to the user. That's as &quot;Serverless&quot; as it gets.</p><p>Nowadays, we've gone absolutely crazy. We have AWS, Kubernetes, CDK, Terraform, Docker, Serverless, GraphQL, gRPC, REST, and so much more. You need many years of experience to be able to set up a project with this &quot;modern stack&quot;. It's pure madness.</p><p>You need Webpack or another tool to bundle your code, minify and optimize it. Build and publish Docker images, or upload zip files to AWS Lambda. And then there's yaml all over the place to configure your infrastructure.</p><p>Architects proudly show off their &quot;serverless&quot; architecture diagrams on conferences with hundreds of components. I think to myself: &quot;Why is this so complicated?&quot; Why are there so many moving parts? There are specialised AWS consultants who earn a lot of money because nobody understands Cloud anymore.</p><p>Our goal is to change this. We want to make using the cloud as easy as it was in the old days. But first, let's take a step back and look at the problem from a different angle.</p><h2>The rise of NextJS and Vercel</h2><p>From the early days on, I really enjoyed working with ReactJS. But for the first few years, there was a huge problem. I was constantly on the lookout for the perfect &quot;boilerplate&quot;. Getting ReactJS right wasn't easy, especially if you want to have server-side rendering, hot reloading, and all the other features that make for a great developer experience.</p><p>Then, in 2016, a new project called NextJS was released. It took NextJS a while to win the hearts of the community, but today it's the most popular ReactJS framework.</p><p>With NextJS, I was able to stop my search for the perfect boilerplate. The framework might not be perfect in every way, but it's good enough for most projects. I can focus on the actual application instead of spending hours on figuring out how to do X.</p><p>That said, NextJS wasn't alone. Along with NextJS came Zeit, a company that was founded by Guillermo Rauch, later renamed to Vercel.</p><p>In Germany, we like to say &quot;Es wird höchste Zeit&quot; which means &quot;It's about time&quot;. Vercel was the first company to understand that it's about &quot;Zeit&quot; to make deploying frontend applications easy.</p><p>Vercel developed a simple but powerful playbook:</p><ol><li>Create an opinionated open source framework to consolidate the work of the community</li><li>Add features that focus on developer experience, productivity and ergonomics</li><li>Build a hosting platform that deploys your code on git push</li><li>Abstract away the complexity of the underlying infrastructure so developers can focus on their code</li></ol><p>With this playbook, we're almost back to the simplicity of the PHP example above. Unsurprisingly, NextJS adds more complexity than a single PHP file, but we get a lot of value in return.</p><p>Most importantly, we're back to the simplicity in terms of DevOps. Instead of dragging files from left to right, we just push our code to a git repository. The rest is handled by the hosting platform for us, and we're not just talking about a simple hosted NodeJS server.</p><p>Vercel creates Serverless functions for server-side rendering, provides a CDN for static assets, runs middleware on the edge, integrates with GitHub, and builds previews on every git push.</p><p>Now that we have NextJS and Vercel, we can say that &quot;Frontend&quot; is a solved problem. But what about the backend?</p><h2>Finding the right platform for the backend is hard</h2><p>When you ask developers where to host their backend, you'll get a lot of different answers.</p><p>What all of them have in common is that they require a lot of DevOps and infrastructure knowledge. They offer you Redis and Postgres, they talk about Docker and containers. They have endless documentation and tutorials on how to set up the database and so on.</p><p>Compare this to the simplicity of NextJS and Vercel. Backend seems to be years behind frontend in terms of simplicity and developer experience.</p><p>That's why we decided to build WunderGraph the way we did. We want to create a &quot;pure&quot; backend framework that is as simple as NextJS, combined with a hosting platform that abstracts away the complexity of the underlying infrastructure.</p><h2>WunderGraph, an opinionated approach to backend development</h2><p>Similarly to NextJS, WunderGraph needs to be opinionated to create a great developer experience. Here's an overview of the most important decisions we made:</p><ul><li>The primary programming language is TypeScript</li><li>WunderGraph supports multiple API styles<ul><li>server-side GraphQL as an integration layer</li><li>JSON-RPC to expose internal APIs</li><li>REST to expose external APIs</li><li>Event-driven APIs for asynchronous workflows</li></ul></li><li>Configuration through code</li><li>Touching infrastructure is optional</li><li>Type-safety whenever possible</li></ul><h3>TypeScript</h3><p>TypeScript is a perfect balance between adoption, language features, and performance. It's not ideal in every way, but perfect for configuration as code and implementing middleware and APIs.</p><h3>Multi API style</h3><p>No one API style is perfect for every use case. For us, GraphQL is the perfect language to integrate and combine multiple APIs. However, we're not directly exposing GraphQL, but only using it as a server-side integration layer.</p><p>WunderGraph exposes internal APIs via JSON-RPC, while using REST when we'd like to expose APIs to third parties.</p><p>For internal workflows and complex use cases, we're also offering event-driven APIs with asynchronous event handlers.</p><p>Instead of forcing our users into a single API style, we're offering different options to choose from.</p><h3>Configuration through code</h3><p>Middleware, API, and event handlers are implemented in TypeScript, and we're using the same language for configuration as well. It's a single codebase for everything, not a single YAML or JSON file is needed.</p><h3>Touching infrastructure is optional</h3><p>It's possible to go from zero to production without touching any infrastructure, but we don't want to magically hide the underlying infrastructure from the user. You can always plug in your own infrastructure, like a Postgres database or Redis cache, but you don't have to.</p><h3>Type-safety whenever possible</h3><p>We want to avoid runtime errors as much as possible. The type system of TypeScript helps us a lot to achieve this goal. Sometimes, it might be favourable to have a bit more flexibility, but we're trying to avoid this as much as possible.</p><h2>Infraless backend development</h2><p>What are the most critical building blocks of a backend (in no particular order)?</p><ol><li>authentication &amp; authorization</li><li>database</li><li>key-value store</li><li>caching</li><li>file storage</li><li>cron jobs</li><li>long-running operations</li><li>job queues and async workflows</li><li>logging</li><li>monitoring</li><li>automated deployments</li></ol><p>We're not reinventing the wheel here. We're using existing open source projects to implement the interfaces and offer them as one unified set of lego blocks. Let's dive into the details.</p><h3>Authentication &amp; Authorization</h3><p>It's a problem that is already solved by WunderGraph. For authentication, we rely on OpenID Connect. For authorization, we offer rbac and abac as well as injecting claims into API Operations, allowing for a lot of flexibility.</p><h3>Database</h3><p>We're using Prisma as our database abstraction layer. Prisma not only allows us to offer simple migrations, but also to introspect the database schema and generate TypeScript types for it.</p><h3>Key-value store</h3><p>A typical key-value interface might look like this:</p><pre data-language="typescript">const client = new Client()
await client.set('foo', 'bar')
const value = await client.get('foo')
</pre><p>The problem with this interface is that it violates one of our principles: type-safety. A more type-safe approach might look like this:</p><pre data-language="typescript">// define key-value store with zod schema
const store = new Store('fooStore', {
  foo: z.string(),
})
await store.set('foo', 'bar')
const value = await store.get('foo')
console.log(value.foo) // bar
</pre><p>This store is now fully type-safe. By giving it a name, we're able to evolve the schema over time. As long as we're not introducing breaking changes, the schema can be evolved.</p><h3>Caching</h3><p>Caching is a very important part of a backend. We'd like to offer multiple caching strategies, HTTP-layer caching (already implemented), and application-layer caching in the form of a key-value store with TTLs and eviction policies. We'll probably use one of the existing well-known solutions to implement this.</p><h3>File storage</h3><p>File storage is already implemented in WunderGraph. WunderGraph is compatible with any S3-compatible storage.</p><h3>Cron jobs</h3><p>It's very common to have cron jobs in a backend that should run at a specific time or interval. If you do some research on how to run cron jobs with AWS Lambda, here's what you'll find:</p><ol><li>You need to create a CloudWatch Event Rule</li><li>You need to create a Lambda function</li><li>You need to create a CloudWatch Event Target</li><li>You need to create a CloudWatch Event Permission</li><li>You need to create a CloudWatch Event Rule Input</li><li>You need to create a CloudWatch Event Rule Input Target</li><li>You need to create a CloudWatch Event Rule Input Target Permission</li></ol><p>That's a lot of steps to run a simple cron job.</p><p>What if we could just write this:</p><pre data-language="typescript">const cron = new Cron('myCronJob', {
  schedule: '0 0 * * *',
  handler: async () =&gt; {
    // do something
  },
})
</pre><p>Git push this code to WunderGraph cloud and you're done. Even if we were using CDK, this would still be a lot of boilerplate code.</p><h3>Long-running operations</h3><p>There are many use cases where you'd like to implement workflows that run for a long time. Temporal (formerly Cadence) is a great source of inspiration for this, as well as AWS Step Functions.</p><p>Here's an example that made me fall in love with Temporal:</p><pre data-language="go">func RemindUserWorkflow(ctx workflow.Context, userID string, intervals []int) error {
   // Send reminder emails, e.g. after 1, 7, and 30 days
   for _, interval := range intervals {
      _ = workflow.Sleep(ctx, days(interval)) // Sleep for days!
      _ = workflow.ExecuteActivity(ctx, SendEmail, userID).Get(ctx, nil)
      // Activities have timeouts, and will be retried by default!
   }
}
</pre><p>The idea that you can write synchronous code which can sleep for days is amazing. However, this love quickly turned into confusion when digging into their documentation. I have to understand too many new concepts to get started with Temporal, like activities, workflows, signals, queries, etc.</p><p>The same applies to AWS Step Functions. They don't feel intuitive to me. Configuring state machines via JSON is not how I envision writing workflows.</p><p>I'd like to offer a similar experience to our users, but without this steep learning curve.</p><p>Here's an example of how a workflow to onboard users could be implemented:</p><pre data-language="typescript">const workflow = new Workflow&lt;{ userID: string }&gt;('onboarding workflow', {
  states: {
    welcome: {
      handler: async (ctx: Context) =&gt; {
        console.log('send welcome email')
        const ok = await ctx.internalClient.sendEmail('userID', 'welcome')
        if (ok) {
          ctx.next('sendReminder')
        }
      },
    },
    sendReminder: {
      waitBeforeExecution: '5 days',
      handler: async (ctx: Context) =&gt; {
        const loggedIn = await ctx.internalClient.queries.userLoggedIn('userID')
        if (!loggedIn) {
          console.log('send reminder email')
          ctx.internalClient.sendEmail('userID', 'reminder')
        }
        ctx.done()
      },
    },
  },
})

const id = await workflow.start({ userID: '1234' }) // id: 1
const state = await workflow.getState(id) // state: 'welcome'
// after one day
const state2 = await workflow.getState(id) // state: sendReminder (4 days remaining)
// after 5 days
const state3 = await workflow.getState(id) // state: 'sendReminder'
// after 5 days and 1 second
const state4 = await workflow.getState(id) // state: 'finished'
</pre><p>What's the beauty of this approach? Other solutions to this problem already exist. WunderGraph Workflows will be, like everything else, type-safe and easy to use. But most importantly, they are fully integrated into the rest of your application. Start workflows from an API Operation, trigger them from a cron job, or run them in the background. You can get the state of a workflow from anywhere in your application, like an API handler. Finally, you're able to run workflows locally and debug them just by running <code>wunderctl up</code>. Deploy your WunderGraph application to WunderGraph cloud and the state of your workflows will automatically be persisted.</p><p>Final note: Workflows will be Serverless, meaning that they will sleep when they're not running. When a workflow sleeps, it really does. Therefore, you don't have to pay for a workflow that's not running.</p><h3>Job queues and async workflows</h3><p>Another common use case is to run jobs asynchronously. For this to work, you usually need a job queue and a worker that processes the jobs. This is a very common pattern, but it's not very easy to implement. You have to configure a queue, a worker, and a way to communicate between them. As the queue, you can use AWS SQS, RabbitMQ, Nats, or similar solutions. Then you have to configure workers to process jobs, report state, handle errors, etc. Finally, you need to implement the logic to enqueue jobs and handle the responses.</p><p>But isn't this just a workflow with a different name? Yes, it is. Workflows will automatically be backed by a job queue. The communication is already handled by the workflow engine. All you have to do is to define a handler, possible states, and the transitions between them. Workflows don't have to have multiple states, they can also be just a single handler that runs asynchronously.</p><p>All the steps to implement a job queue and a worker are already handled by WunderGraph. We're trying to abstract away the complexity to the minimum.</p><h3>Insights: Logging, Monitoring, Metrics, Alerting and Tracing</h3><p>Another important aspect of developing APIs and services is to have insights into what's going on. This includes logging, monitoring, metrics, alerting, and tracing.</p><p>WunderGraph will offer a unified way to collect and analyze all of these insights. In addition to that, we'll offer you ways of integrating with your existing tools.</p><h3>Automated Deployments / CI-CD</h3><p>A critical part of achieving a great developer experience is to not have to worry about deployments. One of our users reported that they were able to build a POC with WunderGraph within one hour, but then it took them multiple days to figure out how to properly deploy it to AWS, including health checks, DNS configuration, autoscaling, and so on.</p><p>We believe that this should be abstracted away, just like Vercel does it. You should be able to push your code to a git repository and have it deployed automatically. No additional configuration should be required. Good defaults should be used, but you can always override them if you want to.</p><p>We've invested heavily to build the perfect CI-CD pipeline for WunderGraph. It's based on top of Firecracker and is able to build and deploy WunderGraph applications in less than a minute. We'll talk about this topic in depth in a future post.</p><h2>Summary</h2><p>In this post, we demonstrated how an opinionated approach can radically simplify the existing workflow of building software. You don't have to understand the entire AWS ecosystem to build rich backend applications. It's clear that we're making trade-offs here, but we believe that the benefits outweigh the downsides.</p><p>As I said earlier in the post, it's about &quot;Zeit&quot; (time) to simplify cloud native software development. Serverless was a great start, but I think that we should go one layer above, abstracting away infrastructure completely. Back to the old days of PHP, but with a modern twist.</p><p>We'd love to hear your thoughts on this topic. How do you think about abstracting away infrastructure as proposed in this post? Do you want to control every aspect of your infrastructure, or do you prefer to have a more opinionated approach?</p><p>Additionally, we'd love to invite you to the WunderGraph community. Please share your opinion on our <a href="https://wundergraph.com/discord">Discord server</a>, and join the early access program if you're interested in trying out WunderGraph Cloud as soon as it's available.</p><p>Are you ready for the next generation of <s>Serverless</s> Infraless API Development? Join the waitlist for WunderGraph Cloud Early Access and be the first to try it out.</p></article>

It's about time that we simplify cloud native software development. Serverless was a great start, but it's time that we abstract away infrastructure completely. We will demonstrate our opinionated approach that can radically simplify the existing workflow of building software

Dev without Ops - Why we are building Vercel for Backend, the Infraless Cloud

<article><p>We recently announced our public beta for WunderHub, the package manager for APIs. With WunderHub, we have developed an API repository on top of our open source integration framework WunderGraph, which saves developers 90% of time when building integrations.</p><p>Think of WunderHub like the GitHub for APIs: Developers can search for and find APIs that fit their needs. Then they can then integrate them into their application with a single command.</p><p>Need a weather API? Find one on WunderHub and add it to your application, as easy as “wunderctl add wundergraph/weather” and you are good to go. In this article, we want to share how having your API published on WunderHub does not only benefit users, but also offers new opportunities for API vendors.</p><p><strong>Tl;dr:</strong> Publishing your API on WunderHub will drastically reduce implementation time of your API and therefore boost your most important metric: time-to-value for your users.</p><h2>Why sharing API documentation is not enough anymore</h2><p>APIs have become the core components of every development project. But when it comes to sharing and implementing APIs, we are still in the stone age.</p><p>Even the largest API providers are making their APIs available to developers through a GitHub repository with OpenAPI specs. While this is completely fine in a scenario where you only use one or two APIs, it becomes unmanageable when you are building larger applications. With increasing numbers of API endpoints, versions and variants (REST, GraphQL, OpenAPI), the developer experience gets worse and worse because every API adds technical debt that developers have to manage.</p><p>This is a challenge you cannot solve, even if you wanted to. You could have the best API documentation on the planet, but since your API is going to be integrated with other services, there are dependencies that you just can’t control.</p><h2>Users favor APIs that help then generate value instantly</h2><p>But users don’t want to manage those complexities. They want value, and they want it now. That is why time-to-value is the most important metric for any product.</p><p>Let’s look at one of the biggest companies in the world for a second - Facebook. Their success comes from the fact that they have optimized everything for getting users to their “a-ha moment” as quickly as possible. For them, it was getting users to 7 friends in 10 days. For you, it is most likely a completely different metric. But in principle it is the same.</p><p>** Faster value creation for users increases revenue, reduces churn and boosts NPS. Sales will close deals faster, support has to deal with fewer requests and developers have more time to work on core product value.**</p><p>For API providers, that means that the time from a developer finding your product to them getting value from it should be as short as possible. Today however, this process is much longer than it should be. These are the steps they have to go through:</p><blockquote><p>Time-to-value for developers is 3+ weeks in this scenario.</p></blockquote><p>This is where WunderGraph and WunderHub come into play. We reduce this process to only the most fundamental steps. How we do this is by combining all data sources, APIs and services used for a project into a single GraphQL API and by automating 90% of all the manual and repetitive tasks when building integrations. Developers now only have to use a single API, instead of 10 or more. No more complexity at scale.</p><p>With WunderHub, adding a new API to this unified GraphQL API is like adding a Lego block to your Lego house: Developers can search for and find an API for the functionality needed on WunderHub and add it to their WunderGraph application with a single command. It is immediately compatible with all other services and therefore implementation time is reduced by factor 10.</p><blockquote><p>In this scenario, time to value is one day or even less.</p></blockquote><h2>WunderHub as a growth channel</h2><p>But WunderHub does not only make implementing your API faster for existing customers, it also works as a growth channel to generate new ones. By providing a central platform where developers can search for and integrate APIs with a single command, WunderHub offers a low barrier to entry for new customers. They are just one command away from using your product, so why shouldn’t they give it a try?</p><h2>Extended insights into product usage</h2><p>Another opportunity that this model enables is extended insights into how APIs are used and combined. Since WunderHub provides a centralized platform, reporting is no longer limited to a single API. Want to know which other products yours is integrated with most often? What are other APIs people have tried before committing to yours? Are there any large-scale trends of user behavior that you are not yet aware of? All these are questions that WunderHub can answer.</p><h2>How you can get started with WunderHub</h2><p>WunderHub is currently in public beta and you can start publishing your API today. We have <a href="https://docs.wundergraph.com/docs/wunderhub-reference/publish-api-to-wunderhub">documentation on how you can do that in less than 30 Minutes.</a> WunderHub supports all GraphQL APIs as well as REST APIs using OpenAPI/Swagger specification. Jens did a great video on how to get started, you can check it out here:</p><p>If you would like to talk to someone from the team, you are welcome to join our Discord server. We would be happy to <a href="https://wundergraph.com/discord">discuss your ideas on our Discord</a>.</p></article>

Publishing your API on WunderHub will drastically reduce implementation time of your API and therefore boost your most important metric: time-to-value for your users.

10x faster implementation time for your API with WunderHub

<article><p>Do you remember how we shared applications before Docker existed? Applications were not as portable as they are today. You had to install all the required packages, manually or automated, but it was nowhere near as easy as <code>docker run</code> or <code>docker build</code>.</p><blockquote><p>If you're impatient, you can check out the <a href="https://hub.wundergraph.com">WunderHub WebSite</a> straight away. However, we suggest you to read the announcement first to understand our motivation behind building WunderGraph and the Hub.</p></blockquote><h2>How portability and package managers changed the way we develop software</h2><p>Docker, or better yet OCI (Open Container Initiative), completely changed the way the bundle applications and distribute them. Today, you can pull an image from a Docker registry and run it on your local machine or in the cloud.</p><p>Similarly, could you imagine a world without package managers like npm, Composer, or Maven? There was a time when JavaScript libraries like jQuery had to be included directly into the HTML from a CDN. The way we develop software today heavily relies on package managers, bundlers, and build tools.</p><p>What both of these categories of tools have in common is that they fundamentally changed the way we develop software. They enabled new workflows and made it easier for developers to collaborate and share code.</p><p>Docker / OCI for example paved the way for kubernetes, standardizing the way how applications can be deployed in cloud native environments.</p><p>So what's the point of mentioning these two when we actually want to talk about APIs? Well, I believe that we're still in the stone age when it comes to sharing APIs.</p><p>While the API community developed tools like API Gateways and Developer Portals to secure and distribute APIs, they completely forgot to think about the developer experience of API developers and their consumers.</p><p>What happens when you visit a developer portal and decide, you'd like to use the API in your project? You download the SDK or use the Swagger / OpenAPI specification and start a manual integration process. There's no simple way to <code>npm install</code> the API and start using it.</p><p>The typical project doesn't just talk to a single database in isolation. You will probably have to integrate with multiple APIs from different teams or even third parties. Microservice architectures require a lot of integration work. Additionally, there are many powerful SaaS providers that offer APIs, e.g. for sending emails, managing user accounts, etc.</p><p>When it comes to integrating all these services, developers have to go through a lot of manual work. Wrapping SDKs, building backends for frontends, managing secrets and handling authentication are just a few of the problems to tackle. Most of the time, this manual integration work is not shared because it's proprietary closed source code that cannot be shared publicly. This means that API consumers do the same or similar work over and over again, wasting time and money.</p><blockquote><p>Our goal is to change this!</p></blockquote><p>We want to make API integration as simple as <code>npm install</code>. Our goal is to make APIs as portable as Docker containers, allowing API developers and their consumers to collaborate at a whole new level.</p><p>Manually integrating APIs is like importing jQuery from a CDN, let's get rid of that!</p><h2>The solution: How to make APIs easily portable</h2><p>Similarly to Docker, we need a common language to make APIs portable. Additionally, we need a runtime to run our API integrations on.</p><p>Once we have these two, we need a place to store our API integrations so that API developers can &quot;publish&quot; their APIs and consumers can &quot;pull&quot; them into their projects, similar to Docker or npm.</p><h3>GraphQL: The common language for API integrations</h3><p>For the language, we've decided to use GraphQL. By combining all APIs into a single GraphQL schema, we're able to &quot;query&quot; data from multiple APIs at once.</p><p>In that sense, we're creating a &quot;Virtual Graph&quot; that represents all API dependencies of a project. GraphQL was invented as a solution to fetch exactly the data needed by frontends.</p><blockquote><p>We believe that GraphQL will become the standard language for API integrations.</p></blockquote><p>GraphQL has a strong community and gets a lot of love from their users. Additionally, it comes with a powerful type system, making it very easy to generate e.g. TypeScript interfaces for your integrations.</p><h3>WunderGraph: The runtime for API integrations</h3><p>What we've done for the last year is to build the runtime for API integrations. WunderGraph makes it easy to combine APIs from different services into a single GraphQL schema. Our Runtime / Engine is capable of combining them into a common format, allowing you to execute GraphQL Operations against almost any service.</p><p>So far, we're supporting the following Backends:</p><ul><li>REST (OpenAPI / Swagger)</li><li>GraphQL</li><li>Apollo Federation</li><li>PostgreSQL</li><li>MySQL</li><li>SQLite</li><li>SQL Server</li></ul><p>You can &quot;introspect&quot; any of those and turn them into the &quot;portable&quot; WunderGraph format with a single command.</p><p>In addition to the above backends, we also support the following Frontends:</p><ul><li>REST(-ish) API</li><li>Postman Collections</li><li>Generated SDKs<ul><li>TypeScript</li><li>React</li><li>React Native</li></ul></li></ul><p>When we talk about &quot;frontends&quot; we're talking about how to consume the API integrations. WunderGraph doesn't just combine your APIs into a GraphQL Schema and calls it a day. We go one step further, generating complete ready-to-use SDKs for your APIs that not just let you call your APIs, but also handle authentication and authorization, caching, security and more.</p><h3>WunderHub: A place to store and share API integrations</h3><p>The last component of our solution is WunderHub. It's a place where you can store and share API integrations. Similarly to the Docker Hub or npm, you can publish your API descriptions and share them with the community.</p><p>You could share them publicly with everyone or limit access to just a group of people, e.g. only those of your own organization.</p><p>With the three components, the common language, the Runtime and the Hub, let's have a look at the flow of integrating APIs using WunderGraph and the Hub.</p><h2>How does it work?</h2><h3>Sharing an API using the WunderHub</h3><p>The first step is to introspect the API you want to share and translate it into the portable WunderGraph format. This can be done using the TypeScript SDK of WunderGraph. Here's an example:</p><pre data-language="typescript">// first, introspect an API
const countries = introspect.graphql({
  url: 'https://countries.trevorblades.com/',
})

// then, prepare it for publishing it to the Hub
configurePublishWunderGraphAPI({
  organization: 'wundergraph',
  apiName: 'countries',
  title: &quot;Trevor's Countries&quot;,
  markdownDescriptionFile: 'countries.md',
  public: true,
  keywords: ['countries', 'trevor', 'trevorblades'],
  apis: [countries],
})
</pre><p>The SDK lets you introspect one or more APIs which you can then combine and publish. Similarly to how npm works, you publish the API to an organization and can use various methods to describe it.</p><p>Once you're ready to publish, run the following command:</p><pre data-language="shell">$ wundergraph publish generated/wundergraph.countries.api.json
</pre><h3>Integrating an API published on the Hub</h3><p>Now let's talk about the flow of integrating APIs using WunderGraph.</p><p>First, let's init a new project.</p><pre data-language="shell"># Checkout the WunderHub template
npx create-wundergraph-app my-api --example publish-install-api

# Move the the project directory
cd my-api

# Install dependencies
npm install &amp;&amp; npm start

</pre><p>Then let's add two APIs to our workspace.</p><pre data-language="shell">wunderctl add wundergraph/countries wundergraph/spacex
</pre><p>The added API dependencies are automatically downloaded and installed. All API dependencies of a project are stored in the <code>wundergraph.manifest.json</code> file.</p><pre data-language="json">{
  &quot;dependencies&quot;: [&quot;wundergraph/spacex&quot;, &quot;wundergraph/countries&quot;]
}
</pre><p>Once we've added the APIs to our workspace, we can add them to our WunderGraph API using the WunderGraph SDK.</p><pre data-language="typescript">import {
  configureWunderGraphApplication,
  cors,
  templates,
} from '@wundergraph/sdk'
import wunderGraphHooks from './wundergraph.hooks'
import operations from './wundergraph.operations'
import { integrations } from './generated/wundergraph.integrations'

const spacex = integrations.wundergraph.spacex({
  apiNamespace: 'spacex',
})

const countries = integrations.wundergraph.countries({
  apiNamespace: 'countries',
})

configureWunderGraphApplication({
  apis: [spacex, countries],
})
</pre><p>As you can see, we're instantiating both APIs from the generated &quot;integrations&quot; file. There's one little detail that might spark your attention, the <code>apiNamespace</code> parameter.</p><p>WunderGraph combines all your APIs into a single GraphQL Schema. If you combine APIs from different teams or vendors into the same GraphQL Schema, you're very likely to run into naming collisions and your Schema will be broken. By putting different APIs into their own namespace, we're able to avoid these problems without manual configuration.</p><p>As a final step, we have to define an operation to interact with our newly created API.</p><pre data-language="graphql">query DragonsAndContries {
  dragons: spacex_dragons {
    name
    active
  }
  countries: countries_countries {
    code
    name
    capital
  }
}
</pre><p>This Query retrieves data from both the SpaceX and Countries APIs. You can also see how the root level fields of both APIs are prefixed with the API namespace.</p><p>You're now ready to start your WunderGraph application and start using it.</p><pre data-language="shell"># cd into the .wundergraph directory and run:
$ wunderctl up --debug
</pre><p>And finally, let's query it!</p><pre data-language="shell">$ curl http://localhost:9991/operations/DragonsAndContries
</pre><p>In this example, we're simply using curl to query the generated REST(-ish) API, but you could also go more advanced and use a generated TypeScript client, the generated Postman Collection, etc...</p><h3>Summary</h3><p>We've introspected a GraphQL API using the SDK, prepared it for publishing and then pushed it to the hub.</p><p>Then, as an API consumer, we've added two APIs to our project and instantiated them with an api namespace. Finally, we've defined an Operation and interacted with our newly created API integration using curl.</p><p>This might look like a simple example but I hope it's clear how much time we're able to save.</p><h2>How does the world look like without using this flow?</h2><p>As we've said earlier, we think that API integrations are still in the stone age, so let's contrast the WunderGraph flow with how developers would save the same problem without WunderGraph.</p><ul><li>First, you have to decide on a technology, language and framework to build your REST API</li><li>Then, add a new endpoint to your API</li><li>Use a tool like graphql-code-generator to generate a typesafe API client for both APIs</li><li>Use the generated client to query both APIs and implement the REST Endpoint</li><li>Define a JSON Schema for the REST Endpoint</li><li>Add an authentication and authorization layer to your REST Endpoint (this is batteries included in WunderGraph)</li><li>Add a caching middleware (this is batteries included in WunderGraph)</li><li>Use curl to query the REST Endpoint</li></ul><p>We could easily make the list a lot longer because WunderGraph does way more than just integrating APIs. Have a <a href="/docs/overview/features/overview">look at our Features</a>, our suite of tools helps you solve all problems around APIs, from authentication to authorization, role based access control, mocking, JSON Schema validation, automatic ETags, S3 file uploads and many more.</p><p>Additionally, imagine what happens if you have to add another API or one of the APIs needs to be updated. With WunderGraph and the Hub, it's a matter of minutes and mostly automatic. You shouldn't really waste your time for such a boring task.</p><h2>Announcing the WunderHub closed Beta</h2><p>WunderGraph, the Runtime / Engine is very stable and ready for production. Together with our community of WunderGraph fans, we've been able to mature it over the last few months.</p><p>It's now time to move forward towards the final step before we want to release our framework to the public, Open Source and with no restrictions.</p><p>To make this final step easier, we need feedback from you, the community!</p><p>We're asking you to join our closed beta and help us to optimize the Developer Experience of both the WunderGraph Framework and the Hub.</p><p>If you're interested, please have a look at <a href="https://hub.wundergraph.com">https://hub.wundergraph.com</a> and sign up for the private beta. Additionally, you can also <a href="https://wundergraph.com/discord">join our Discord</a> and ask to join the Beta there.</p><p>We'd love to hear from you if you think the Hub and our Framework could help you to improve your experience of working with APIs.</p><h2>The Future</h2><p>Our plan is to release our Open Source Framework in January 2022. Our long term goal is to be able to connect more backends and integrate with more frontend technologies.</p><p>On the backend side, we'd like to add support for SOAP, OData, gRPC and MongoDB. On the frontend side, we're looking at supporting Vue, Svelte, Angular, iOS, Android, Flutter, Java, Go, Python, Ruby, PHP, Typescript, Swift, Kotlin, C#.</p><p>Our vision is to become a meta-framework to solve all problems around APIs while being both backend and frontend agnostic. You should be able to use any backend or frontend technology, we're handling the heavy lifting of API integrations, security and more.</p></article>

Today, we announce WunderHub, a tool to share APIs just like npm packages. WunderHub enables API developers and consumers to collaborate at a whole new level.

Documentation

Examples

Github

Community

LATEST FROM THE BLOG

Isomorphic TypeScript APIs: End-to-end type-safety between client & server

Building A Serverless Live Chat App with Next.js, Fauna, and WunderGraph for GraphQL Live Queries

Blog

Company

Product

Resources

Docs