kowainik / kowainik/github-graphql

More modular structure

Open
#32 0 comments 1 reaction 0 assignees View on GitHub
refactoring
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.