kowainik / kowainik/github-graphql
More modular structure
- Dominant language
- Haskell
- Stars
- 7
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Current structure of modules is a bit messy:
```haskell
GitHub
GitHub.Author
GitHub.Connection
GitHub.GraphQL
GitHub.Id
GitHub.Issue
GitHub.Label
GitHub.Lens
GitHub.Milestone
GitHub.Order
GitHub.PullRequests
GitHub.Render
GitHub.Query
GitHub.Repository
GitHub.RequiredField
GitHub.Title
GitHub.User
```
Current problem is that we have fields for different types (title of issue, login of user, etc.) and we also have different connections with input parameters (issue by state, pullrequests, etc.). Some connections can be polymorphic, so to abstract further, it's better to separate types.
I propose a new structure with clearer boundaries (and probably avoiding recursive dependencies).
I will write in a shorter syntax for clarity. Mostly duplicates the GitHub API structure:
```haskell
GitHub
Types
Connection
Issue
Milestone
PullRequest
User
Id
Connections
Labels
Issue -- issue by number
Issues -- list of issues
PullRequests
Milestones
Interface
Actor -- has author name
Enums
IssueState
PullRequestState
IssueOrder
Queries
Repository
Viewer
Mutations
CreateIssue
AddAssigneesToAssignable
GraphQL
Query
Mutation
Render
API -- calling remote API, better name needed
Common
Query
Mutation
Abstraction -- local abstractions for better UX and UI, better name needed
Lens
Author -- HasAuthor typeclass and instances
Title -- HasTitle typeclass and instances
RequiredField
```
With this structure, it's clear what to add and where:
1. All new types go to `GitHub.Types`.
2. All new connections for those types use types and go to `GitHub.Connection`
3. New read-only queries and mutations go to the corresponding sections.
4. Functions to call GitHub API are in the `GitHub.API` module.
5. Our local helpers in `GitHub.Abstraction`
Contributor guide
Research direction
Start by comparing the current GitHub module tree with the proposed Types, Connections, Queries, Mutations, GraphQL, API, and Abstraction sections in this issue. Resolve the proposed boundaries and names before moving modules; done means the structure has clearer responsibilities and avoids the recursive dependencies described.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, haskell
- Domain
- api, backend-api-design
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100