Meta: GraphQL development process
I've noticed that what we do is slightly different than what we say we do, and I wanted to flag this and adjust either our process or the documentation so they match. Here's what is formally set up:
- GraphQL API foundational development falls officially to the groupproject management of the devopsplan team (@gweaver DRI) - this does not include individual features being implemented in GraphQL (e.g. devopssecure vulnerability, devopsmonitor alert management, etc)
- As a part of Product, there is a process for scheduling and tracking GraphQL issues within the groupproject management team
I personally think what we do works well, but it does not match the above
- Much of the GraphQL foundational work (by "foundational" I mean common to all GraphQL API, such as complexity or lookaheads) is done by a group of GraphQL 'volunteer' experts on a variety of teams.
- The experts identify pain points, tag everyone else, begin a conversation, and often come up with a solution (or at least have a good discussion)
- GraphQL is complex and while one single person could theoretically understand it all, we have pockets of deeper expertise - e.g. @digitalmoksha knows keyset pagination, @ntepluhina knows heaps about Apollo, @seanarnold knows externalised API integration/pagination, etc.
It's not really acknowledged that the above is a thing. Maybe it should be?
Some possible challenges/tensions:
- There is a lot of GraphQL foundational work, and it flies under the radar a bit.
- Much of this GraphQL work does not affect customers directly, but it would affect quality and developer efficiency if they didn't get addressed. So some of it is "Product" but most falls under the "Engineering" purview.
- We sometimes ping @gweaver as the nominal DRI, but sometimes that doesn't happen because bias for action and that.
- If there isn't an immediate pain point (or if it's not championed by an engineer), the issue sometimes falls by the wayside (put more succinctly by @tkuah below... we're not really developing towards a vision or a roadmap to that vision at the moment. it's all a bit ad-hoc)
- GraphQL experts have a higher review load since we are called as GraphQL domain experts to review both codebase-wide GraphQL implementations (that's where a lot of conversation and improvements come from), as well as our own group's foundational improvements
- If this group of volunteers wasn't available, I'm not sure that the Project Management team would be able to manage it (though I could be wrong here, there are only five backend engineers and a very wide product scope).
A couple of suggestions to get the conversation started
- Create a GraphQL-foundation-specific label or way to track "foundational" GraphQL API issues? GraphQL and api are often placed on feature implementations that use GraphQL
🤔 - Create a board for GraphQL issues using the above with checkins, say, during Office Hours?
- Figure out a process to make it clear who's the DRI for issues (@gweaver or an Engineering DRI, say, whoever is assigned to the issue or volunteers to take the solution)
- Cut a handbook MR to describe what we actually do
😆
WDYT GraphQL folks?
Edited by charlie ablett