GraphQL as api v3

I had some more time and played more with graphql. The code now supports authentication and authorization and included example code how scoped search integrates with graphql. It does not yet contain mutations.

3 Likes

I played with your branch - nice :slight_smile: using the explorer does make it pretty simple to understand how to generate queries - I like it :slight_smile:

Could you add a few more examples? like related data (e.g. host with subnets/models etc)? it would be interesting to compare performance as well.

What are your next steps?

Thanks!

1 Like

Finally had a chance to look into GrahpQL more and I like what I see so far. Any thoughts on what a timeline for a v3 of the API would look like?

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 :wink:

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 :wink:

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