Prisma binding class should not use global variables about prisma-binding HOT 11 CLOSED

Great, I think that's enough info for me to get started on a PR.

from prisma-binding.

Great point! This should definitely be improved. The caching mechanism is intended however it should cache based on a schema level (so instead of a single cache variable there should be a cache map).

from prisma-binding.

Newcomer to the project; Git history shows graphql-schema-cache previously used. Was there a reason for dropping it?

from prisma-binding.

Yes this was based on a different „architecture“ and is now no longer needed. It refers to another kind of cache than this issue describes.

from prisma-binding.

Another newcomer! I have another use case: i'm building a multi tenant system of which I am deploying multiple databases with identical schemas. E.g service-1@dev and service-2@dev.

I want to then switch the endpoint when creating a new Prisma instance on each request. E.g endpoint/service-1/dev and endpoint/service-2/dev.

However due to getCachedRemoteSchema using the typeDefs as the key, it's impossible to switch endpoints on the fly if the schemas are identical.

I've got it working by using the endpoint as the key. Is this a suitable solution for my use case?

from prisma-binding.

Hi there!
I have the same issue as @pollard93 , I can't switch between multiple endpoints having the same schema.

But I've found a solution which doesn't require me to fork this repo until a better solution is found.

I currently am doing a workaround by importing the typeDefs from the file myself and then appending a comment with the service and stage names. This makes the cache think the typedefs are different.

from prisma-binding.

@Errorname Nice workaround I'm now doing the same, thanks.

from prisma-binding.

Hey 👋, I believe this issue has been resolved in most recent versions of prisma-binding. Taking @schickling's comment as a basis, I believe new implementation constructs a remote schema based on provided typeDefs instead of blindly saving a global default.

More about this can be found in the cache.ts file of prisma-binding; I'll include the link below.

https://github.com/prisma/prisma-binding/blob/master/src/cache.ts

from prisma-binding.

Hey @maticzav !
Well, @pollard93 and I still have an issue with the current implementation. Here is our issue:

We both have a multi tenant system in which we created multiple services having the exact same schema (and therefore same provided typeDefs). Then, using prisma-binding, we try to register some (at least two) of our identical services. But, because they have the same typeDefs, the cache only sends requests to the first registered service!

In order to make a multi-tenant application with prisma-binding, we have to bypass the cache using the following trick:
For each of our services, we manually import the typeDefs file ourselves, and append a comment with the service and stage name. The cache is now fooled thinking they are different typeDefs and allow us to query independently our services.

I hope I explained why the cache is still a issue, at least for our use-case.

from prisma-binding.

I think a potential solution for our issue would be to cache based on the endpoint instead of the typeDefs

from prisma-binding.

🎉 This issue has been resolved in version 2.2.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

from prisma-binding.