method cache and memory leaks

[terion-name]

I have a specific usecase where schemas are not static, but should be updated over time without entire app restart.

In short, I have a master express server (that handles task-specific routing for SaaS system), that spawns child apollo-express servers (each for corresponding subsystem), that each use complex schemas built with graphql-binding over underlying microservices.

When something in subsystem's microservices updates I nee to rebuild it's schema. So I delete from memory corresponding apollo-express server and it is rebuilding (and new graphql-bindings are generated).

After each rebuild a manually call garbage collector. As of bindings do exist only in context of apollo-express server, deleting this server should terminate all references to graphql-bindings and GC should free memory of them.

But I encounter a problem with graphql-bindings method cache — it is not cleared when bindeings are deleted. After every update method cache grows and grows:

1. It shouldn't act like this in general, method cache should be bound to concrete Binding instance to be cleared, when this instance is deleted
2. As for now, is there a way to manually clear method cache?

UPD
As I see from here https://github.com/graphql-binding/graphql-binding/blob/master/src/Binding.ts - no, there is no access to this cache map :(
Using such global static and unreachable cache is a design flaw, IMO

[BrunoScheufler]

@terion-name I'm experiencing the exact same problem, have profiled my application and found two sources of memory leaks, in the memory cache of graphql-binding, so this issue you've described, as well as an existing schema cache in the prisma-binding package. I think the authors didn't intend use cases like having multiple schemas generated over time, which is a pretty serious assumption to begin with, especially if the caches aren't isolated to a context and can't be accessed from outside. I'll try to file a PR for this package, hope we'll get this fixed in time!

[terion-name]

I currently use an extended class for this purpose:

import {Binding} from "graphql-binding";

export default class CachelessBinding extends Binding {
  buildMethods() {
    return {
      query: this.buildQueryMethods('query'),
      mutation: this.buildQueryMethods('mutation'),
      subscription: this.buildSubscriptionMethods(),
    }
  }
}

[Urigo]

Thank you for reporting.

In the last few months, since the transition of many libraries under The Guild's leadership, We've reviewed and released many improvements and versions to graphql-cli, graphql-config and graphql-import.

We've reviewed graphql-binding, had many meetings with current users and engaged the community also through the roadmap issue.

What we've found is that the new GraphQL Mesh library is covering not only all the current capabilities of GraphQL Binding, but also the future ideas that were introduced in the original GraphQL Binding blog post and haven't come to life yet.

And the best thing - GraphQL Mesh gives you all those capabilities, even if your source is not a GraphQL service at all!
it can be GraphQL, OpenAPI/Swagger, gRPC, SQL or any other source!
And of course you can even merge all those sources into a single SDK.

Just like GraphQL Binding, you get a fully typed SDK (thanks to the protocols SDKs and the GraphQL Code Generator), but from any source, and that SDK can run anywhere, as a connector or as a full blown gateway.
And you can share your own "Mesh Modules" (which you would probably call "your own binding") and our community already created many of those!
Also, we decided to simply expose regular GraphQL, so you can choose how to consume it using all the awesome fluent client SDKs out there.

If you think that we've missed anything from GraphQL Binding that is not supported in a better way in GraphQL Mesh, please let us know!