Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Connecting the Dots: Kong for GraphQL Endpoints
Ähnlich wie Connecting the Dots: Kong for GraphQL Endpoints (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Connecting the Dots: Kong for GraphQL Endpoints
- 1. Connecting the Dots Kong for GraphQL Endpoints Julien Bataillé Software Engineer / Rakuten, Inc.
- 3. How to manage GraphQL APIs with Kong?
- 4. Agenda • Quick introduction to GraphQL • Differences between REST and GraphQL • API Management for GraphQL • Kong Plugins (demo)
- 5. • Developed by Facebook in 2012 / publicly released in 2015 / GraphQL Foundation in 2018 • Server and Client implementations are available for major languages (JS, Java, Python, C#...) • Supports reading (query), writing (mutation) and subscribing to data changes (subscriptions) • Solves the Over-Fetching and Under-Fetching problems (Credits: https://graphql.org/)
- 6. A familiar use case: Kong Admin
- 7. Data Fetching with REST HTTP GET /services { "next": null, "data": [ { "host": "10.0.2.2", "created_at": 1560781137, "connect_timeout": 60000, "id": "3692da97-e066-46e6-9739-3da47cfe4abd", "protocol": "http", "name": "starwars-server", "read_timeout": 60000, "port": 8080, "path": "/graphql", "updated_at": 1561016983, "retries": 5, "write_timeout": 60000, "tags": null }, { "host": "mockbin.org", "created_at": 1560797940, "connect_timeout": 60000, "id": "81c4c6b5-746a-4421-ad0d-cddc0aa3ed87", "protocol": "http", "name": "mockbin", "read_timeout": 60000, "port": 80, "path": "/request", "updated_at": 1561017861, "retries": 5, "write_timeout": 60000, "tags": null } ] } HTTP GET /services/{service-id}/plugins x2 { "next": null, "data": [ { "created_at": 1560860735, "config": { "block_introspection_queries": false }, "id": "e0fcaa8b-167f-4f62-bf22-43dae04e91bf", "service": { "id": "3692da97-e066-46e6-9739-3da47cfe4abd" }, "name": "graphql-operation-whitelist", "protocols": [ "http", "https" ], "enabled": true, "run_on": "first", "consumer": null, "route": null, "tags": null } ] }
- 8. Data Fetching with REST vs GraphQL query { services { name host created_at plugins { name } } } HTTP POST /kong-graphql-admin HTTP GET /services { "next": null, "data": [ { "host": "10.0.2.2", "created_at": 1560781137, "connect_timeout": 60000, "id": "3692da97-e066-46e6-9739-3da47cfe4abd", "protocol": "http", "name": "starwars-server", "read_timeout": 60000, "port": 8080, "path": "/graphql", "updated_at": 1561016983, "retries": 5, "write_timeout": 60000, "tags": null }, { "host": "mockbin.org", "created_at": 1560797940, "connect_timeout": 60000, "id": "81c4c6b5-746a-4421-ad0d-cddc0aa3ed87", "protocol": "http", "name": "mockbin", "read_timeout": 60000, "port": 80, "path": "/request", "updated_at": 1561017861, "retries": 5, "write_timeout": 60000, "tags": null } ] } HTTP GET /services/{service-id}/plugins x2 { "next": null, "data": [ { "created_at": 1560860735, "config": { "block_introspection_queries": false }, "id": "e0fcaa8b-167f-4f62-bf22-43dae04e91bf", "service": { "id": "3692da97-e066-46e6-9739-3da47cfe4abd" }, "name": "graphql-operation-whitelist", "protocols": [ "http", "https" ], "enabled": true, "run_on": "first", "consumer": null, "route": null, "tags": null } ] }
- 9. Data Fetching with REST vs GraphQL query { services { name host created_at plugins { name } } } HTTP POST /kong-graphql-admin { "data": { "services": [ { "name": "starwars-server", "host": "10.0.2.2", "plugins": [ { "name": "graphql-operation-whitelist" } ], "created_at": 1560781137 }, { "name": "mockbin", "host": "mockbin.org", "plugins": [ { "name": "basic-auth" } ], "created_at": 1560797940 } ] HTTP GET /services { "next": null, "data": [ { "host": "10.0.2.2", "created_at": 1560781137, "connect_timeout": 60000, "id": "3692da97-e066-46e6-9739-3da47cfe4abd", "protocol": "http", "name": "starwars-server", "read_timeout": 60000, "port": 8080, "path": "/graphql", "updated_at": 1561016983, "retries": 5, "write_timeout": 60000, "tags": null }, { "host": "mockbin.org", "created_at": 1560797940, "connect_timeout": 60000, "id": "81c4c6b5-746a-4421-ad0d-cddc0aa3ed87", "protocol": "http", "name": "mockbin", "read_timeout": 60000, "port": 80, "path": "/request", "updated_at": 1561017861, "retries": 5, "write_timeout": 60000, "tags": null } ] } HTTP GET /services/{service-id}/plugins x2 { "next": null, "data": [ { "created_at": 1560860735, "config": { "block_introspection_queries": false }, "id": "e0fcaa8b-167f-4f62-bf22-43dae04e91bf", "service": { "id": "3692da97-e066-46e6-9739-3da47cfe4abd" }, "name": "graphql-operation-whitelist", "protocols": [ "http", "https" ], "enabled": true, "run_on": "first", "consumer": null, "route": null, "tags": null } ] }
- 10. API Management with REST vs GraphQL • API has many endpoints • Resource selection is defined in route • HTTP verbs define the operation (GET, POST, DELETE...) REST • API has a single endpoint • Resource selection is defined in body • HTTP POST for every operations (query or mutation defined in request body) GraphQL To manage GraphQL Endpoints, we have to look into the query and extract some characteristics to implement policies.
- 11. Query characteristics examples Nesting Measure the nesting level of a query. Query Cost Analysis Count the amount of resources requested by a query. Query whitelisting Verify the query belongs to a group of authorized queries.
- 12. Query characteristics examples Nesting Measure the nesting level of a query. Query Cost Analysis Count the amount of resources requested by a query. Query whitelisting Verify the query belongs to a group of authorized queries. 50 = 50 repositories + 50 x 10 = 500 repository issues = 550 total nodes
- 13. Query characteristics examples Nesting Measure the nesting level of a query. Query Cost Analysis Count the amount of resources requested by a query. Query whitelisting Verify the query belongs to a group of authorized queries.
- 14. Existing solutions are language-specific libraries API - 1 (JS) Nesting Limit Node Count Limit Query Whitelisting API - 2 (Java) Nesting Limit Node Count Limit API - 3 (Python) API - 1 (JS) API - 2 (Java) API - 3 (Python) Kong Plugins: Nesting Limit, Node Count Limit, Query Whitelisting... Non-intrusive: no code or configuration change on your GraphQL server. Language-agnostic: same features and performance for all GraphQL implementations .
- 15. Two proof-of-concept Kong plugins developed at Rakuten 1. Depth Limit Limit the complexity of GraphQL queries based on their depth. https://github.com/rakutentech/kong-plugin-graphql-depth-limit 2. Operation Whitelist Whitelist operations that your consumers can send to your GraphQL server. https://github.com/rakutentech/kong-plugin-graphql-operation-whitelist
- 16. Operation Whitelist Plugin Requirements Queries and Mutations blocked if not whitelisted Equivalent operations represented as a single entry PDK Features Usage Storing/Caching Custom Entities Admin API Extension to manage the Whitelist Client UpstreamKong Query Parsing Signature Generation Signature Hashing Whitelist Check
- 17. DEMO
- 18. Credits and references • Securing Your GraphQL API from Malicious Queries (Apollo) https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b • GraphQL API Management (IBM) https://www.ibm.com/blogs/research/2019/02/graphql-api-management/ • GraphQL Lua (@bjornbytes) https://github.com/bjornbytes/graphql-lua
- 19. Thank you
- 20. Conclusion and Next Steps • Kong extensibility is a key factor, look into plugin and Admin API • GraphQL is still relatively new, but it’s popular and we need to address the security aspect • Load and Performance testing • Hardening the code • Merging all the plugins in a single one • Implement a Query Cost Analysis Plugin
Hinweis der Redaktion
- Good afternoon everyone, I'm Julien Bataillé , I'm a software engineer at Rakuten and I work with a team in charge of developing and maintaining the API Gateway for our entire group of companies.
- If you attended the session this morning "Building the Next Era of Software" maybe you heard my colleague Alex talking about the challenges of providing Kong to such a large and diverse organization. Today, I'd like to talk about one particular use case that came to us earlier this year. We were talking with one of our largest team here in the US about getting onboard and expose their APIs through our shared instance of Kong. They were interested, Kong is a great product after all, but they raised one important question:
- how Kong can help to manage GraphQL APIs? And this is the question I'd like to try to answer with today’s presentation.
- this is the agenda for today’s talk. First, I will start with a very quick introduction to GraphQL. Then I will try to highlight the differences between REST and GraphQL and how it’s impacting the rules and policies we use to manage APIs. Finally, I will show you some examples of Kong plugins we developed with a live demo if we have enough time.
- But first, a few words about GraphQL. It’s a very popular alternative to REST for front end applications. Since it was open sourced by Facebook in 2015, adoption has been really strong and nowadays you can find both server and client implementations for almost every stacks. It allows the client to define the structure of the data required and the server will return exactly that and nothing else. This is why it’s often considered a great solution to solve the so-called Over-fetching and under-fetching problems. It’s doing much more than that but I’d like to insist on this point because I think this is one of the most relevant to today’s topic.
- So to illustrate this I’d like to take an example that is probably very familiar to today’s audience. The Kong Admin REST API. How many of you used or know about the Kong Admin API? So let’s say I want to display the list of services configured on my Kong cluster and in the same page I want to see the list of plugins activated on each service.
- To achieve this, I first need to call the services endpoints and it will return the name, host and creation time for each of my services. Notice that I also receive a lot of fields in the response that are not required to display this page to the user. This is Over-fetching: I get data in the server’s response that are useless to my application. But the plugins for each service are missing from this first response so I need to make another round trip to the server to get this additional piece of information. Not only one but 2 calls in this example because I need to display 2 serrvices. At least I can send those two last requests in parallel but in more complex scenarios it is sometime not even possible to do so. This I hope is a good example of under-fetching. Now let’s compare it to how we would achieve the same result with GraphQL:
- First on the client we would build a query that would contain only the information we need: name, host, creation time, plugins. On this plugins entity we specify only the fields we want, in this example the name of the plugin. We would POST this query inside the body of a HTTP request to the Kong GraphQL Admin API
- and the response would contain exactly the fields specified in the query. We get the all the information we need to display our page in a single round trip to the server. So from this example you can already notice a few differences between REST and GraphQL that will have an impact how we implement API Management policies.
- First, instead of many endpoints in a typical REST API we now have a single endpoint for GraphQL. The resource selection with REST is usually defined in the route or path of the request whereas with GraphQL this resource selection is specified by the operation sent in the body. With REST, we are used to conventions on the HTTP verb to define operations: GET, POST, PATCH, DELETE can be used to implement policies or restrictions on the API usage. For most common GraphQL implementations only POST operations are necessary. Finally, as we just saw in the previous example One GraphQL call can replace multiple REST calls. How do we implement Rate Limiting in this case, does it even make sense to use rate limiting? I hope a this point you will agree that to manage GraphQL endpoints, we have to look into the GraphQL operation to extract some characteristics about the query or mutation and use those characteristics to implement our API Management policies.
- To make things more concrete let me share a few examples of what we can look into. First we could measure the nesting of a query and impose some arbitrary limits to avoid this kind of recursive query.
- Next, we can measure the cost of a query by counting the number of entities required by the client. this example is from the Github GraphQL API: the client requested the 50 first repositories from an account and for each repository the first 10 issues for a total of 550 nodes. This is how Github implements rate limiting: instead of a number of 5,000 request per hour, they set a limit of points per hour. Each type of node costing an arbitrary number of points.
- Query whitelisting is another policy we can implement if we have the capability to compare GraphQL operations and determine when two operations are functionally equivalent or not. I will develop this one in just a moment.
- But first I want to mention that you will find libraries that implement the policies I just showed. Those are language specific solutions so it means you need to modify or reconfigure your GraphQL server to enable it. This is where I believe Kong brings a better alternative: as for REST APIs, we want to move the implementation to Kong plugins instead of each individual upstream API. It gives us the opportunity to enforce the same policies across all our GraphQL servers implemented in Javascript, Python or Java.
- In the past few months we implemented two Kong plugins at Rakuten to validate this approach: the first one is fairly basic and implements the Depth limit policy I talked about earlier. It allowed us to verify we could parse a GraphQL query in a Kong plugin. The second one is a little more complex and this is the one I’d like to demo today.
- There is no Open Source without a Community.