A new path for GraphQL Import - help us decide on the roadmap!
Urigo opened this issue · 3 comments
Hi everyone!
I'm @Urigo the founder of The Guild.
As recently been announced on the Prisma blog, we are taking over the maintenance of this library going forward.
I've expressed it in the blog post in more details but I would like to start by thanking Prisma for conceiving, creating and maintaining this library so far and also for doing the selfless act of providing it with fresh life by handing over the maintenance to us.
We already have a certain plan in mind going forward, some of it we've specified in the blog post, but we want you, the users and community of the library to be part of influencing the roadmap going forward.
One thing to note about The Guild - We place all the open source packages we maintain under individual person's Github profile instead of under a GitHub org or a company.
That is part of our philosophy - it puts more accountability on the maintainer and it also lowers the barrier of creating successful competing forks.
So we will transfer that repository from under Prisma as part of the transition.
I'm looking forward to start the discussion here below.
Please share how and why you use the library today, what are your biggest pain points today and ideas and features you would like to see in the future.
I will add points into the description here as we go.
Let's make this happen!
Please share how and why you use the library today
We have just started doing a migration towards using graphs in our code-base. We use graphql-import to take advantage of the SDL format in .graphql files, as well as the tooling that comes with those files.
This format provides a clear distinction between the server's graph, and the logic behind each field, making it more reasonable to contextualize.
What are your biggest pain points today
The only real pain points I've experienced with this module has been the turnaround on #359
Ideas and features you would like to see in the future.
I believe with the advent of Apollo Federation, there's now a need for de-coupling from the schema stitching paradigm, and be able to have both: locally referenced graphs that get aggregated on instantiation, and the ability to reference the remote-graphs from SDL files.
Thanks for all the hard work, it's much appreciated, and I look forward to seeing what comes next
@Globolobo can you explain about the remote graphs you are referencing?
Are those 3rd party APIs?
Are those other modules inside the same codebase?
@Globolobo can you explain about the remote graphs you are referencing?
Are those 3rd party APIs?
Are those other modules inside the same codebase?
@Urigo I can't speak for everyone but, in my team's scenario it's both other modules within the same codebase, as well as APIs from different parts of the organization in different repos only available internally