Future #.
Our plan is to release the open source framework in January 2022. Our long term goal is to be able to connect more backends and integrate with more frontend technologies.
On the backend side, we would like to add support for SOAP, OData, gRPC, and MongoDB. On the front-end side, we are considering support for Vue, Svelte, Angular, iOS, Android, Flutter, Java, Go, Python, Ruby, PHP, Typescript, Swift, Kotlin, and C#.
Published Date: 2022-01-02
Jens Neuse, CEO and Founder @ WunderGraph
Remember how applications were shared before Docker existed? Applications were not as portable as they are today. You had to install all the necessary packages manually or automatically, but it wasn't as easy as docker run or docker build.
If you are impatient, check the WunderHubWeb site immediately. However, we recommend reading the announcement first to understand the motivation behind the WunderGraph and the hub build.
How portability and package managers have changed the way software development is done #.
Docker, and even OCI (Open Container Initiative), has completely changed bundled applications and how they are distributed. Now you can pull images from the Docker registry and run them on your local machine or in the cloud.
Similarly, can you imagine a world without package managers like npm, Composer, Maven, etc. There was a time when JavaScript libraries like jQuery had to be included directly in HTML from a CDN. Today's software development methods rely heavily on package managers, bundlers, and build tools.
What both of these categories of tools have in common is that they have fundamentally changed the way software is developed. New workflows are now possible, making it easier for developers to collaborate and share code.
For example, Docker / OCI paved the way for kubernetes and standardized the way applications are deployed in cloud-native environments.
So what is the point of mentioning these two when we actually want to talk about APIs? Well, I think we are still in the stone age when it comes to sharing APIs.
The API community has developed tools like API gateways and developer portals to protect and distribute APIs, but completely forgot to think about the developer experience for API developers and their consumers.
What happens when you access the developer portal and decide to use the API in your project, download the SDK or use the Swagger / OpenAPI specification to start the manual integration process. npm installA simple way to start using theAPI There is not.
A typical project will not just communicate with a single database on its own. It will likely need to integrate with multiple APIs from different teams and third parties. Microservices architecture requires a lot of integration work. In addition, there are many powerful SaaS providers that offer APIs. For example, sending email, managing user accounts, etc.
When it comes to integrating all these services, developers need to do a lot of manual work: wrapping the SDK, building the front end back end, managing secrets, and handling authentication are just a few of the issues that need to be addressed. In most cases, this manual integration work is not shared because it is proprietary closed source code that cannot be shared publicly. This means that API consumers waste time and money doing the same or similar work over and over again.
Our goal is to change this!
We want to make API integration as easy as npm install. our goal is to make APIs as portable as Docker containers, allowing API developers and their consumers to collaborate on a whole new level.
Manually integrating an API is like importing jQuery from a CDN. Let's get rid of that!
Solution: make the API easily portable #.
Similar to Docker, we need a common language to make APIs portable. Additionally, you need a runtime to perform API integration.
Once we have these two, we need a place to store the API integration so that API developers can "publish" the API and consumers can "pull" the API into their projects, similar to Docker or npm.
GraphQL: Common language # for API integration
For the language, we decided to use GraphQL. By combining all APIs into one GraphQL schema, we can "query" data from multiple APIs at once.
In this sense, we are creating a "virtual graph" representing all API dependencies of the project; GraphQL was invented as a solution to fetch the exact data needed for the front end.
We believe that GraphQL will become the standard language for API integration.
GraphQL has a strong community and gets a lot of love from its users. In addition, it comes with a powerful type system that makes it very easy to generate, for example, TypeScript interfaces for integration.
WunderGraph: Runtime # of API Integration
What we have done in the last year is to build a runtime for API integration: with WunderGraph, you can easily combine APIs from different services into a single GraphQL schema. Our runtime/engine can combine them into a common format and perform GraphQL operations on almost any service.
So far, we support the following backends
REST (OpenAPI / Swagger)
GraphQL
Apollo Federation
PostgreSQL
MySQL
SQLite
SQL Server
Any of these can be "introspected" and converted to the "portable" WunderGraph format with a single command.
In addition to the above backends, the following frontends are supported
REST (-ish) API
Postman collection
Generated SDK
TypeScript
React
React Native
When we talk about "front ends," we talk about how to take advantage of API integration, and WunderGraph does more than just bind an API to a GraphQL schema and call it a day. It goes a step further and generates a complete, ready-to-use SDK for your API that not only calls the API, but also handles authentication and authorization, caching, security, and more.
WunderHub: a place to store and share API integrations #.
The final component of the solution is the WunderHub. This is where you can store and share your API integrations, similar to Docker Hub or npm, where you can publish API descriptions and share them with the community.
You can share them publicly with everyone, or restrict access to a group, such as only those in your organization.
Let's take a look at the flow of integrating an API with WunderGraph and the Hub, using the three components of a common language, the Runtime and the Hub.
How does it work? #.
# of APIs to share using WunderHub
The first step is to introspect the API to be shared and convert it to the portable WunderGraph format. This can be done using WunderGraph's TypeScriptSDK. Here is an example
// First, introspect the API
const
country
= (country)
introspect
const = country
graphql
(
{
url
.
"https://countries.trevorblades.com/", }
}
)
;
// Next, prepare to publish to the hub
configurePublishWunderGraphAPI
(
{
Organization
:: "wundergraph
wundergraph", "wundergraph", "wundergraph", and
apiName
apiName: "wundergraph", apiName
"country", apiName: "wundergraph", apiName: "wundergraph
title
, apiName: "country", title.
"Trevor'sCountries", title
markdownDescriptionFile
, title.
"countries.md" , markdownDescriptionFile
Public
True , "countries.md" , public
true , public : "countries" , public : "md" , public : "md
Keyword : "countries
keywords.
[ "country", "trevor", "trevorblades" ], "apis
apis
keywords .
[ "country
country
[ "country", "trevor", "trevorblades
]
, [
}
)
;
Using the SDK, you can introspect one or more APIs and publish them in combination; similar to how npm works, you can publish your APIs to your organization and write them using a variety of methods.
When you are ready to publish, run the following command
$ wundergraphpublishgenerated / wundergraph.countries.api.json
Integration # of APIs published in the hub
Now let's go through the flow of integrating APIs using WunderGraph.
First, start a new project.
$ wundergraph init
$
cd
.wundergraph
$
Thread.
Next, let's add the two APIs to our workspace.
The $wunderctl integration is
Add $wundergraph/countrys wundergraph/spacex
The added API dependencies will be automatically downloaded and installed. All API dependencies for the project are stored in the wundergraph.manifest.json file.
{{{
Dependencies.
： .
[
"wundergraph / spacex"
, [ "wundergraph/countries
"wundergraph/countries"
]
}
Once the APIs have been added to the workspace, they can be added to the WunderGraphAPI using the WunderGraphSDK.
Import.
{
Application
, the
configureWunderGraphApplication
, and
cors
, and
Template
}
from "@ wundergraph / sdk" ;
". Import wunderGraphHooks from "/wundergraph.hooks" ;
". /wundergraph.operations"; import operations from ";
import
{ integrations } from ". /generated/wundergraph.integrations" ;
constspacex
= integrations. _
wundergraph . SpaceX ({
apiNamespace
:.
"spacex" , }
}
)
;
const
country
= { const
Integration
wundergraph
wundergraph
country = integration
country
(
{ {
apiNamespace
apiNamespace:.
"country" , }
}
)
;
const
myApplication
= myApplication
new Application ({
Name
Name: {name
application", "apis
apis
Name: "apis", "apis
[ [
spaceX
, [ space
country
, [ [ [ SpaceX, [ [ [ SpaceX, [ [ [ [ SpaceX
]
, ]
}
)
;
As you can see, both APIs are instantiated from the generated "integration" file. There is one small detail that might call your attention, the apiNamespace parameter.
WunderGraph combines all APIs into a single GraphQL schema. Combining APIs from different teams or vendors into the same GraphQL schema greatly increases the likelihood of name collisions and schema corruption. Placing the various APIs in their own namespace avoids these problems without manual configuration.
As a final step, we need to define operations to interact with the newly created APIs.
Query
DragonsAndContries.
{
Dragons
:: Dragons
spacex_dragons
{
name
active
}
Country
:: countries_countries
countries_countries
{
Code
Name
capital
}
}
This query retrieves data from both SpaceX and CountriesAPI. We can also see that the root-level fields of both APIs are prefixed with the API namespace.
You are now ready to launch the WunderGraph application and begin using it.
cd to the #.wundergraph directory and run the following.
$ wunderctl up --debug
And finally, let's query it!
$
curl
http: // localhost:9991 / api / main / operations / DragonsAndContries
In this example, we are querying the generated REST(-ish) API using curl, but you can go even more advanced and use the generated TypeScript client, the generated Postman collection, etc...
Summary #.
We introspected the GraphQLAPI using the SDK, prepared it for publication, and pushed it to the hub.
Next, we added two APIs to the project as API consumers and instantiated them in the api namespace. Finally, we defined the operations and interacted with the newly created API integration using curl.
This may seem like a simple example, but I hope it is clear how much time it saves.
What would the world look like without this flow? #.
As I mentioned before, I believe API integration is still in the stone age, so let's compare the WunderGraph flow to how developers can save the same problem without WunderGraph.
First, we need to determine the technology, language and framework to build the REST API
Next, add a new endpoint to the API
Generate a type-safe API client for both APIs using a tool such as graphql-code-generator
Use the generated client to query both APIs and implement the REST endpoints
Define JSON schema for REST endpoints
Add an authentication and authorization layer to the REST endpoint (this is the battery included in WunderGraph)
Add caching middleware (this is the battery included in WunderGraph)
Query REST endpoints using curl
WunderGraph does more than just integrate APIs, so you can easily lengthen your list. See the features. The tool suite helps you solve all API issues from authentication to authorization, role-based access control, mocking, JSON schema validation, automatic ETag, S3 file upload, and more.
Plus, imagine what happens when you need to add another API or update one of your APIs: with WunderGraph and the Hub, it's almost automated in minutes. You really should not waste your time for such a tedious job.
WunderHub Closed Beta Announcement #.
WunderGraph, the runtime/engine is very stable and production ready, and with the help of the WunderGraph fan community we have been able to mature it over the past few months.
It is time to move forward with the final steps before we release the framework to the public without restrictions.
To make this final step easier, we need feedback from you, the community.
Please help us optimize the developer experience for both the WunderGraph framework and the hub by participating in the closed beta.
If you are interested, please visit https: //hub.wundergraph.com and sign up for the private beta. Additionally, you can join our Discord and request to join the beta there.
If you think the hub and framework will help improve the API operating experience, we'd love to hear from you.
Future #.
Our plan is to release the open source framework in January 2022. Our long term goal is to be able to connect more backend and integrate with more frontend technologies.
On the backend side, we would like to add support for SOAP, OData, gRPC, and MongoDB. On the front-end side, we are considering support for Vue, Svelte, Angular, iOS, Android, Flutter, Java, Go, Python, Ruby, PHP, Typescript, Swift, Kotlin, and C#.
Our vision is to be a meta-framework to solve all problems related to APIs, both back-end and front-end agnostic. It should be able to use either back-end or front-end technologies, handling the heavy lifting of API integration, security, etc.
What to read next.
This is a curated list of articles you might find interesting.
WunderHub presentation talks about how WunderHub is changing the way we share and collaborate on APIs. sharing APIs like the npm package.
How automating API integration can help your business is dedicated to executives who want to learn more about the business benefits of automating API integration.
Another interesting topic is combining APIs using only a single GraphQL operation, without schema stitching or federation.
Those interested in the most common GraphQL security vulnerabilities are encouraged to read about them and how WunderGraph can help you avoid them.
A classic post, but still relevant, is that GraphQL is not intended to be published on the Internet. It is a controversial topic and many people misunderstand it. But consider this: why is HTTP not mentioned once in the GraphQL specification?
One very common problem when using GraphQL is the double-declaration problem, the problem of declaring a type multiple times. This post explains how it is even more complicated than double declarations and how it can be solved.
Fusing GraphQLREST and HTTP/2 is a very long post, perhaps too long for a blog post. But if you are interested in digging deeper into the motivation behind the creation of WunderGraph, this is the post for you.
About the Author.
Jens Neuse
Jens Neuse, CEO and Founder @ WunderGraph
Jens has experience building native apps for iOS and Android, hybrid apps using Xamarin, React Native, and Flutter, and back-end development using PHP, Java, and Go. He has led increasingly large engineering teams in roles ranging from development to architecture.
Throughout his career, he has found that working with APIs is very complex and repetitive and requires a lot more standardization and automation. To that end, he started WunderGraph to facilitate the use of APIs and collaboration via APIs.
He believes that the businesses of the future will be built on a collaborative system connected via APIs. To achieve this goal, it is important to make it easy to use, explore, share, and collaborate with APIs.
Follow and connect with Jens, exchange ideas and join his thought feed.
Comment Comment
Previous
Joining data across APIs: GraphQL, REST, PostgreSQL, MySQL, etc.
Next
GraphQL Namespaces: Conflict-Free Merging of Any Number of APIs
Product
Features
Example code for developers
wunderctl
WunderHub
resources
Documentation
user feedback
Discord
GitHub
Book a Demo
YouTube
About
Blog
GitHub
Legal Notices
Imprint
Terms of Use
Privacy Policy
Site Map
Getting Started
Quick Start
Complete Getting Started Guide
NextJSTypeScriptGraphQL Real-Time Examples
Polyglot Persistence with PostgreSQL and MySQL Examples
Video
WunderGraph in under 300 seconds
WunderGraph Intro
Uploading Files Using S3
WunderGraph intro using NextJS and PostgreSQL
Creating a Postman collection from the WunderGraphAPI
Feed
RSS
Atoms
JSON
Compare
VS Hasra
Subscribe to our newsletter!
Stay informed when great things happen! Get the latest news about APIs, GraphQL, and more directly to your mailbox.
© 2022Wund
0 件のコメント:
コメントを投稿