{"id":15192454,"url":"https://github.com/jensneuse/graphql-gateway","last_synced_at":"2025-10-02T08:30:45.497Z","repository":{"id":55379580,"uuid":"218750233","full_name":"jensneuse/graphql-gateway","owner":"jensneuse","description":"Turn any* DataSource into a GraphQL API with no code","archived":true,"fork":false,"pushed_at":"2021-04-29T14:33:58.000Z","size":693,"stargazers_count":51,"open_issues_count":0,"forks_count":2,"subscribers_count":8,"default_branch":"master","last_synced_at":"2024-11-15T12:52:36.158Z","etag":null,"topics":["graphql","graphql-api","graphql-apis","graphql-gateway","graphql-server"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jensneuse.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2019-10-31T11:26:49.000Z","updated_at":"2023-06-24T19:11:16.000Z","dependencies_parsed_at":"2022-08-14T23:00:42.729Z","dependency_job_id":null,"html_url":"https://github.com/jensneuse/graphql-gateway","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jensneuse%2Fgraphql-gateway","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jensneuse%2Fgraphql-gateway/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jensneuse%2Fgraphql-gateway/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jensneuse%2Fgraphql-gateway/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jensneuse","download_url":"https://codeload.github.com/jensneuse/graphql-gateway/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":234957752,"owners_count":18913343,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["graphql","graphql-api","graphql-apis","graphql-gateway","graphql-server"],"created_at":"2024-09-27T21:40:16.662Z","updated_at":"2025-10-02T08:30:40.158Z","avatar_url":"https://github.com/jensneuse.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"This codebase is **deprecated**!\nPlease use https://github.com/jensneuse/graphql-go-tools instead.\n\n# GraphQL Gateway\n\nGraphQL Gateway turns an annotated schema into an executable GraphQL Server.\nSimply describe your schema and use directives to describe how the execution engine should resolve a field.\nNo code needs to be written, no code generation, just configuration and the execution engine does its thing.\n\nCurrently DataSources can be Static, GraphQL or JSON HTTP APIs.\nYou can nest GraphQL data sources into REST data sources into GraphQL data sources into...\nHave a look at the schema.graphql file to fully understand the concept.\n\nThis is experimental, don't use in production! But please, try it out!\n\n# Run\n\nRun the gateway using docker.\n\n```shell script\ndocker run -p 0.0.0.0:9111:9111 jensneuse/graphql-gateway serve\n```\n\n# Docs\n\nhttps://jens-neuse.gitbook.io/graphql-gateway/\n\n# Develop\n\n1. Install go 1.15 (golang.org)\n2. git clone https://github.com/jensneuse/graphql-gateway.git\n3. cd graphql-gateway\n4. run:\n\n```shell script\ngo run main.go serve\n```\n\nUse GraphQL Playground to explore your API.\n\nUpdate the schema and make use of the directives.\nTake inspiration from the schema.graphql file on how to use the directives.\nIf something doesn't work for you please supply a schema file so I can reconstruct the problem.\n\n# Motivation\n\nWriting resolvers on top of existing data sources is repetitive.\nThe logic can be encapsulated into directives.\nIf a directive doesn't give enough flexibility you're free to open an issue and/or PR.\n\nBefore wrapping existing data sources think about the costs of writing and maintaining the resolver code.\nImplementing, extending and maintaining a bunch of directives scales a lot better than writing individual resolvers.\nThere's a lot of tooling for writing efficient REST services. Also it's very easy to apply caching (e.g. using Varnish) to a REST API.\n\nWith the help of this gateway you'll get the best of both worlds, easy to reason about backend services and the benefits of GraphQL at the front end layer:\nWrite simple CRUD based REST APIs, apply server side caching and turn them into a GraphQL API with very little effort.\n\n# Architecture\n\nQuery -\u003e Lexing -\u003e Parsing -\u003e Normalization -\u003e Validation -\u003e Create Query Execution Plan -\u003e Execute Query Plan -\u003e Return Result\n\nCaching of execution plans will be possible to increase performance.\nThis will enable skipping validation and query planning for recurring operations.\nAfter normalization the input can be hashed and the hash will be used to fill a query plan map / retrieve a cached query plan.\n\n# *any DataSource\n\n*any DataSource can be supported implementing the necessary interfaces.\nCurrently supported:\n- GraphQL (multiple GraphQL services can be combined)\n- static (static embedded data)\n- HTTP JSON\n- HTTP JSON Streaming (uses polling to create a stream)\n- MQTT\n- Nats\n- Webassembly (resolve a Request using WASI compliant modules)\n\n# Contribute\n\nPlease try this tool for your use case and submit issues in case it didn't work for you.\nIt's far from being production ready so I'm relying on your input to find missing features \u0026 bugs.\n\n# Goals\n\n1. Based on you input I want to evolve the engine to support as many use cases as possible.\n2. When it feels \"production ready\" I'll focus on increasing performance because I took a few shortcuts to release this PoC faster (e.g. no parallel fetching, creation of unnecessary garbage collection)\n\n# Comparison\n\n### nautilus gateway\nhttps://github.com/nautilus/gateway\n\nNautilus is based around the assumption that all your services are GraphQL Services. It uses the Node interface ([Relay Gloabl Object Identification](https://facebook.github.io/relay/graphql/objectidentification.htm)) to automatically federate between multiple services. This approach is quite similar to the approach Apollo Federation took. So all services have to comply to the Relay Global Object spec and you're ready to go. Nautilus gateway will analyze your services via introspection at startup time and generate the final gateway schema.\n\nIn contrast this library goes a complete different approach. The basic assumption is that your public gateway schema should not be an artifact. The gateway schema is the contract between gateway and clients. The gateway doesn't make any assumptions on your services other than complying to some protocol and some spec. It's a lot more manual work at the beginning but this gives a lot of advantages. Because the gateway is the single source of truth regarding the schema you cannot easily break the contract. With federation an upstream service can directly break the contract. Additionally you're not limited to GraphQL upstreams. While GraphQL upstreams are supported it's only a matter of implementing another DataSource interface to support more upstream protocols, e.g. SOAP, MQTT, KAFKA, Redis etc.. On top of that, because the gateway schema is the single source of truth you'll get two additional benefits. First, you can swap DataSources for a given schema without changing the contract. E.g. you could replace a REST User-Service with a GraphQL User-Service without changing the contract between client and gateway. This could help to easily transition from legacy to more modern architectures. Second, because the gateway owns the schema you can apply features like rate limiting, authorization etc. at the gateway level.\n\nTo conclude, if you have only GraphQL services complying to the Relay Global Object spec and there are no special requirements like rate limiting or authZ you're best off using nautilus as it's a lot easier to get started.\n\nIf you have a heterogenous mesh of services and more specific requirements that would require customizing the schema you'd want to put in the extra effort to configure it all manually in exchange for the benefits described above.\n\nAs a sidenote, nautilus relies on the amazing gqlgen library as well as gqlparser from vektah, both amazing tools which are quire mature I think. In comparison I've implemented the GraphQL spec myself ([graphql-go-tools](https://github.com/jensneuse/graphql-go-tools)) for this specific use case. I've paid extra attention to implement features like parsing/lexing/validation/ast-walking in a zero garbage collection fashion which ultimately leads to better performance and more consistent latencies than every available implementation. I won't add benchmarks here because I'm biased but you're invited to prove me wrong.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjensneuse%2Fgraphql-gateway","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjensneuse%2Fgraphql-gateway","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjensneuse%2Fgraphql-gateway/lists"}