Spike: Investigate GraphWrap to see if it is worth implementing

Proposed Changes

I am proposing that we perform a spike with the intent of determining whether it would be feasible and valuable to implement GraphWrap to replace our custom schema generation code in nautobot.core.graphql.

No more than a day should be spent attempting to implement GraphWrap and to identify and assess how it compares to our current custom implementation. The outcome of this spike should be a decision and a level of effort estimation to the tactical steps required to move forward.

Justification

While our current implementation works for the common case there are a growing number of edge cases that we have yet to solve (See: #446, #596, #464). The GraphWrap library appears to do largely the same thing, but requires almost no code on our side “by adding only two lines of code to your django project” (according to the project documentation).

GraphWrap is also fully tested. Ideally, it would result in us having approximately 600 fewer lines of code to maintain, but it remains to be seen whether we would still get the desired behavior we want. All the same, from a maintainability perspective, it would be better to contribute upstream to an already established project than to continue to maintain our own implementation.

Acceptance Criteria

• Evaluate if we no longer need to restart to update schema changes
• Evaluate performance impact by switching to GraphWrap
• Evaluate maintenance difference (currently hybrid of declarative & dynamic vs entirely dynamic with GraphWrap)
• Determine any breaking schemas changes
• Evaluate licensing, currentness, and stability of GraphWrap
• Can we add backwards compatibility to address breaking changes

[jathanism]

@PaulGilmartin Thank you for taking the time to comment here. I appreciate your interest in helping! This is definitely food for thought.

[PaulGilmartin]

Hi @jathanism

I’m the maintainer/sole author of GraphWrap. I was pleased to see your interest in the library. I just wanted to add to what you remarked above.

First, I believe #446would be solved with GraphWrap. I’m judging this off of the following comment in that thread: "_I worked on this for a while now, sadly none of the approaches that we could come up with proved viable. For posterity, let me document them:

The simplest way to make this work is to generate the schema everytime it is needed (i.e. on every API call). Unfortunately, this is prohibitively slow (on the order of seconds)."_

Generating the schema on API call is exactly what GraphWrap does. I have however never seen it take anything close to the order of a second to generate that schema though - the Python code it uses to do so is really quite light. I have had it running on a production API with possibly 50 distinct schemas and schema generation time is not noticeable. It is perhaps the case however that your API really is huge, I’m not sure.

For the other remaining open issue, I’m not quite familiar enough with your API to be able to comment on whether or not GraphWrap could handle it.

If you do decide to investigate, I’d be more than willing to lend a hand with any issues or questions.

Cheers,

Paul