You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I'm trying to make sense out of this architecture. Currently I have one connector per model, which I now realize that that's more like the repository pattern.
I've been reading How to structure GraphQL server code where they seem to prefer caching and batching in the connector. Of course there they don't mention managers sooo...
The way this project is set up I believe a better place would be in the managers. Is this correct?
That would mean there is some place where to instantiate managers per request since you don't want to share cache between requests. Then it makes sense to place all managers on the GraphQL context object instead of as properties of the models.
I'm so confused, currently trying to simplify your implementation to be easier to read while keeping most of the benefits.
The text was updated successfully, but these errors were encountered:
Hi @CrocoDillon! Thank you for showing interest in this project.
I built it 4 years ago as I intended to create a framework that would allow developers to focus on building a structured domain based on well defined patterns instead of having the mess of loose uncoupled resolvers.
Unfortunately I haven’t had the proper time to develop this project further, so it has never gained enough momentum. Since then, as well, lots has changed in the ecosystem. A lot of the goals of this project have already been achieved by https://prisma.io, so I recommend checking it out instead.
That's the way to go if you look for something mature and reliable. If you feel adventurous, though, you can take a look of my new experiment: https://github.com/zvictor/faugra (I have only shared it with the faunadb team so far because it is not ready for public access yet).
I will write a deprecation note on the README file so it will become more clear to the newcomers.
Hey @zvictor, thanks for the quick response! I did notice the age of the project 😆 Also been reading more on the Apollo website and saw they are using DataSources now (which I guess are managers with a different name).
Anyway thanks for the links, I am checking them both out right now! Cheers 😄
Hello, I'm trying to make sense out of this architecture. Currently I have one connector per model, which I now realize that that's more like the repository pattern.
I've been reading How to structure GraphQL server code where they seem to prefer caching and batching in the connector. Of course there they don't mention managers sooo...
The way this project is set up I believe a better place would be in the managers. Is this correct?
That would mean there is some place where to instantiate managers per request since you don't want to share cache between requests. Then it makes sense to place all managers on the GraphQL context object instead of as properties of the models.
I'm so confused, currently trying to simplify your implementation to be easier to read while keeping most of the benefits.
The text was updated successfully, but these errors were encountered: