sbegaudeau

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.

I use GraphQL as my main solution to build APIs these days and I have worked with GraphQL for almost 4 years.

I agree with you that "being able to project out individual fields seems like a niche benefit" and I almost never use it to let anyone ask for anything. I rely on GraphQL mostly for its schema in order to have a coherent view of my API at all time. I can thus easily validate my frontend queries during continuous integration and I know the structure and type of the result that I will obtain from my queries.

When I refactor my API, I can evaluate the impact quite easily since my build will tell me about invalid queries in my frontend and unused fields too (since I am building my API for known clients, unused stuff has no place in my API). It brings me the same security net during changes to my API as TypeScript does.

Since I'm not building my API for unknown clients which could ask for anything but instead for specific clients that I can control, I am still doing most of my joins in my datastore. I am relying on a Java implementation of GraphQL and I don't feel any GraphQL-specific complexity on the backend, it may be different with other implementations of GraphQL. In Java, with a minimal amount of annotations, most of my schema is created automatically from my data classes.

On one of our project, we are using CSS Grid but for a part of our application we need to support IE11. For this use case, we have decided to use the Grid implementation of IE11 and while different on some points, it is still close enough to be maintainable next to some CSS Grid if you don't use some advanced concepts.

My company has open sourced a lot of code (80% of our products) and finding people outside willing to contribute is actually quite difficult if you don't do things properly. We actually spent quite some time to improve the build and the branding, to check the intellectual property of our dependencies etc.

If you want real contributors, building a community often require a good documentation, examples, etc.