You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bd...@apache.org on 2020/04/15 13:06:45 UTC

[sling-whiteboard] branch master updated: mention GraphQLServlet

This is an automated email from the ASF dual-hosted git repository.

bdelacretaz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/sling-whiteboard.git


The following commit(s) were added to refs/heads/master by this push:
     new 7f26ecd  mention GraphQLServlet
7f26ecd is described below

commit 7f26ecd10634f5d59281af43770f9d2c735e31d5
Author: Bertrand Delacretaz <bd...@apache.org>
AuthorDate: Wed Apr 15 15:06:37 2020 +0200

    mention GraphQLServlet
---
 graphql-scripting/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/graphql-scripting/README.md b/graphql-scripting/README.md
index a65d07a..35c534c 100644
--- a/graphql-scripting/README.md
+++ b/graphql-scripting/README.md
@@ -20,7 +20,7 @@ or turning any Sling Resource into a GraphQL endpoint. See the comments in that
 Here are my initial rough ideas for evolving this into a useful GraphQL core for Sling:
 
   * Use the Sling resolution mechanism to acquire the GraphQL Schemas, using maybe a `.gqlschema` request extension to get them. This provides full flexiblity to generate schemas from scripts, servlets, Sling Models or whatever's needed. We'll probably need to invent a way to specify which `DataFetchers` to use in the schemas.
-  * Demonstrate how to create a "traditional" GraphQL endpoint by setting up a Sling Resource to define it, which might need a proxy servlet for ease of use. As those endpoints use the Sling script resolution mechanism under the hood, it's possible to define several such endpoints with specific characteristics, schemas etc. if needed. Also, backing those endpoints with Sling Resources allows for setting up access control of them, which we wouldn't get with a path-mounted servlet.
+  * (Implemmented in a minimal way - `GraphQLServlet`) Demonstrate how to create a "traditional" GraphQL endpoint by setting up a Sling Resource to define it, which might need a proxy servlet for ease of use. As those endpoints use the Sling script resolution mechanism under the hood, it's possible to define several such endpoints with specific characteristics, schemas etc. if needed. Also, backing those endpoints with Sling Resources allows for setting up access control of them, which w [...]
   
 This (along with a few "details") would allow for this GraphQL core to be used in various modes: