DEV Community: jjoo

Controlling Codex via JSON-RPC with Codex App Server

jjoo — Mon, 20 Jul 2026 01:07:46 +0000

Have you heard of Codex App Server?

Instead of interacting with Codex through the CLI, Codex App Server lets you control a Codex agent over JSON-RPC.

In other words, you can build your own GUI, TUI, task queue, or orchestration layer on top of Codex.

This article focuses on keeping a fast pace, so if you're looking for precise protocol details and specifications, please refer to the official README:
https://github.com/openai/codex/blob/main/codex-rs/app-server/README.md

Starting Codex App Server is as simple as running:

codex app-server

That's it.

The server will begin listening on standard input. From there, you simply send JSON requests that follow the protocol (technically JSONL, so each request must be on a single line).

This allows your own applications to launch and control Codex agents programmatically through Codex App Server.

Conversation Flow

A typical interaction looks like this:

Send an initialize request to initialize the server.
Start an agent conversation with thread/start.
Give the agent work using turn/start.
Wait until you receive turn/completed.
Repeat steps 3–4 until the task is finished.
Done.

Understanding Thread and Turn

When I first started learning the protocol, I found it difficult to picture the relationship between Thread and Turn.

The following example helped everything click:

Thread
├── Turn 1
│   User:
│     "Please investigate this issue."
│
│   Agent:
│     - Search the codebase
│     - Read relevant files
│     - Identify the root cause
│
│   turn/completed
│
├── Turn 2
│   User:
│     "Please fix it."
│
│   Agent:
│     - Edit files
│     - Run tests
│
│   turn/completed
│
├── Turn 3
│   User:
│     "Create a pull request."
│
│   Agent:
│     - Commit changes
│     - Push to Git
│     - Create a PR
│
│   turn/completed
│
└── End of Thread

A Thread is roughly equivalent to a Codex CLI session, while a Turn represents a single exchange between the user and the agent.

Hands-on

By default, Codex App Server accepts JSON-RPC messages through standard input.

If you copy and paste the following JSON into a running server (after converting it into a single-line JSONL message), you'll be able to interact with a persistent Codex agent.

{
  "id": 1,
  "method": "initialize",
  "params": {
    "clientInfo": {
      "name": "tutorial",
      "title": "Tutorial",
      "version": "1.0"
    }
  }
}

After sending it, you'll receive a response similar to this:

% codex app-server
{"id":1,"method":"initialize","params":{"clientInfo":{"name":"tutorial","title":"Tutorial","version":"1.0"}}}
{"id":1,"result":{"userAgent":"tutorial/0.144.5 (Mac OS 26.5.0; arm64) xterm-256color (tutorial; 1.0)","codexHome":"~/.codex","platformFamily":"unix","platformOs":"macos"}}
{"method":"remoteControl/status/changed","params":{"status":"disabled","serverName":"xxx.local","installationId":"2124e102-01b2-4b60-94c3-dabb22d2913f","environmentId":null}}

At this point, the server has been successfully initialized.

Next, start a conversation with an agent by sending a thread/start request:

{"id":2,"method":"thread/start","params":{}}

The response will look something like this:

{"id":2,"result":{"thread":{"id":"019f7960-95a5-7140-8749-a3cf59e0ffab","extra":null,"sessionId":"019f7960-95a5-7140-8749-a3cf59e0ffab","forkedFromId":null,"parentThreadId":null,"preview":"","ephemeral":false,"historyMode":"legacy","modelProvider":"openai","createdAt":1784447800,"updatedAt":1784447800,"recencyAt":1784447800, ...}
{"method":"thread/started","params":{"thread":{"id":"019f7960-95a5-7140-8749-a3cf59e0ffab","extra":null,"sessionId":"019f7960-95a5-7140-8749-a3cf59e0ffab", ...}
{"method":"mcpServer/startupStatus/updated","params":{"threadId":"019f7960-95a5-7140-8749-a3cf59e0ffab","name":"codex_apps","status":"starting","error":null,"failureReason":null}}
{"method":"mcpServer/startupStatus/updated","params":{"threadId":"019f7960-95a5-7140-8749-a3cf59e0ffab","name":"context7","status":"starting","error":null,"failureReason":null}}
{"method":"mcpServer/startupStatus/updated","params":{"threadId":"019f7960-95a5-7140-8749-a3cf59e0ffab","name":"notion-mcp-server","status":"starting","error":null,"failureReason":null}}
{"method":"mcpServer/startupStatus/updated","params":{"threadId":"019f7960-95a5-7140-8749-a3cf59e0ffab","name":"notion-mcp-server","status":"ready","error":null,"failureReason":null}}
{"method":"mcpServer/startupStatus/updated","params":{"threadId":"019f7960-95a5-7140-8749-a3cf59e0ffab","name":"codex_apps","status":"ready","error":null,"failureReason":null}}
{"method":"mcpServer/startupStatus/updated","params":{"threadId":"019f7960-95a5-7140-8749-a3cf59e0ffab","name":"context7","status":"ready","error":null,"failureReason":null}}

The output may look a little noisy, but you'll notice events such as thread/started, followed by the startup of MCP servers.

If you've used the codex command before, this should feel very familiar—the same initialization process is happening behind the scenes.

Next, let's send a task to the agent using turn/start.

For this example, we'll ask it to introduce itself with the following prompt:

{"id":3,"method":"turn/start","params":{"threadId":"019f7960-95a5-7140-8749-a3cf59e0ffab","input":[{"type":"text","text":"Hello! Please introduce yourself."}]}}

The response is quite long, so I'll omit most of it here. The message worth paying attention to is this one:

{
  "method": "item/completed",
  "params": {
    "item": {
      "type": "agentMessage",
      "id": "msg_0e30b319d2fc7416016a5c854b85a0819192efde569032bd15",
      "text": "Hello! I'm Codex.\n\nI can help with code investigation, implementation, testing, code reviews, Git operations, pull request preparation, and more within this workspace. My general approach is to understand the existing architecture and repository conventions before making small, safe changes.\n\nFor this repository, I'll follow your instructions and respond primarily in Japanese.",
      "phase": "final_answer",
      "memoryCitation": null
    },
    "threadId": "019f7960-95a5-7140-8749-a3cf59e0ffab",
    "turnId": "019f7968-a116-7f13-bf24-c56fddd4373d",
    "completedAtMs": 1784448333474
  }
}

The response is divided into several types of events.

The most important one is item/agentMessage/delta, which streams the agent's response in small chunks as it is generated. Once the response is complete, the full message is available in the item/completed event.

At this point, you've seen the complete interaction flow. From here on, you simply continue sending turn/start requests to assign new tasks. By repeating this process until all work is finished, you can drive the agent through an entire workflow programmatically.

Why Use Codex App Server?

When working with Codex day to day, you typically launch the interactive console with the codex command.

However, if you keep a Codex App Server running locally and send JSONL requests to it instead, you unlock a number of interesting possibilities:

Run Codex agents in headless mode.
Send tasks directly to the App Server without opening a new codex session and manually entering prompts for each task.
Build your own custom clients, such as GUIs, TUIs, or web applications.

OpenAI has also introduced Codex Symphony](https://openai.com/ja-JP/index/open-source-codex-orchestration-symphony/), a specification for orchestrating multiple coding agents. Building your own orchestration layer on top of Codex App Server would be an interesting project.

Since Codex App Server continuously emits events that reflect the agent's state, you can also monitor its progress in real time. This opens the door to building tools similar to Herdr, with features for tracking and visualizing the state of long-running agent workflows.

Tasq: An Open-Source Project I Built

As a bit of self-promotion, I'd also like to introduce Tasq, an open-source project I built on top of Codex App Server.

If you're curious about how it works, I recommend checking out the demo video in the README—it gives a good sense of the overall workflow and user experience.

Tasq is built around local issue management. Once you add implementation plans created by tools like Claude Code or Codex to your backlog, Tasq can automatically drive coding agents through the entire workflow—from implementation all the way to creating a pull request.

Thanks for reading!

If Tasq sounds interesting, I'd love for you to give it a try. Feedback, issues, and contributions are always welcome.

Queue Your Plan. Get PRs. — Tasq, a Task Queue for Coding Agents

jjoo — Tue, 14 Jul 2026 04:45:34 +0000

If you'd rather try it first than read about it, there's a demo video and a quick tutorial that walk you through the entire workflow in just a few minutes.

By the end of it, you'll have an agent:

picking up issues automatically
implementing changes in isolated worktrees
creating pull requests
updating issue states as work progresses

This article explains why I built tasq and the problems it tries to solve.

I spend most of my time building software with AI coding agents.

My workflow usually looks like this:

Use Claude Code and custom skills to explore a problem and generate a plan.
Ask Codex to implement the plan.
Let the agent create a pull request.

At first, it felt magical.

Then I started running multiple agents in parallel.

While one agent was investigating a bug, another was implementing a feature. While waiting for CI to finish, I would ask yet another agent to work on a different task.

A few days later I noticed a problem:

Which tasks are currently running?
Which tasks are blocked by dependencies?
Which tasks are already finished?
Which conversation thread belongs to which implementation?

Sometimes an agent would finish a task and I wouldn't notice for days.

Sometimes I would discover an unfinished implementation a week later and wonder why it had stopped in the first place.

AI made software development massively parallel.

But my task management workflow was still designed for humans.

That's why I built tasq.

version-1 / tasq

AI-native task orchestrator for coding agents

tasq

AI coding agent task manager.

tasq helps you turn implementation work into a visible queue, start local services for that queue, and inspect progress from both the tq CLI and the Web UI.

intro_v2.mp4

Watch the Tasq introduction video.

Japanese counterpart: README.ja.md.

Problem

AI coding agents make it possible to work on multiple implementation tasks at the same time. The bottleneck moves from writing code to managing parallel work.

Human Context Switching

Agents can run in parallel, but humans still need to track which tasks were assigned, which agents are running, how far each task has progressed, and what should be reviewed next.

Workspace Conflicts

Running multiple agents in one repository checkout can create branch switching issues, unfinished-change conflicts, and overlapping file edits.

Repeated Setup Work

Each agent task often needs the same preparation steps: create a branch, create a worktree, verify dependencies, and run the right…

View on GitHub

An AI-native task orchestrator designed for coding agents.

Why not GitHub Issues or Linear?

The obvious answer is to create more issues.

The problem is that not all tasks belong in a shared project management system.

I don't want to publish every tiny implementation detail, development experiment, or dotfiles improvement to a team-wide Linear workspace.

Many of these tasks are personal implementation notes or intermediate steps that only exist to help me finish larger work.

They also have dependencies.

For example:

Create database schema
Implement repository layer
Add API endpoints
Update frontend integration

I don't want to manually copy and paste these tasks into agents in the correct order.

I want the system to understand the dependency graph and schedule the work automatically.

What I needed was:

Run multiple agents and automatically consume tasks while respecting dependencies.

What is tasq?

tasq combines three ideas:

A local issue tracker
A dependency-aware task queue
An orchestrator for coding agents

Issues are stored locally in a database rather than in GitHub or Linear.

The orchestrator continuously watches the queue and dispatches executable tasks to coding agents.

Each task runs in its own Git worktree and branch, so multiple implementations can happen in parallel without conflicts.

tasq was heavily inspired by Codex Symphony and its orchestration model, while focusing on local-first and personal workflows.

Workflow Customization

The default implementation loop looks like this:

Create a worktree and branch.
Move the issue to in_progress.
Implement the requested changes.
Run agent-based review.
Create a pull request.

However, these steps are not hardcoded.

tasq uses WORKFLOW.md files inspired by Symphony's workflow specification.

This means users can customize:

review strategies
branching models
required checks
skill selection
pull request behavior

tasq only cares about:

issue dependencies
issue states
orchestration

Everything else belongs to the user.

Autonomous agents still need humans

In an ideal world, agents would continuously fetch tasks and finish them without interruption.

Reality is messier.

Agents may require permissions.

CI pipelines fail.

Implementations sometimes diverge from expectations.

For these situations, tasq intentionally stays lightweight.

Each issue stores the execution session identifier of the underlying coding agent.

If something goes wrong, you can simply continue from the existing session:

codex resume <thread_id>

You don't need to create another issue just to fix CI failures or tweak a generated implementation.

You simply resume the conversation and continue from where the agent stopped.

Typical Workflow

A typical tasq workflow looks like this:

Create a plan using Claude Code, Codex, or your preferred tools.
Convert the plan into issues with tq issue create.
Review the generated issues and mark them as ready.
Let the orchestrator dispatch work automatically.
Review the generated pull requests.

In practice, this often means your work becomes:

Review issues and move them to ready.

Everything else happens automatically.

tasq provides both a web interface and a CLI interface.

The CLI is primarily intended for coding agents, while the web interface focuses on issue management and orchestration visibility.

There is also a dedicated tasq skill package for coding agents so they can interact with the issue tracker without additional prompting.

What's Next?

There is still a lot to improve.

Current ideas include:

TUI support
Seamless recovery of blocked tasks
Better onboarding and startup configuration
Claude Code integration

I personally spend most of my time inside tmux and Vim, so a TUI feels inevitable.

I also want blocked tasks to recover automatically whenever possible.

For example, if CI fails, users shouldn't need to manually resume an agent and type:

fix ci

Finally, tasq currently depends on Codex App Server and does not yet support direct execution through Claude Code.

Long term, I would like planning and implementation workflows to work seamlessly across both ecosystems.

If any of this sounds interesting, I'd love for you to try the tutorial and share your feedback.

Tasq Document Site

Implementing Ruby's methods Method in JavaScript

jjoo — Tue, 30 Jul 2024 10:40:43 +0000

Suddenly, isn't Ruby's methods method handy? When writing code, it lists all the methods and properties available for an object and allows you to search through them, which is very useful for debugging.

Besides that, it is also effective for checking methods specific to frameworks like Rails, aiding in code reading and understanding libraries. While it's good practice to refer to official documentation or source code, the methods method is quite helpful for libraries where you don’t need to dive deeply or when you have vague memories of method names.

Ruby's `methods` Method

To briefly introduce Ruby's methods method, it looks like this:

Object#method

Returns a list of the names of public and protected methods of obj. This will include all the methods accessible in obj’s ancestors. If the optional parameter is false, it returns an array of obj’s public and protected singleton methods, the array will not include methods in modules included in obj.

In other words, it returns an array object of the properties and methods accessible from the receiver.

This method is implemented in the Object class, which is the ancestor of all classes that inherit from Object, so it can be used in any class inheriting from Object.

Sample Code

class Hoge
  attr_accessor :fuga

  def bar
    puts ''
  end
end

puts Hoge.new.methods     // => [:bar, :fuga=, :fuga, :hash, :singleton_class, :dup, ...]
puts Hoge.new.grep /fuga/ // => [:fuga=, :fuga]

As shown in the example, it returns an Array object, so you can also search through the list of methods using the grep method, which is very convenient.

So, I thought about whether this could be done in JS and gave it a try.

Implementation

Below is the actual code.

The class name can be anything, but I’m naming it PropertyFinder for now.

class PropertyFinder {
    constructor(receiver) {
      this.receiver = receiver
    }

    grep(regexp, options = {}) {
      let res = []
      if (typeof regexp === 'string') {
        return this.find((name) => name.includes(regexp))
      }
      if (regexp instanceof RegExp) {
        return this.find((name) => regexp.test(name))
      }
      return []
    }

    toString() {
      return this.find(() => true)
    }

    find(detect) {
      const list = Object.getOwnPropertyNames(this.receiver).filter(it => detect(it))
      if (!this.receiver.__proto__) {
        return list
      }
      const ancestors = new PropertyFinder(this.receiver.__proto__).find(detect)
      return [...list, ...ancestors]
    }
}

I’ll explain the code later, but let’s start with how to use it.

Once the class is defined, you can add a method to the Object class's properties as follows:

Object.prototype.methods = function () {
    return new PropertyFinder(this)
}

By doing this, you can use the methods method on instances of classes inheriting from Object. However, please be aware of the caution note below and use this at your own risk.

Here are some example executions:


class Hoge {
  fuga() {
    console.log('fuga')
  }
}

console.log(new Object().methods().toString()) // => ['constructor', 'constructor', '__defineGetter__', '__defineSetter__', 'hasOwnProperty' ...]
console.log([].methods().toString())           // => ['length', 'length', 'constructor', 'at', 'concat', ...]
console.log(new Hoge().methods().grep(/fuga/)  // => ['fuga']

Safety Introduction

*This code is not recommended for use in production environments *

Adding properties to higher-level classes through monkey-patching is an anti-pattern and could lead to problems with future changes in JS specifications. Use it with caution and at your own risk.

Reference : The cons of monkey patching

Code Explanation

Now, let's move on to explaining the code.

The most important method in PropertyFinder is the find method. This method traverses the prototype chain of the given object, searches for accessible properties, and returns them as a list.

The toString and grep methods simply use find, so they don't need further explanation.

Prototype Chain

The prototype chain might be unfamiliar to some, but it’s the inheritance of properties from the Object class.

Inheritance and the prototype chain | MDN

The details are covered in the MDN documentation, but JavaScript's inheritance mechanism is supported by the prototype chain.

Although it's not always obvious, when referring to some property, the process involves:

Checking if the receiver itself has the property.
Checking if the parent class instance has the property.
Checking if the property exists in the parent class’s instance's parent class.

This process continues up the chain until a match is found, which is then returned.

What the `find` Method Does

Given the above, the find method in PropertyFinder implements this mechanism, allowing you to get a list of properties by recursively exploring __proto__.

Here's the implementation that achieves this by exploring __proto__ recursively to get the list:

    find(detect) {
      const list = Object.getOwnPropertyNames(this.receiver).filter(it => detect(it))
      if (!this.receiver.__proto__) {
        return list
      }
      const ancestors = new PropertyFinder(this.receiver.__proto__).find(detect)
      return [...list, ...ancestors]
    }

That concludes the explanation of PropertyFinder.

Wrap up

That wraps up the explanation of the code and what I’ve tried.

This was more of an experimental or playful exercise, but since it involved some knowledge and techniques, I hope you find it useful or inspiring for your own applications.

Tried to Create Crud API Gin+Gorm+GraphQL(gqlgen)

jjoo — Sat, 02 Jan 2021 01:46:59 +0000

I usually develop backend with Ruby on Rails so I'm not familier with golang but I have studied it and created a GraphQL API with Gin + Gorm + GraphQL.

I will explain about entire flow. Next, I will talk about stack point I was working in.

This is the repository.
gin-gorm-gqlgen-sample

Technologies I used

Followings are technologies I used this time,

Docker
Dep (package manager)
Gin (WAF)
Gorm (ORM)
gqlgen (GraphQL Library)

Gin

Gin is one of the Go language WAF. It have got the most star on github in go lang WAF(as far as I know).

Gorm

Gorm is Go Lang ORM. According to web articles, its interface is like Rails's ActiveRecord.
I am familliar with Rails so I choose this library.

Dep

Dep is pacakge manager. I need to "go get" to install some libraries but it seems like disturbing my Dockerfile.
So I used dep

gqlgen

gqlgen is GraphQL server library. There are some graphql libraries for golang such as graphql-go/graphql.
But I selected gqlgen becuase I really like a point of generating code after I defined schema.

99designs/gqlgen

If you use gqlgen, you can proceed your development with following procedure.

Define Schema
Write logic about query in resolvers

In this process, you can focus on writing logic and you don't need to write boring code because gqlgen genearate code based on your schema.

Entire Flow

The gqlgen sample in the document is baout Todo List. If you will read "Getting Start", you start it easily.
But, I need to do something when you use it with Gorm or you develop CRUD. So, I will explain those way, So, I will explain those way.

Install gqlgen with dep

You can install gqlgen by "go get" but if you use dep, you have to prepare wrapper scripts to generate boilerplate.

scripts/gqlgen.go

package main

import "github.com/99designs/gqlgen/cmd"

func main() {
    cmd.Execute()
}

If you do this,

$go run scripts/gqlgen.go init

you will be able to execute it like this.
When you finished to write scripts, make files you need on gqlgen.

$go run scripts/gqlgen.go init

Gqlgen will generate followings files.

gqlgen.yml ・・・ Configure file. you write the configure fo generated code.
genereated.go ・・・ When you define schema and execute scripts, this file will be generatted. Must not edit manually because it is generated.
models_gen.go ・・・ This file is also generated from schema. Must not edit manually because it is generated.
resolver.go ・・・ This is generated if you yet to create this name file.
server/server.go ・・・ Entrypoint.

When you generate code, excecute following command and install pacakges.

dep ensure

Create Entry Point for Gin

I have to prepare entry point for gin if you want to use gin.
prepare two endpoints.( for playground and main)

import (
  "github.com/99designs/gqlgen/handler"
  "github.com/gin-gonic/gin"
)

// Defining the Graphql handler
func graphqlHandler() gin.HandlerFunc {
  h := handler.GraphQL(NewExecutableSchema(Config{Resolvers: &Resolver{}}))

  return func(c *gin.Context) {
    h.ServeHTTP(c.Writer, c.Request)
  }
}

// Defining the Playground handler
func playgroundHandler() gin.HandlerFunc {
  h := handler.Playground("GraphQL", "/query")

  return func(c *gin.Context) {
    h.ServeHTTP(c.Writer, c.Request)
  }
}

func main() {
  // Setting up Gin
  r := gin.Default()
  r.POST("/query", graphqlHandler())
  r.GET("/", playgroundHandler())
    r.Run()
}

Prepare Gorm Model

Next, I will define model which are used on schema definition.
I put it on internal/models according to go language standard layout.

// user.go
package models

import (
    "time"
)

type User struct {
    ID        int
    Name      string
    Todos     []Todo
    CreatedAt time.Time
    UpdatedAt time.Time
}

// todo.go
package models

import (
    "time"
)

type Todo struct {
    ID        int
    Text      string
    Done      bool
    UserID    int
    User      User
    CreatedAt time.Time
    UpdatedAt time.Time
}

Certainly I think it is preferd to wirte it with embed (please refer to Gorm documents)
but errors occur when I excecuted. I wrote all attributes..(I would like to know better way..)

// todo.go
package models

import (
    "time"
)

type Todo struct {
  gorm.Model
    Text      string
    Done      bool
    UserID    int
    User      User
}

If you finish to define your model, you have to wirte mapping of model in gqlgen.yml.
Followings is definition in this case.

models:
  Todo:
    model: gin_graphql/internal/models.Todo
  User:
    model: gin_graphql/internal/models.User

Define Schema

What I introduced until now is to prepare to develop in schema drriven, I'll to write the code and logic for api from now.

type Todo {
  id:   Int!
  text: String!
  done: Boolean!
  userID: Int!
  user: User!
  createdAt: Time!
  updatedAt: Time!
}

type User {
  id: Int!
  name: String!
  createdAt: Time!
  updatedAt: Time!
}

type Query {
  todos: [Todo!]!
  users: [User!]!
  todo(input: FetchTodo): Todo!
}

input NewTodo {
  text: String!
  userId: Int!
}

input EditTodo {
  id: Int!
  text: String!
}

input NewUser {
  name: String!
}

input FetchTodo {
  id: Int!
}

type Mutation {
  createTodo(input: NewTodo!): Todo!
  updateTodo(input: EditTodo!): Todo!
  deleteTodo(input: Int!): Todo!
  createUser(input: NewUser!): User!
}

scalar Time

Above is schema.graphql to realize CRUD. You have to use graphql syntax to write this.
Processes to change resouce is wrriten in Mutations and Processes to read it is wrriten in Query.
And Types you need is also defined in schema.graphql.

Until now, you got reday to generate code and you start to edit resolver.In resolver, IO is defined by schema.graphql and it is generated automatically.
So you focus on writing logic between input and output.

Implemntaion Resolver

In resolver, write code to get data from database or create some records.
You have to know that resolver is not overwritten when it is already exist.

Following is resolver I wrote. I can't explain all because it is about gorm and bored for us.


type Resolver struct {
}

func (r *Resolver) Mutation() MutationResolver {
    return &mutationResolver{r}
}
func (r *Resolver) Query() QueryResolver {
    return &queryResolver{r}
}

type mutationResolver struct{ *Resolver }

func (r *mutationResolver) CreateUser(ctx context.Context, input NewUser) (*models.User, error) {
    user := models.User{
        Name: input.Name,
    }
    db.Create(&user)
    return &user, nil
}

func (r *mutationResolver) CreateTodo(ctx context.Context, input NewTodo) (*models.Todo, error) {
    todo := models.Todo{
        Text:   input.Text,
        UserID: input.UserID,
        Done:   false,
    }
    db.Create(&todo)
    return &todo, nil
}

func (r *mutationResolver) UpdateTodo(ctx context.Context, input EditTodo) (*models.Todo, error) {
    todo := models.Todo{ID: input.ID}
    db.First(&todo)
    todo.Text = input.Text
    db.Model(&models.Todo{}).Update(&todo)

    return &todo, nil
}

func (r *mutationResolver) DeleteTodo(ctx context.Context, input int) (*models.Todo, error) {
    todo := models.Todo{
        ID: input,
    }
    db.First(&todo)
    db.Delete(&todo)
    return &todo, nil
}

type queryResolver struct{ *Resolver }

func (r *queryResolver) Todo(ctx context.Context, input *FetchTodo) (*models.Todo, error) {
    var todo models.Todo
    db.Preload("User").First(&todo, input.ID)
    return &todo, nil
}

func (r *queryResolver) Todos(ctx context.Context) ([]models.Todo, error) {
    var todos []models.Todo
    db.Preload("User").Find(&todos)
    fmt.Println(todos[0].User)
    return todos, nil
}

func (r *queryResolver) Users(ctx context.Context) ([]models.User, error) {
    var users []models.User
    db.Find(&users)
    return users, nil
}

Run

Finally, you can run your code if you finish process I introduced.
The entrypoint of the repositry I prepared is cmd/app/main.go so you can run following command.

ENV=development go run cmd/app/main.go

We should pass env in this command because I implemented it to load configuration by env.
When you success to run the server, you can try it on http://localhost:8080.

Stack Points

Next, I will write about points I stacked while I was building.

How can I define type of Time like CreatedAt and Updated?

Schema Types are only 5.

ID
Int
Float
String
Boolean

So we have to define types we need such as Date.

When I create this sample, I'm stack here but I found gqlgen provide Time Type so I can use it.

You only do like this as above schema definition.

scalar Time

After you declare the type, the type is mapped to Go Embeded tim.Time Type.
Gqlgen support Map, Upload and Any type so if you want to use their type, only declare it with scalar declaration.

Error Occured in Gorm Model while I generate code.

This problem is not resolved. I got away with it by workaround though..
I defined a model with gorm embed type but error occured during generation...

type User {
  gorm.Model
  name
}

I got away with writing all attributes but it is not good.
If anyone know better way, I would like to teach me.

Get association model while I get list

This is about not GraphQL but Gorm. I often get list which include associated model so I tried it in this sample, too.
That is simpler than I expeceted. All you need is to add fields to struct.

type Todo {
  id:   Int!
  text: String!
  done: Boolean!
  userID: Int!
  user: User!
  createdAt: Time!
  updatedAt: Time!
}

For example, when you define Todo model, you can do that by adding userId and user fields to Todo model.

db.Preload("User").Find(&todo, input.ID)

And add this line to resolver.

You already write preload clasue so you already solved N+1 problem.
This is sql when I execute.You can make sure that users query is preloaded.

(/app/src/gin_graphql/resolver.go:65)
[2019-05-14 15:27:07]  [0.90ms]  SELECT * FROM `todos`  WHERE (`todos`.`id` = 2) ORDER BY `todos`.`id` ASC LIMIT 1
[1 rows affected or returned ]

(/app/src/gin_graphql/resolver.go:65)
[2019-05-14 15:27:07]  [2.65ms]  SELECT * FROM `users`  WHERE (`id` IN (1)) ORDER BY `users`.`id` ASC
[1 rows affected or returned ]

Wrrap Up

I tryied to build hot stacks of Web API and Graphql.

I currently feel the limit of REST API while I develop system with it so I feel stronger the good points of graphql.
In REST API, When I create new endpoint, I have to write code to request that endpoint in client-side.

In GraphQL, if you define schema once, you can fetch necessary resouce anytime.
When I develop api in REST, I think how I don't depned on frontend but I often need to change code of server-side code when the front is changed.

I think such problems will be solved by GraphQL (many people say so though..)
Certainly, I learn it deeply and I would know that drawbacks and I can never know that now but I can feel that potential.

If you are familiar with REST or are sick of creating Web API, try GraphQL

Thank you,