I plan on adding more examples and some tests within the next two weeks. I’ll open a PR then. My hope is to take an iterative approach here and merge a small PR first that doesn’t cover all models. Maybe we can start with easy ones like “models” or “bookmarks” so we have something to play within the frontend. We can add support for plug-ins etc. in separate PRs.
A quick status update: We are still actively working on this. We are implementing more and more core modules right now. We had some issues with graphql-activerecord gem and relations. It did not work well with sqlite. We’d need to invest more time to patch the gem or define relations manually.
3 Likes
Could we consider dropping sqlite support to avoid cycles trying to make a non-production database work?
1 Like
I think that point deserves a thread on its own, I would definitely be happy to consider it - writing code that works well on 2 databases is challenging enough 
Yet another status update: We have added support for cursor based pagination, see this blog post for a comparison of cursor vs. offset based pagination and a good explanation of both.
Expect a PR probably this week.
We also have added Json Web Token (JWT) Authentication support. Is there some interest to have this in core as well?
1 Like
Finally, here we go: https://github.com/theforeman/foreman/pull/5336
I’d suggest continuing the conversation in the PR. Happy to hear your thoughts.
2 Likes
Is there a volunteer who wants to work with us on this? I can definitely review and test the PRs, but I’d love to get a second opinion on the PRs.
Does somebody (maybe from the UX team) want to test the client implementation of this to figure out how this works?
pinging @ui_ux team and @Walden @Tomas_Strachota who haven’t joined the group yet apparently
Add them to the group (and developers)
I’m just a lowly moderator, I think only @Gwmngilfen and @Ori_Rabin have permission to add people to groups (but most groups are open to join)
Way to make a typo. I meant Added since I did that (/me has admin as well).
3 Likes
I definitely want to check this one. Thanks for all your efforts @TimoGoebel !
I’d like to play with it and take a look what it would take for hammer to use the graph api for list actions. I didn’t have a chance to get to it yet, but it’s on my todo.
Our main agenda is to use the graphql api as a backend for a small frontend app we are developing. As we want to use the new API before a new Foreman release is available that contains the changes, we’re trying developing it as a plugin.
We had a brief status call this morning and started to wonder if it makes sense to continue to ship the API as a plugin.
I quite like the idea, especially if we consider the API as experimental for starters.
What do you think? Do we want to have the new API in core or keep it as a plugin for now?
We have now talked a lot about graphql and the general feedback was positive. I have opened some initial PRs that implement the basic scaffolding. But have received very little feedback so far.
Is there a volunteer core committer who wants wo work with me on this?
3 Likes
One thing I’d really like to see from a v3 api is for it to be symmetrical in that you could GET data from the api, change the fields you wanted to update, and then POST it back without having to reformat the data, add fields, remove them, make extra calls to fill in extra data the POST call needs and other such work. It would make automating using the api to script changes a dramatically simpler task.
1 Like
FWIW, I just happened to listen to an interesting podcast about GraphQL - https://changelog.com/podcast/316.
Looks like this won’t make it to 1.20, I plan to look into it some more after 1.20 is ready.
Let’s not rush this, but I still think this is a very important move for the whole single page app effort. I already see some places where our API is a limitation for development and workarounds are being introduced to the codebase. I don’t want to be a grinch about this, but I don’t see a reason why we don’t do this.
1 Like
One interesting point that was talked about in the podcast is that graphql is really good for UI and internal APIs that we control on both sides, but that for public facing APIs it might not be the best fit (The podcast talks about Kahn Academy’s implementation, they have migrated many internal APIs to GraphQL but not the public facing ones).
do they say, why?
IIRC, mostly the inability to control what users may request from the api