We have a small core module with its core GraphQL schema and additional modules which are all extending this core module. We want to have the liberty to leverage those modules in various applications for the needs of our clients.
To give you some examples, in one use case our modules are used within desktop applications running locally, in a couple others they are used in regular web applications, in another they are embedded in a Java server running inside a VS Code extension (no network connection required everything runs locally). Sometimes we have our regular frontend modules which are performing some queries to our backend modules but in the VS Code extension for example, the VS Code integrations performs other kind of queries to our backend modules.
Each modules bring some capabilities and our projects can take those capabilities and reuse some or all of them.
In my company, we are building a set of monolith applications based on frontend and backend modules that we can compose (Spring jars and React npm packages). As the maintainer of several of those modules, I don't know how my modules will be integrated in each monolith and I don't know exactly how all the complete frontend of each monolith will interact with each API.
Having the ability to define small schemas for each module gives us a great way to communicate the contract provided by a backend module and the parts of the API required by its associated frontend module.
It can be extended very easily and it gives each monolith the ability to ask for anything they want. On top of that we are using a ton of subscriptions so having the ability to use a common language even for the websocket parts is great.
So in the end, the ability to request anything from the API, the simplicity to extend and compose APIs and the support for subscriptions are features that we would have needed in REST which are "included" in GraphQL.
I'm also a French developer and I have delivered projects used by French customers in the public sector and it really depends. I have worked for/with French public sector customers on open source projects in popular open source foundations where everything is in English (code, comments, user manual, etc) with a regular open source license but I also know of teams in public sector customers where everything they build has to be in French including the code itself. Ask your customer.
To give you some examples, in one use case our modules are used within desktop applications running locally, in a couple others they are used in regular web applications, in another they are embedded in a Java server running inside a VS Code extension (no network connection required everything runs locally). Sometimes we have our regular frontend modules which are performing some queries to our backend modules but in the VS Code extension for example, the VS Code integrations performs other kind of queries to our backend modules.
Each modules bring some capabilities and our projects can take those capabilities and reuse some or all of them.