Currently the GitHub related API things are spread out between both the contributors and issue processing objects. One then ingests the other via instantiation / composition.
This makes it hard to maintain github related functionality. And encourages duplication.
It would be better to move that functionality out into a separate module called github_client.
Then if we decide to move request to graphql (which might make sense in some calls) it would all happen in a single spot.
So the first step of this is to simply
move all github related methods into a new github_client module (with an object there)
Add a composition step to both issues and contributor objects where the github related methods are available.
Swap out embedded functionality within each object to use the github object.
This initial step should minimize if not remove any needed modifications fo the front end API. But will make the back end easier to maintain / update / debug.
Currently the GitHub related API things are spread out between both the contributors and issue processing objects. One then ingests the other via instantiation / composition.
This makes it hard to maintain github related functionality. And encourages duplication.
It would be better to move that functionality out into a separate module called github_client. Then if we decide to move request to graphql (which might make sense in some calls) it would all happen in a single spot.
So the first step of this is to simply
This initial step should minimize if not remove any needed modifications fo the front end API. But will make the back end easier to maintain / update / debug.