In the case of GraphQL, I'd be interested in seeing strategies for multiple graphs within a single codebase. Essentially being able to produce different schemas based on config. I know that superficially it's as simple as some "if" statements, but I'm curious about the maintenance/scalability side of it.
Many GraphQL libraries take some sort of schema definition and then serve it at a route (eg. /graphql). To support multiple schemas, you'd just write a different definition and serve it at a different route. How you resolve the fields is up to you, but both can use shared underlying business logic in these resolvers.
In terms of maintainability, you have to take care that your changes to the underlying business logic don't break assumptions of each schema. And if you want to evolve one schema (eg. say, deprecate a mutation argument, rename a field and deprecate the old naming), you have to ensure that your underlying business logic is backwards compatible for any other schemas (and their clients) relying on it.
None of them are really "great". I get acceptable results with OpenLink Virtuoso if I give it a lot of RAM, tweak the configuration, and baby it when needed.
