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.
This is an interesting use case, I could see why GraphQL would be useful here where the contract between frontend and backend modules is not known in full and can change often.
Out of curiosity, is the reason for the contract between these modules not being fully known / being able to change often because of how your company wants to use them or is there another reason? I'm just wondering if the reason for this is wanting to be able to reuse modules across different projects for multiple clients or writing integrations for other tools or something totally different.
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.
> This is an interesting use case, I could see why GraphQL would be useful here where the contract between frontend and backend modules is not known in full and can change often.
But that's a misconception. If your contracts between frontend and backend are not known, you cannot just "open" your backend resources to the frontend so they are queried at will. That creates a huge entanglement that is only discovered after years of maintenance (at the beginning it may seem as a huge boost in productivity, but it's just pure tech debt: the debt you pay for not designing contracts between frontend and backend)
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.
From my 10+ years of experience: if you want contributors, build something that people really need, that is not available on the market. Build it just enough to solve the main problem it should. Make it really open and easy to contribute. People will chip in to scratch their own itches with the software.
Also, make sure you keep developing it yourself further in the open. Discuss features and architecture with community. Nobody wants to work on a code dump of commercially failed project. You can get a lot of help, if you show leadership by example.
Karl Fogel's Producing Open Source Software is hands down one of the best books possible on building communities and driving contributions. It was written ~10 years ago (pre-Github) so it's a bit dated but he's working on an update now - https://www.kickstarter.com/projects/kfogel/updating-produci...
Lot of companies are moving away from UML but not away from modeling tools by using domain specific languages (DSL) instead of a language like UML which tries to please everybody. The Eclipse Foundation hosts lot of domain specific tools like Xtext (1) for textual DSL or Sirius (2) for graphical DSL. Both tools are even compatible since they are using the same underlying framework, the Eclipse Modeling Framework (EMF). With those tools, and others (have a look at all the modeling tools in the Eclipse Foundation), you can build a "development environment" for your own domain with your dedicated editors (syntax highlighting, completion, error detection, etc) and designers.
Internet Explorer 8 shipped with Windows 7 too so it should be supported until January 2015 (2020 for the extended support). It can be an issue for corporate applications.
The Eclipse Foundation and the Free Software Foundation consider that both licenses are incompatible.
"The EPL and the GPL are not compatible in any combination where the result would be considered either: (a) a "derivative work" (which Eclipse interprets consistent with the definition of that term in the U.S. Copyright Act ) or (b) a work "based on" the GPL code, as that phrase is used in the GPLv2, GPLv3 or the GPL FAQ as applicable. Further, you may not combine EPL and GPL code in any scenario where source code under those licenses are both the same source code module.
Based upon the position of the Free Software Foundation, you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3."
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.