Closed benhaynes closed 5 years ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I think this is the most requested feature by far... and it's the one that comes up in sales conversations the most too. What would it take to add support for this? Even if just to get some of that hype-train action. 😉
Could it really be as easy as /_/gql/...
? A single endpoint with this alternate query option...
@rijkvanzanten @WellingGuzman
The problem here is authentication and permissions. Recreating directus' granular permissions system to work with graphql is a lot of work. The next best thing we can do is make the graphql endpoint admin only and give full access to everything (no permissions check whatsoever)
Ahh, right. I think that's a great option! So all we have to do is check that the token used is an administrator.
Do we have a sense of how long this would take? I assume there are libraries written for this already.
https://github.com/webonyx/graphql-php
Came across this
That one looks pretty good (stars, open issues, docs). @WellingGuzman can you give a time estimate?
Really looking forward to this. Having used graphql-php in the past, I think it will be a great fit.
I do not have experience working with GraphQL, and I would love if someone with experience with GraphQL help me to implement this feature. Or If they want to implement it and open a Pull Request, I would be open to help them implement it on Directus.
The idea I am looking to implement is used a GraphQL library (such as graphql-php
) to translate the GraphQL query input to an array that php understand (the way it translate query string into array).
I am learning how this all works, so the sooner the help comes the sooner this feature can be implemented.
I'm not sure if this is the best way, but my thinking is:
This is a single Directus API endpoint where all parameters/options/responses are handled by the GraphQL library. This is an admin only feature (only works with admin tokens/users) and has direct database access with no limited permissions. After Directus checks the auth it let's the endpoint do what it needs to do.
Any community thoughts on this approach or alternatives?
Why remove GraphQL feature for non-admin?
Also if you are an admin you have full access. Or what do you mean by direct database access?
I don't think we can control or limit access to data with the way GraphQL works. I think it would have to bypass the Directus ACL if I'm not mistaken.
I imagine this endpoint having full access to data and assumed the PHP library would simply accept database credentials (easiest and fastest way to implement).
I don't think we can control or limit access to data with the way GraphQL works. I think it would have to bypass the Directus ACL if I'm not mistaken.
Why? I don't see any different from GraphQL and using query strings or json (in request body) in terms of querying or posting data.
What I understand is that GraphQL is just an input data type, and the library is middleman that helps us translate that request into something the API understand. Same thing we do with JSON, we translate a JSON string to something php understand.
If I am missing something how do you think GraphQL works that won't allow us to control access?
As fas as I am concern, instead of:
https://directus.example/_/items/users?fields=id,name
https://directus.example/_/items/users/1?fields=id,name
We do something like this:
query {
user {
id
name
}
}
query {
user(id: 1) {
id
name
}
}
The only different is that instead of using the query string we are using GraphQL. Now, GraphQL has vast of features, as far as I am concern. I am thinking of GraphQL as an input format for what currently works on the API side.
I imagine this endpoint having full access to data and assumed the PHP library would simply accept database credentials (easiest and fastest way to implement).
This is another thing that I don't think makes sense to implement in the core directus, this will be a (MySQL) SQL Wrapper.
deleted a comment from db473653 20 minutes ago
REALLY @benhaynes @directus ?
I'm sitting here trying to USE your product, glad see a good/interesting topic (this one), filled with less-than-well-informed comments about how GraphQL gets implemented, and I provide a clear, legitimate suggestion to YOUR question -- to just explore or look at a well-done implementation.
And you DELETE it?
That's an unfortunate, childish response.
What -- worried about the more capable competition?
Fine. Figure it out on your own.
Hey @db473653 — sincere apologies if I misunderstood your post, but a non-existent GitHub user simply pasting a link to a different headless CMS seemed a bit like spam.
"worried about the more capable competition?"
Not in the slightest. I think all the headless platforms out there are a great alternative to traditional CMS. And while biased, I'm quite confident that Directus is the best/ideal OSS headless option.
In any event, we have looked into Mesh and their single endpoint (/{project}/graphql
) is a given. This conversation is about the GraphQL integration into the Directus ACL/API... which is more specific to our platform.
From my point to view, having an admin-only endpoint does not make much sense. So the implementation would have to go through the Directus ACL. Those should be anyhow included in resolvers for the individual types.
The part where it is not like https://directus.example/_/items/users?fields=id,name,https://directus.example/_/items/users/1?fields=id,name
is that I would want to query across relationships, e.g.:
query {
blogs (slug: 'xyz') {
title
content
pages {
headline
content
}
}
}
Thanks @puco — the main reason for starting with admin-only is that it makes it easier/faster to develop. We're a small open-source team, so while we agree that full ACL would be ideal, we're trying to get this done in stages (unless someone knows of a big corporate sponsor who needs this 💸 ). Also, we're always open to contributions is anyone wants to help out!
@hemratna is the lead for our GraphQL endpoint, and he's just getting started. Depending on how dynamic collections/fields are fetched to build the GQL schema, maybe honoring ACL won't be too difficult... but first we want to get a basic proof-of-concept working.
@puco
The part where it is not like https://directus.example/_/items/users?fields=id,name, is that I would want to query across relationships
Except, you can! Your example would be
https://directus.example/_/items/blogs?fields=title,content,pages.headline,pages.content
Maybe I didn’t really understand what you are talking about above (I don’t know enough English), but I’ll say this: Now very relevant in terms of providing GraphQL is the product https://github.com/hasura/graphql-engine
He forms api on a ready-made database. And adds ACL and other features on top. But, based on what I need, and why I got here, I need an admin panel to manage this data.
My point api: https://api.emista.online/console The implementation of the admin on the react-admin for this point https://hidden-citadel-38499.herokuapp.com/ (login / password any)
Well, I have difficulty creating the GraphQL bundle and react-admin due to the fact that I am not a programmer, but I need authorization, roles, and so on.
I see the work of directus graphql only in this way if you implement GraphQL only as a database:
Hey @Pomazan-Bogdan — I think that's how @hemratna is building this. We should have a working demo soon and then we'll post a dev link here for review.
I have a question on implementation. based on how directus now works, work with graphql should be based on the principle of the first scheme. Based on this, directus should generate it, and there should be a database that can work this way, and this could be a dgraph for example and not a SQL database. Then there will be no need to write a generator complex schema generator.
what's the good word on the status of this feature? any updates?
It's the only hard sell compared to contemporaries is the lack of a graphql endpoint, and im looking forward to telling those interested on the when and the where it may be here
Thanks!
@RedactedProfile — we're squeezing it into our other work-streams:
As of now we're shooting for a Directus GraphQL beta the first week of April!
Thank you so much for the speedy update! I look forward to it :D
On Mon, Mar 25, 2019 at 10:14 AM Ben Haynes notifications@github.com wrote:
@RedactedProfile https://github.com/RedactedProfile — we're squeezing it into our other work-streams:
- 2 days: Search
- 2 days: Adding support for Directus built-in collections
- 1 day: Final round of testing and code overview
As of now we're shooting for a Directus GraphQL beta the first week of April!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/directus/api/issues/367#issuecomment-476294710, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_eJ2i8i7j0dXKUsHdsn1AXUEId4cZaks5vaQPwgaJpZM4WfEis .
Love the first week of April :)
Love the first week of April :)
why what happened?
@RedactedProfile
[@benhaynes]: As of now we're shooting for a Directus GraphQL beta the first week of April!
😄
@RedactedProfile
[@benhaynes]: As of now we're shooting for a Directus GraphQL beta the first week of April!
smile
hahaha apologies I had special moment, I thought @u12206050 's comment was in regards to some sort of april 1st / fools day jab or something when I wrote that
Haha, this was our only April Fools day mis-information...
If Directus was built on PostgreSQL it would be possible to use it with API generators, like
To achieve better clarity/visibility, we are now tracking feature requests within the Feature Request project board.
This issue being closed does not mean it's not being considered.
This was added in https://github.com/directus/api/pull/1005
:rotating_light: MIGRATED FROM REQUESTS.GETDIRECTUS.COM :rotating_light:
GraphQL support
:+1: = 56
Created 1 year ago by @PierBover
@rijkvanzanten – :+1: (1 year ago)
<3 this
@luminarious – (1 year ago)
As a front-end developer GraphQL feels magical every time and the performance improvements from getting only the data necessary for current view add up quickly!
@nikola66 – :+1: (6 months ago)
It seems in the pipleline for Q2 / 2018 but really counting the days to get this!
@kosirm – :+1: (5 months ago)
GraphQL and Microservices are most fast moving parts of the web in 2018!
@sendtogil – :+1: (3 months ago)
plzzzzzz
@sendtogil – :+1: (3 months ago)
plzzzzzz
@T-Specht – :+1: (1 month ago)
Really looking forward to this feature for the usage with React
@bianpratama – :+1: (3 weeks ago)
Can't wait!
@allanleonardjr – :+1: (2 weeks ago)
Definitely need this!!!!