Is a GraphQL API in the works?

[Dhruvan Ganesh]

Could you consider a GraphQL API in the future?

1. Looking at the number of breaking changes in each major version in SonarQube, can GraphQL be considered to solve this problem?

2. Sonar typically loads a lot of data in its /issues/search API (my application's largest and longest call) and when I have to search through a lot of rules I have to make sure the call doesn't exceed ~2000 chars. These problems can be solved by using GraphQL.

There might be more points in favor of GraphQL but these are pain points that I've faced during development.

[G. Ann Campbell]

Hi,

Please be aware that the standard courtesies (Hi, Thanks, ...) are appreciated in this group.

It's not clear to me what either of your problems really is or why you think GraphQL would solve them.

Ann

[carlo.bo...@sonarsource.com]

Hi Ann,

Ganesh will correct me if I'm wrong, but I believe he does not have an immediate problem. These are rather architectural suggestions. First there's the fact that the SonarQube api evolves frequently : GraphQL has mechanics that support soft deprecation of data structures with backwards compatibility, which might make these evolutions less painful for users of the api (as they would have more time to update their clients after the api changes). Second, some calls to the api can return a lot of data : GraphQL is first and foremost a query language, so, instead of running a generic search that returns plenty of information about everything that was found, you could run a search with a specific filtering query that would reduce the fields that are returned (so, you still get 100 results, but each result only contains the fields you care about).

I don't know if these issues are strongly felt in general, nor if GraphQL would be the one and best way to have a go at them, but it's probably worth a chat.

Cheers,

Carlo