gRPCでのエラーに関してgolangではどう向き合うべきなのか知るべくひとまず知識をまとめた。

golangでのerrorハンドリング

golangではerrorをどのように取扱うのがよりよいのかというのがしばしば話題になることがある。
golang自体がシンプルなゆえに、考慮することが多い。

• エラーの種類
• stack trace
• メッセージ
• ステータス
• errorの伝搬

標準パッケージだけでは難しいことも多いため、errorsなども利用して行うことが多い。(Error handling in Upspin)

grpcのgolangでのerrorハンドリング

自分はgolangを使ったmicro serviceの開発をしていることもあり、grpcでのエラーに関してどう向き合うべきなのか知る
べく知識をまとめた。

gRPCのエラーのまとめ

サーバー、クライアントでのerror handlingの例としてはavinassh/grpc-errorsが参考になる。
protoを利用してる前提なのでerror modelも参考になる。

gRPCのエラーはGoogle APIのエラーモデルの設計に基づきエラーコード、ステータス、詳細情報が返される。
google.rpc.Status

1
2
3
4
5
6

package google.rpc;
message Status {
    int32 code = 1;
    string message = 2;
    repeated google.protobuf.Any details = 3;
}

status codeはgoogle/rpc/code.protoにあるとおりで、このステータスはHTTP Status Codeとの整合性を保つことができるようになっている。

https://cloud.google.com/apis/design/errors#handling_errors

こうすることでクライアントとはhttpで、micro serviceとはgrpcでメッセージングしているサービスの場合においても
整合性を保ったままエラーの設計ができる。

gRPC client

status、codesパッケージを使うことで

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

import (
"google.golang.org/grpc/codes"
"google.golang.org/grpc/status"
)

st, ok := status.FromError(err)
if !ok {
log.Printf("Unknown Error: %+v\n", err)
// return unknown error
}
responseWriter := &httptest.ResponseRecorder{}
switch st.Code() {
case codes.NotFound:
log.Printf("Error NotFound %+v\n", err)
responseWriter.WriteHeader(http.StatusNotFound)
case codes.PermissionDenied:
log.Printf("Error PermissionDenied %+v\n", err)
responseWriter.WriteHeader(http.StatusForbidden)
default:
log.Printf("Error Internal %+v\n", err)
responseWriter.WriteHeader(http.StatusInternalServerError)
}

gRPC server

またgrpcサーバーの実装としてはgoogleapis/rpc/errdetailsを使うことでエラー詳細を含めたエラーを生成することが容易にできる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import (
    "google.golang.org/grpc/status"
    "google.golang.org/genproto/googleapis/rpc/errdetails"
)

st := status.New(codes.InvalidArgument, "some error message")
// add error message detail
st, err := st.WithDetails(
&errdetails.BadRequest{
FieldViolations: []*errdetails.BadRequest_FieldViolation{
&errdetails.BadRequest_FieldViolation{
Field:       "Message",
Description: "error detail",
},
},
},
&errdetails.LocalizedMessage{
Locale:  "ja",
Message: "エラー詳細",
},
)
// unexpected error
if err != nil {
panic(fmt.Sprintf("Unexpected error: %+v", err))
}
// return error
return nil, st.Err()

Parse error detail

またこの詳細メッセージはclient側ではstatus.Detailsを使うことで取り出すことができる。

1
2
3
4
5
6
7
8
9
10
11

for _, detail := range st.Details() {
switch t := detail.(type) {
case *errdetails.BadRequest:
for _, violation := range t.GetFieldViolations() {
log.Printf("The %q field was wrong:\n", violation.GetField())
log.Printf("\t%s\n", violation.GetDescription())
}
case *errdetails.LocalizedMessage:
log.Printf("%s:%s", t.GetLocale(), string(t.GetMessage()))
}
}

参考にしたページ

Google API Error
Error Handling

とてもシンプルなclientの利用事例は以下のようになる。

1
2
3
4
5
6
7
8
9
10

package main

import (
"net/http"
)

func main() {
client := &http.Client{}
resp, err := client.Get("https://example.com")
}

ますは前回と同じくcallstackを見てみる。

http client callstack

1
2
3
4
5

// net/http/client.go
type Client struct {
    ...
    Transport RoundTripper
    ...

Client構造体のコードコメントを見ると以下のようにあり

1
2
3

Transport specifies the mechanism by which individual
HTTP requests are made.
If nil, DefaultTransport is used.

どのメカニズムでtransportするのかはTransportの実装できまる。
nilの場合はデフォルトでHTTPが使われる。つまりhttp以外で会話するclientを作成する際も
このtransportをサポートしていれば良いってこと。
実際はhttp clientのtransportがRoundTripperなので、別のプロトコルの場合はこのRoundTripperを実装することになるのかな。

話は少しそれるがTransport構造体もざっとみてみると

• Transportは将来の再利用のために接続をキャッシュする
  • CloseIdleConnectionsで管理する
  • MaxConnsPerHostで設定可能
• Transportはgorutineで再利用可能(スレッドセーフ)
• HTTP URLがHTTP1.1または2を使う
  • HTTP2をサポートしてる
• ネットワークエラーのときのみ再接続
• Proxyで特定のURLに対してhttp(s), socketでのproxyができる
• そのほかTCP dialやkeep-aliveもここで扱かわれる

1
2
3

type RoundTripper interface {
    RoundTrip(*Request) (*Response, error)
}

RoundTripperのiterfaceからRoundTrip関数を持ち、実際にこのRoundTripでサーバーとの会話を行う。

続いて実際にRequestを行っている処理を見てみる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

func (c *Client) Get(url string) (resp *Response, err error) {
req, err := NewRequest("GET", url, nil)
if err != nil {
return nil, err
}
return c.Do(req)
}

...

func (c *Client) Do(req *Request) (*Response, error) {
return c.do(req)
}

...

func (c *Client) do(req *Request) (retres *Response, reterr error) {
    ...

for {
        ...

reqs = append(reqs, req)
var err error
var didTimeout func() bool
if resp, didTimeout, err = c.send(req, deadline); err != nil {
// c.send() always closes req.Body
reqBodyClosed = true
if !deadline.IsZero() && didTimeout() {
err = &httpError{
// TODO: early in cycle: s/Client.Timeout exceeded/timeout or context cancelation/
err:     err.Error() + " (Client.Timeout exceeded while awaiting headers)",
timeout: true,
}
}
return nil, uerr(err)
        }

        ...
}
}

func (c *Client) send(req *Request, deadline time.Time) (resp *Response, didTimeout func() bool, err error) {
if c.Jar != nil {
for _, cookie := range c.Jar.Cookies(req.URL) {
req.AddCookie(cookie)
}
}
resp, didTimeout, err = send(req, c.transport(), deadline)
if err != nil {
return nil, didTimeout, err
}
if c.Jar != nil {
if rc := resp.Cookies(); len(rc) > 0 {
c.Jar.SetCookies(req.URL, rc)
}
}
return resp, nil, nil
}


// send issues an HTTP request.
// Caller should close resp.Body when done reading from it.
func send(ireq *Request, rt RoundTripper, deadline time.Time) (resp *Response, didTimeout func() bool, err error) {
req := ireq // req is either the original request, or a modified fork

    ...

resp, err = rt.RoundTrip(req)

    ...

return resp, nil, nil
}

ということで、最終的にRoundTripperのRoundTripをcallすることになる。

これからclientのmiddlewearはRoundTripを実装するRoundTripperであれば良い。

ちなみにTransportのRoundtripの実装を見ると

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// roundTrip implements a RoundTripper over HTTP.
func (t *Transport) roundTrip(req *Request) (*Response, error) {
...
// Get the cached or newly-created connection to either the
// host (for http or https), the http proxy, or the http proxy
// pre-CONNECTed to https server. In any case, we'll be ready
// to send it requests.
pconn, err := t.getConn(treq, cm)
if err != nil {
t.setReqCanceler(req, nil)
req.closeBody()
return nil, err
}

var resp *Response
if pconn.alt != nil {
// HTTP/2 path.
t.decHostConnCount(cm.key()) // don't count cached http2 conns toward conns per host
t.setReqCanceler(req, nil)   // not cancelable with CancelRequest
resp, err = pconn.alt.RoundTrip(req)
} else {
resp, err = pconn.roundTrip(treq)
}
...
}

optionのroundTripperであるpconn.altがある場合はhttp2などが利用される。
またgetConnをみると既にidleなconnectionがある場合はそちらを利用する設計なのがわかる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// getConn dials and creates a new persistConn to the target as
// specified in the connectMethod. This includes doing a proxy CONNECT
// and/or setting up TLS.  If this doesn't return an error, the persistConn
// is ready to write requests to.
func (t *Transport) getConn(treq *transportRequest, cm connectMethod) (*persistConn, error) {
...
if pc, idleSince := t.getIdleConn(cm); pc != nil {
if trace != nil && trace.GotConn != nil {
trace.GotConn(pc.gotIdleConnTrace(idleSince))
}
// set request canceler to some non-nil function so we
// can detect whether it was cleared between now and when
// we enter roundTrip
t.setReqCanceler(req, func(error) {})
return pc, nil
}

...

go func() {
pc, err := t.dialConn(ctx, cm)
dialc <- dialRes{pc, err}
}()

idleConnCh := t.getIdleConnCh(cm)
...
}

middlewearの実装

ここまでの結果から実際の具体的な実装をしていく。
middlewearはhttp.RoundTripperをオプションにとりhttp.RoundTripperを返す関数であればよい。
またhttp.Serrverのmiddlewearを実装下のrと同じく、clientのmiddlewear関数もhttp.Requestを受け、http.Responseを返す関数をオプションとする関数を返す必要がある。

1
2
3
4
5

func adapter(next http.RoundTripper) http.RoundTripper {
return RoundTripperFunc(func(r *http.Request) (*http.Response, error) {
return next.RoundTrip(r)
})
}

またこれらの関数をClient構造体のTransportメンバーに渡せるようにする関数を作成する必要がある。

1
2
3
4
5
6
7
8
9

func useAdapters(adapters ...adapter) adapter {
return func(final http.RoundTripper) http.RoundTripper {
fn := final
for i := len(adapters) - 1; i >= 0; i-- {
fn = adapters[i](fn)
}
return fn
}
}

のようにすることでhttp.clientのmiddlewearでmiddlewearを利用できるようになる。
この実装を見ても、serverのmiddlewearと同じ実装出ることがわかる。

実際のコードは以下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

package main

import (
"fmt"
"net/http"
)

type adapter func(http.RoundTripper) http.RoundTripper
type RoundTripperFunc func(*http.Request) (*http.Response, error)

func (f RoundTripperFunc) RoundTrip(r *http.Request) (res *http.Response, err error) {
return f(r)
}

func adapterA(next http.RoundTripper) http.RoundTripper {
return RoundTripperFunc(func(r *http.Request) (*http.Response, error) {
fmt.Println("Executing adapterA before adapter")
res, err := next.RoundTrip(r)
fmt.Println("Executing adapterA after adapter")

return res, err
})
}

func adapterB(next http.RoundTripper) http.RoundTripper {
return RoundTripperFunc(func(r *http.Request) (*http.Response, error) {
fmt.Println("Executing adapterB before adapter")
res, err := next.RoundTrip(r)
fmt.Println("Executing adapterB after adapter")
return res, err
})
}

func useAdapters(adapters ...adapter) adapter {
return func(final http.RoundTripper) http.RoundTripper {
fn := final
for i := len(adapters) - 1; i >= 0; i-- {
fn = adapters[i](fn)
}
return fn
}
}

func main() {
adapters := useAdapters(adapterA, adapterB)
client := &http.Client{
Transport: adapters(http.DefaultTransport),
}
resp, err := client.Get("https://example.com")
fmt.Println("RES: %s, Log: %s", resp, err)
}

まとめ

golangのhttp server, clientともに同じ設計でmiddleweaerの実装があ可能な設計が取られており、
またclientはtransporterの実装によりプロトコルを変更・拡張することができる。
柔軟な設計はgolangでアプリケーションを作成するにあたっても良い手本となりそう。

今回はHTTPサーバーおよびHTTPクライアントを読んでみた。
結果として、標準パッケージのみで比較的容易に実装できる。
これはgolangの柔軟な言語仕様なんだろう。
golangらしいコーディングの勉強にもなりました。

http server callstack

およそ一般的なechoサーバーの実装は以下のような感じと思われる

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package main

import (
  "fmt"
  "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
  fmt.Fprintf(w, "Hello, World")
}

func main() {
  http.HandleFunc("/", handler)
  http.ListenAndServe(":3000", nil)
}

callstackを見ていくと

1
2
3

func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
DefaultServeMux.HandleFunc(pattern, handler)
}

patternに適合したhandlerを登録する。DefaultServeMuxで初期設定で提供されている。
ちなみにServeMuxはhttpマルチプレクサになる。

また、コードコメントに以下のようにある

1
2
3
4
5
6

Longer patterns take precedence over shorter ones, so that
if there are handlers registered for both "/images/"
and "/images/thumbnails/", the latter handler will be
called for paths beginning "/images/thumbnails/" and the
former will receive requests for any other paths in the
"/images/" subtree.

パスのパターンマッチはより長いパターンのほうが短いパターンより優先されるとのこと。
さらにhandler optionは

1

handler func(ResponseWriter, *Request)

ここからわかるようにhandlerはrequest writerとresponseの参照をオプションとする関数である。
これを満たせばよい。

1
2
3
4
5
6

func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
if handler == nil {
panic("http: nil handler")
}
mux.Handle(pattern, HandlerFunc(handler))
}

HandleFuncはServeMuxのHandleをcallすることになる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

type ServeMux struct {
mu    sync.RWMutex
m     map[string]muxEntry
es    []muxEntry // slice of entries sorted from longest to shortest.
hosts bool       // whether any patterns contain hostnames
}

func (mux *ServeMux) Handle(pattern string, handler Handler) {
    ...

    e := muxEntry{h: handler, pattern: pattern}
mux.m[pattern] = e
if pattern[len(pattern)-1] == '/' {
mux.es = appendSorted(mux.es, e)
}

    ...
}

pathにマッチしているhandlerを登録している。

次はこのhandlerを呼び出すところ。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

// net/http/server.go

func ListenAndServe(addr string, handler Handler) error {
server := &Server{Addr: addr, Handler: handler}
return server.ListenAndServe()
}

...

func (srv *Server) ListenAndServe() error {
if srv.shuttingDown() {
return ErrServerClosed
}
addr := srv.Addr
if addr == "" {
addr = ":http"
}
ln, err := net.Listen("tcp", addr)
if err != nil {
return err
}
return srv.Serve(tcpKeepAliveListener{ln.(*net.TCPListener)})
}

...

func (srv *Server) Serve(l net.Listener) error {
    ...

for {
        ...

        c := srv.newConn(rw)
c.setState(c.rwc, StateNew) // before Serve can return
go c.serve(ctx)
}
}

...

func (c *conn) serve(ctx context.Context) {
    ...

// HTTP cannot have multiple simultaneous active requests.[*]
// Until the server replies to this request, it can't read another,
// so we might as well run the handler in this goroutine.
// [*] Not strictly true: HTTP pipelining. We could let them all process
// in parallel even if their responses need to be serialized.
// But we're not going to implement HTTP pipelining because it
// was never deployed in the wild and the answer is HTTP/2.
    serverHandler{c.server}.ServeHTTP(w, w.req)

    ...

}

...

func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) {
handler := sh.srv.Handler
if handler == nil {
handler = DefaultServeMux
}
if req.RequestURI == "*" && req.Method == "OPTIONS" {
handler = globalOptionsHandler{}
}
handler.ServeHTTP(rw, req)
}

最終的にhandlerはServeHTTPをcallする形になる。

そしてこのhanderは以下のinterfaceを持っている。

1
2
3

type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}

これから作成するmiddlewearはこのインターフェイスを満たす関数である必要がある。

1

Except for reading the body, handlers should not modify the provided Request.

middlewear自体の内部実装の注意点としては、
公式のコメントにある通りでRequestBodyをあくまでReadするだけで変更してはならない。

またServerにはHandleとHandleFuncが実装されており、HandleFuncをつかうことでハンドラ関数を登録できることわかる。

1
2
3
4

func Handle(pattern string, handler Handler) { DefaultServeMux.Handle(pattern, handler) }
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
DefaultServeMux.HandleFunc(pattern, handler)
}

このHandleFuncのServerHTTPは以下のような実装である

1
2
3
4
5
6

type HandlerFunc func(ResponseWriter, *Request)

// ServeHTTP calls f(w, r).
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
f(w, r)
}

HandlerFuncをcallする関数になっている。

middlewearを実装

ここまで見てきた通りmiddlewearはhandlerで実装されるように設計していくことで、あとは既存の機構で適宜処理される。
またmiddlewerはアプリケーションの処理の前後にmiddlewearの処理挟むため、イメージ的に

[request] –> [middlewear] –> [another middlewear] –>
… –> [final] –> [middlewear] –> [another middlewear] –> … –> [response]

という動作が期待される

具体的には以下のような感じになってほしいものである。

1

http.Handle("/", middleware1(middleware2(... (finalHandler) ...))

引数として受けた次のmiddlewareを呼び出す前後に何らかの操作を実行し。
新しいmiddleware1を返す関数でmiddlewearを実装する必要がある。

各middleware関数は実装としては以下の形であればよい

1
2
3
4
5

func middleware(next http.HandlerFunc) http.HandlerFunc {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
next.ServeHTTP(w, r)
})
}

HandlerFuncをオプションにとり、HandlerFuncを返す関数である。

http.HandlerFuncはinterfaceからServeHTTPを実装しているので最終的にそれをcallする。
あとはmiddlewearを複数登録できるようにラッパー関数を作成していく。

ということで実装してみる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// add type for middlewear
type middleware func(http.HandlerFunc) http.HandlerFunc

// add middlewear function
func useMiddlewears(middlewares ...middleware) middleware {
    // final handler register function
return func(final http.HandlerFunc) http.HandlerFunc {
        // Pass the previous function as an argument
return func(w http.ResponseWriter, req *http.Request) {
fn := final
for i := len(middlewares) - 1; i >= 0; i-- {
fn = middlewares[i](fn)
            }
fn(w, req)
}
}
}

上記のようにmniddlewearというタイプを作成し、middlewearを登録するラッパー関数を作成する。
今回は最終的にリクエストを処理する関数を別途登録するデザインとなっている。
またリスト内のfinal handlerから順番に登録した順番と逆順で直前の関数に渡すようにすることで、

1

http.Handle("/", middleware1(middleware2(... (finalHandler) ...))

このパターンを実現できる。
最終的に以下のようになった。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

package main

import (
"log"
"net/http"
)

type middleware func(http.HandlerFunc) http.HandlerFunc

func middlewareA(next http.HandlerFunc) http.HandlerFunc {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
log.Println("Executing middlewareA before handler")
next.ServeHTTP(w, r)
log.Println("Executing middlewareA after handler")
})
}

func middlewareB(next http.HandlerFunc) http.HandlerFunc {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
log.Println("Executing middlewareB before handler")
next.ServeHTTP(w, r)
log.Println("Executing middlewareB after handler")
})
}

func finalHandler(w http.ResponseWriter, r *http.Request) {
log.Println("Executing finalHandler")
w.Write([]byte("Done"))
}

func useMiddlewears(middlewares ...middleware) middleware {
return func(final http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, req *http.Request) {
fn := final
for i := len(middlewares) - 1; i >= 0; i-- {
fn = middlewares[i](fn)
}
fn(w, req)
}
}
}

func main() {
middlewears := useMiddlewears(middlewareA, middlewareB)
http.HandleFunc("/", middlewears(finalHandler))
http.ListenAndServe(":3000", middlewears(finalHandler))
}

1
2
3
4
5
6
7
8
9

$ go run main.go
// $ curl http://localhost:3000/
DONE

2019/05/02 19:03:56 Executing middlewareA before handler
2019/05/02 19:03:56 Executing middlewareB before handler
2019/05/02 19:03:56 Executing finalHandler
2019/05/02 19:03:56 Executing middlewareB after handler
2019/05/02 19:03:56 Executing middlewareA after handler

ということで期待通りの実装ができた。

まとめ

1
2
3
4
5
6
7
8
9

type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}
...
type HandlerFunc func(ResponseWriter, *Request)

func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
f(w, r)
}

http.Handlerが以下のinterfaceに依存しており、
ServeHTTPの実装がhandlerを呼ぶ形になっている。
この実装のため非常に効果的にmiddlewearを作成することができる。

このあたりがgolangは柔軟に設計されていて,interfaceにのみ依存したkたちで
実際の実装をしていく感じを体験できるものだと思う。
次はhttp.Clientでも同じように見ていければ。

TypescriptCompiler APIを利用することでASTの解析および変更が可能。
独自の型解析機構や構文生成機構を作成できる。例えば、TSからJSへの変更の際に独自に必要な負荷情報を追加・編集してコンパイルすることが可能になる。
ちなみにASTの情報はAST Exploerで確認ができるため、開発の際にはこれを参考にする。

簡単なtransformコンパイラを作成して見ていく。

Config parser

まずはtypescriptのconfig解析機構。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

import * as ts from 'typescript';

const configFileName: string[] = process.argv.slice(2);
// compiler option
const optionToExpend: ts.CompilerOptions = null;
// config file information
const createConfigFileHost: ts.ParseConfigFileHost = {
  // Reporter of unrecoverable error
  // When parsing config file
  onUnRecoverableConfigFileDiagnostic(diagnostic: ts.Diagnostic) {
    console.error(diagnostic);
    throw new Error(ts.flattenDiagnosticMessageText(diagnostic.messageText, "\n"));
  },
  useCaseSensitiveFileNames: false,    // file names are treated with case sensitivity <boolean>
  readDirectory: ts.sys.readDirectory, // used to cache and handle directory structure modifications <string>
  fileExists: ts.sys.fileExists,       // specified path exists and is a file. <boolean>
  readFile: ts.sys.readFile,           // Use to read file text for source files <string> 
  getCurrentDirectory: ts.sys.getCurrentDirectory, // current directory of the program <strig>
};
const configParseResult: ts.ParsedCommandLine = ts.getParsedCommandLineOfConfigFile(configFileName[0], optionToExpend, createConfigFileHost);
console.log(configParseResult);

getParsedCommandLineOfConfigFileを使うことでファイル名を指定してconfigファイルをreadできる。
解析結果のオブジェクトをもとにプログラムを作成し、コンパイルを行う

コンパイル関数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

// typescript compile option
const CJS_CONFIG: ts.CompilerOptions = {
  experimentalDecorators: true,
  jsx: ts.JsxEmit.React,
  module: ts.ModuleKind.ESNext,
  moduleResolution: ts.ModuleResolutionKind.NodeJs,
  noEmitOnError: false,
  noUnusedLocals: true,
  noUnusedParameters: true,
  stripInternal: true,
  resolveJsonModule: true,
  declaration: true,
  baseUrl: __dirname,
  target: ts.ScriptTarget.ES5
};

function compile(
  input: string,
  options: ts.CompilerOptions = CJS_CONFIG
) {
  const file = globSync(input);
  const compilerHost = ts.createCompilerHost(options);
  const program: ts.Program = ts.createProgram(file, options, compilerHost);

  const sourceFile: ts.SourceFile = program.getSourceFile(input);
  const WriteFileCallback = (fileName, data, writeByteOrderMark, onError, sourceFiles) => {
    fs.writeFileSync(fileName, data, 'utf8');
  }
  const cancellationToken: ts.CancellationToken = undefined;
  const emitOnlyDtsFiles: boolean = false;
  const customTransformers: ts.CustomTransformers = {
    before: [],             // to evaluate before built-in .js transformations.
    after: [],              // to evaluate after built-in .js transformations.
    afterDeclarations: [],  // to evaluate after built-in .d.ts transformations
  };
  // EmitResult {
  //  emitSkipped: boolean;
  //  diagnostics: ReadonlyArray<Diagnostic>;
  //  emittedFiles?: string[];
  // }
  const emitResult: ts.EmitResult = program.emit(sourceFile, WriteFileCallback, cancellationToken, emitOnlyDtsFiles, customTransformers);
  const allDiagnostics = ts
    .getPreEmitDiagnostics(program)
    .concat(emitResult.diagnostics);

  allDiagnostics.forEach(diagnostic => {
    let { line, character } = diagnostic.file.getLineAndCharacterOfPosition(
      diagnostic.start
    );
    let message = ts.flattenDiagnosticMessageText(diagnostic.messageText, "\n");
    console.log(
      `${diagnostic.file.fileName} (${line + 1},${character + 1}): ${message}`
    );
  });

  const CarriageReturnLineFeed: ts.NewLineKind = 0;
  const printerOptions: ts.PrinterOptions = {
    removeComments: true,
    newLine: CarriageReturnLineFeed,
    omitTrailingSemicolon: false,
    noEmitHelpers: true,
  }
  
  // debug code print
  // const printer: ts.Printer = ts.createPrinter(printerOptions)
  // const code: string = printer.printFile(sourceFile);
  // console.log('code: =>', code)

  const exitCode = emitResult.emitSkipped ? 1 : 0;
  if (exitCode) {
    console.log(`Process exiting with code '${exitCode}'.`);
  }

  process.exit(exitCode);
}

createProgramでProgramというコンパイル単位のインスタンスを生成する。
Programインスタンスはコンパイルに必要な設定情報やソースファイル情報などをもっている。

Programのemit()によりjsファイル、宣言ファイルを発行する。
ここでtargetSourceFileがない場合は、すべての対ファイルに対してのjsファイルと宣言ファイルが発行される。
emmit()のcustomTransformersオプションには、独自のtransform関数をフックできるようになっている。
それぞれ、jsファイル発行前後、宣言ファイル発行後のイベントフックできる。

各ステップでのコンパイルの結果はDiagnosticという共通のInterfaceをもっており、
programインスタンスから収集が可能になっている。

コンパイル結果のjsコード結果を取得する場合はcreatePrinter()を使い、printerインスタンスを使う。

今度はコードのtransformを行うcustom transform関数をcustomTransformersに追加する。
custom transformにはtypescriptのASTが与えられる。
またvisitorというAST解析、コード修正を再帰的に呼び出す必要がある。

簡単なtransformerを作成する。

1
2
3
4
5
6
7

function customTransform(options: customTransformOption): ts.TransformerFactory<ts.SourceFile> {
  return (context: ts.TransformationContext): ts.Transformer<ts.SourceFile> => {
    return (sorceFile: ts.SourceFile) => {
      return ts.visitNode(sorceFile, transformer(context, sorceFile, options))
    }
  }
}

transformerはNode変更に必要な関数TransformerFactoryを生成する必要がある。
visitNodeで所定のNodeに対してtransnformを適用する(ここではtransformer)。
transformerの処理は以下のようにする。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function transformer(context: ts.TransformationContext, sorce: ts.SourceFile, options: customTransformOption): ts.Visitor {
  const visitor: ts.Visitor = (node: ts.Node): ts.Node[]|ts.Node => {
    if (ts.isFunctionDeclaration(node)) {
      const declaration: ts.VariableDeclaration = ts.createVariableDeclaration(
        ts.createIdentifier('val'),
        ts.createKeywordTypeNode(ts.SyntaxKind.NumberKeyword),
        ts.createNumericLiteral('1000')
      );
      const declarations: ts.VariableDeclaration[] = [declaration];
      return [ts.createVariableDeclarationList(declarations, ts.NodeFlags.Const), node];
    }
    return ts.visitEachChild(node, visitor, context);
  }
  return visitor;
}

今回は関数宣言を変数宣言に置き換える簡単なものを作成する。
createVariableDeclarationListを作成して新たなNodeを生成しているが、
updateVariableDeclarationListなどもあり、既存のNodeに追加することも可能である。
基本的にcreateとupdateはそれぞれサポートされているのでオリジナルのNodeを更新することも可能。
webpackやrollupなどのツールの場合、独自のtransformerの設定がサポートされているので、自前のビルド環境に組み込むことは簡単。

1
2
3
4
5
6
7
8
9
10

// webpack.config.js
{
    test: /\.ts$/,
    loader: ‘ts-loader’,
    options: {
    getCustomTransformers: () => ({
      after: [customTransform] // set custom transformer
    }),
    transpileOnly: true
}

1
2
3
4
5
6
7
8
9
10
11
12
13

// rollup.config.js
import typescript from 'rollup-plugin-typescript2';
import customTransform from 'path/to/customTransform';

export default {
  // ...
  plugins: [
    typescript({ transformers: [service => ({
      before: [],
      after: [ customTransform() ]
    })] })
  ]
};

このtransformerを実際に実行するためにいくつか変更をする。

1
2
3
4

- const WriteFileCallback = (fileName, data, writeByteOrderMark, onError, sourceFiles) => {}
+ const WriteFileCallback = (fileName, data, writeByteOrderMark, onError, sourceFiles) => {
+     fs.writeFileSync(fileName, data, 'utf8');
+ }

1
2
3
4
5
6
7
8
9
10
11
12

const customTransformers: ts.CustomTransformers = {
    before: [],             // to evaluate before built-in .js transformations.
    after: [],              // to evaluate after built-in .js transformations.
-    afterDeclarations: [],  // to evaluate after built-in .d.ts transformations
  };
const customTransformers: ts.CustomTransformers = {
+    before: [
+      customTransform({program})
+   ],             // to evaluate before built-in .js transformations.
    after: [],              // to evaluate after built-in .js transformations.
    afterDeclarations: [],  // to evaluate after built-in .d.ts transformations
  };

1

+ compile(file, CJS_CONFIG);

この変更を加えて次のファイルのcompileを実行する。

1
2

// example.ts
function Example1() {};

1

$ npx ts-node custom-ast-transform.ts example.ts

transformされた結果としてのコードを得ることができる。

1
2
3
4

// example.js
var val = 1000
function Example1() { }
;

コールスタックをみていくと、program#emitでprogram#runWithCancellationTokenが呼ばれ、このrunWithCancellationTokenは処理をprogram#emitWorkerに移譲する。
この内部でcreateTypeCheckerによりcheckerオブジェクトが渡される。これにより多くのAPIが提供される。その一つのTypeChecker#getEmitResolverによりemitresolverが提供される。

1
2
3
4
5

program#emit
  program#runWithCancellationToken
    program#emitWorker
      checker#createTypeChecker
         => checker

引き続きemitWorker内でemitFilesが呼ばれ、オプションとしてsourceFileとemitResolverが渡される。

emitFilesではtsをjsにtransformしていく。
forEachEmittedFileのオプションで渡されるemitSourceFileOrBundleのemitJsFileOrBundleでtransformNodesが呼ばれ変換される。
transformationで変換する。

1
2
3
4
5
6

emitter#emitFiles
  emitter#forEachEmittedFile
    emitSourceFileOrBundle
      emitJsFileOrBundle
        transformer#transformNodes
          transformer#transformation

最後にprintSourceFileOrBundleが実施されてファイルに出力される。

今回は調査のために簡単なサンプルを作成しただけになるが、Typescript Compiler APIを活用することで独自の型チェック機構(linter)のようなものや型解析からのドキュメント自動生成、Debuger、polyfillの自動追加機構などのプラグインを作成可能になる。

APIの変更履歴はAPI Breaking Changesにあるので、利用するTypescriptのバージョンによっては確認しておくと良さそう。

型推論自体はinferTypesで行われ、このメソッドはcreateTypeCheckerで生成されるcheckerを経由して実行されている。
initializeTypeCheckerで

1
2
3

program#getTypeChecker
    ts#createTypeChecker
        initializeTypeChecker

型推論に関しては別途で見てみよう。

参考ページ

Using the Compiler API

Learning GraphQL を読むんで再認識したことも中心にメモした。

グラフ理論

GraphQLはこのグラフ理論に基づく考え方を知っておく必要がある。
ノード（節点・頂点）の集合とエッジ（枝・辺）の集合で構成されるグラフに関する数学の理論。

1

G(グラフ) = (V(頂点)、E(頂点))

で表すことができる。

ノード間に方向や階層がないものを無向グラフという。

ノード間の移動はどこからでもできて、方向は任意。非線形データ構造。
また、辺が順序付けられたペアであるときは有向グラフになる

実世界のグラフ

Facebookの各ユーザーの結びつきは、相互に関連し合う多数の関係を持つ構造で無向グラフ。
それに対してTwitterは有向グラフ。フォローするが、フォローされるわけではないため。

GraphQL

GraphQLとは

GraphQLはクエリ言語および実行エンジンであり、クエリを使用してデータを変更または削除できる。
GraphQLクエリをAPIに送信し、1つ以上のデータベース、REST API、WebSocketなどにデータを格納する。
MySQLのINSERT、UPDATE、DELETEと違いデータ変更を1つのMutation型にまとめ、データ型にまとめ実行するなどが可能。
ソケットを介しデータ変更を監視するためのsubscribe型がある。

GraphQLの操作

Graphqlの操作タイプは3種類ある。

• query: 問い合わせクエリ
• mutation: 作成、更新、削除クエリ
• subscription: websocketを介した変更監視クエリ

GraphQLのqueryの例

1
2
3
4
5

query {
  person {
    name
  }
}

上記は以下のようなhttpリクエストを通じて実行できる。

1
2
3

$ curl 'http://my.graphql.com'
  -H 'Content-Type：application/json'
  --data '{"query"： "{person {name}}"}'

データ更新する場合は次の雰囲気のクエリを実行する。

1
2
3
4
5
6

mutation {
  healthStatus(id: "TOM" status: 'OK') {
    name
    status
  }
}

こちらは以下のhttpリクエストで行える

1
2
3

curl 'http://my.graphql.com'
  -H 'Content-Type: application/json'
  --data '{"query":"mutation {healthStatus(id: \"TOM\" status: \"OK\") {name status}}"}'

フィールドには引数を受け付けることもできる

Fragmant

再利用可能なクエリの実行単位。
大きなクエリや頻繁に利用されるデータ要件を分割管理することができる。

1
2
3
4
5
6
7
8

fragment somethingFields on Person {
  name
  likes {
    foods
    books
    sports
  }
}

Introspection

ざっくりGraphQLがどのようなクエリやフィールドをサポートしているのかを問合る機能。

Schema、Type、TypeKind、Field、nputValue、EnumValue、Directive
アンダースコア()で始まるこれらはすべてイントロスペクションを表す。
内部の情報をクエリ経由で参照できる。つまりそのgraphqlサービスが提供するすべてを知ることができる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
__type(name: "Node") {
  name
  kind
  fields {
    name
    type {
      kind
      ofType {
        name
        kind
      }
    }
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

{
  "__type": {
    "name": "Node",
    "kind": "INTERFACE",
    "fields": [
      {
        "name": "id",
        "type": {
          "kind": "NON_NULL",
          "ofType": {
            "name": "ID",
            "kind": "SCALAR"
          }
        }
      }
    ]
  }
}

Directive

Directiveを利用することで既存の型システムに注釈をつけることができる。
ただしこればGraphqlサーバーの実装による。
https://graphql.org/learn/queries/#directives

@deprecatedディレクティブ

1
2
3
4
5
6
7
8

directive @deprecated(
  reason: String = "No longer supported"
) on FIELD_DEFINITION | ENUM_VALUE

type ExampleType {
  newField: String
  oldField: String @deprecated(reason: "Use `newField`.")
}

上記の場合@deprecatedディレクティブ宣言が与えられると、引数types(reason: String)とlocations(FIELD_DEFINITION | ENUM_VALUE)を適用するかどうかはサーバーの実装次第になる。

@exampleディレクティ部はフィールドFIELD_DEFINITIONと引数定義ARGUMENT_DEFINITIONに注釈をつけることができる。

@skipディレクティブ

クエリの実行をスキップする。

1
2
3
4
5

directive @skip(if: Boolean!) on FIELD | FRAGMENT_SPREAD | INLINE_FRAGMENT

query myQuery($isStatus: Boolean) {
  experimentalField @skip(if: $isStatus)
}

$isStatusがtrueの場合のみクエリが実行される。

@includeディレクティブ

@skipとは逆にクエリの条件にふくめることになる

1
2
3
4
5

directive @include(if: Boolean!) on FIELD | FRAGMENT_SPREAD | INLINE_FRAGMENT

query myQuery($isStatus: Boolean) {
  experimentalField @include(if: $isStatus)
}

クエリでの再帰的検索

GraphQLはデータを無限に再帰検索しない。
Graphデータが無限再起でないことを保証する方法がない。
また再帰的にしても、クエリを利用するアプリケーションの制約があるため利用できないことがある。
対策法として、任意の深さまでデータを取得し、更に追加の情報を取得する必要がある場合は「もっと見る」などのリンクを追加することがよい。

この辺の議論

ID型について

IDがintなのかstringがいいのかとかの話につながるが、Scaler-IDを読むと以下の通り。

The ID type is serialized in the same way as a String; however, it is not intended to be human‐readable. While it is often numeric, it should always serialize as a String.

IDはStringと同じ方法でシリアライズされます。ただし、人間が読める形式ではありません。
多くの場合数値ですが、常にStringとしてシリアル化する必要がある。

言語実装

graphql.jsを例にすると、lexer, ast, parserがあることから、これを基準に各言語でも言語処理が可能。

GraphQL周辺のコミュニティ

GraphQLは既にFaceBookを離れてGraphQL Foundationとなっている。

Apollo GraphQLでGraphQL界隈のツールを多く提供している。Meteor Development Group Inc.が母体。

prisma

GraphQLをとり言えれたアプリケーションのアーキテクチャ

REST APIでは、複数のエンドポイントにアクセスしてデータを収集する。
GraphQLはデータ要件を含む単一のクエリをGraphQLサーバーに送信するだけになる。
よって、複数のエンドポイントを束ねたエンドポイントを構築するよりも、ミドルウェアとしてGraphQLを導入する。
また、スキーマファーストでの開発となる。既にあるリソースを用い、データ構造を抽象化していくことになる。
あらかじめ各データのスキーマを定義しておくことでデータ結合のためのビジネスロジックの開発から解放される。

Falcorのような解決方法もあるがGraphQLのエコシステムを選ぶことが懸命になっている。

セキュリティ上検討すべきこと

認証

実行クライアントを制限。認証Tokenなどを使い実行クライアントを認証することができる。
(Githubなど)

SlowQuery

Slowクエリなどの問題は適切なタイムアウトを設定しておく必要がある。
ただし、jmutationなどが実行された場合、すでにデータに不整合が発生していることもある。

Max Depth

クエリの深度を限定する。再帰的に検索することにもなるため、クエリ実行時にAST分析を行い、最大深度以上のフィールをを無視する。(またはエラーにする)実装が必要。
DoSなどでネスとクエリで攻撃をかけることも可能。

Complex Query

複雑なクエリも定義できるが、実装は難しくなることもある。
また、複雑ゆえに本来隠匿されるべきデータへのアクセスにより、情報が漏洩することや、
データ構造からSQL/NoSQLへのInjectionも起こりえそうなため
できるだけクエリはシンプルに保つことが望ましそう。

Validation

アカウント認証、パスワード認証などの検証機構は提供されてない(あくまでクエリ言語なのため)。
実装するやり方にもよるが、自前でタイプなどの実装が必要になることも。
Validation不備の場合、webのアプリケーションと同じく、injectionやXSSの脆弱性を生むことにもつながる。

そもそもGraphQLで実現すべき機能なのかも踏まえて検討するべき。

実装に関して

Apollo界隈のtool中心に

Apollo Server利用にしている場合。
SchemaDirectiveVisitorを利用する。
このクラスにはllocationsに対応するメソッドが準備されているのでそれをオーバーライドすることになる。

SchemaDirectiveVisitorを継承したDeprecatedDirectiveを作成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// directive @deprecated(
//   reason: String = "No longer supported"
// ) on FIELD_DEFINITION | ENUM_VALUE
// 上記を実装する場合

import { SchemaDirectiveVisitor } from 'graphql-tools';
export default class DeprecatedDirective extends SchemaDirectiveVisitor {
  public visitFieldDefinition(field: GraphQLField<any, any>) {
    field.isDeprecated = true;
    field.deprecationReason = this.args.reason;
  }

  public visitEnumValue(value: GraphQLEnumValue) {
    value.isDeprecated = true;
    value.deprecationReason = this.args.reason;
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import { makeExecutableSchema } from 'graphql-tools';
import DeprecatedDirective from 'directive/DeprecatedDirective'

const typeDefs = `
type ExampleType {
  newField: String
  oldField: String @deprecated(reason: "No longer supported")
}`;

const schema = makeExecutableSchema({
  typeDefs,
  schemaDirectives: {
    deprecated: DeprecatedDirective
  }
});

ユースケーストして日付フォーマットの変更の場合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

import { defaultFieldResolver } from "graphql";

const typeDefs = `
directive @date(format: String) on FIELD_DEFINITION

scalar Date

type Post {
  published: Date @date(format: "mmmm d, yyyy")
}`;

class DateFormatDirective extends SchemaDirectiveVisitor {
  visitFieldDefinition(field) {
    // https://github.com/graphql/graphql-js/blob/master/src/execution/execute.js#L1238
    // fileld is `resolve`
    const { resolve = defaultFieldResolver } = field;
    const { format } = this.args;
    // overwrite resolve filed method
    field.resolve = async function (...args) {
      const date = await resolve.apply(this, args);
      return require('dateformat')(date, format);
    };
    // The formatted Date becomes a String, so the field type must change:
    field.type = GraphQLString;
  }
}

const schema = makeExecutableSchema({
  typeDefs,
  schemaDirectives: {
    date: DateFormatDirective
  }
});

Apollo GraphQL Platform

Apollo Client

名前の通り。
https://github.com/apollographql/apollo-client
アプリのデータと状態を管理するClient。

InMemoryCache

Apollo Clientのキャッシュ機構。
Apollo ClientのDataProxyを通して、
readQuery, readFragment, writeQuery, writeFragment インターフェイスを経由してcacheとやり取りする。

readQuery

queryの場合は、サーバーにリクエストするが、readQueryはApplicationにcacheあがない場合はエラーを投げる。

1
2
3
4
5
6
7
8
9
10
11

const { todo } = client.readQuery({
  query: gql`
    query ReadTodo {
      todo(id: 5) {
        id
        text
        completed
      }
    }
  `,
});

1
2
3
4
5
6
7
8
9
10
11

client.writeFragment({
  id: '5',
  fragment: gql`
    fragment myTodo on Todo {
      completed
    }
  `,
  data: {
    completed: true,
  },
});

Appolo Link

GraphQLサーバーへのリクエストを制御するインターフェイス。
GraphQLリクエストを実行すると、各Linkの機能が次々に適用されます。
Apollo Clientコアにある機能をモジュラーリンクに移行する予定。

1

ApolloLink.from([...])

fromで配列を受け取りそれらを単一のリンクに統合する。
内部的にreduceする。

1

ApolloLink.concat(x, y)

concatでリンクを結合して1つにする。

状況によってことなるリンクを使うのであれば

1

ApolloLink.spilit(conditon, condition_is_true, condition_is_false)

spilitのオプションは第一引数に条件、第二引数にtrueの場合のリンク、第三引数にfalseの場合のリンク

apollo-link-state

ローカルの状態を管理する。
起動時にwithClientStateでローカルのデータストアに状態を登録する。

apollo-cache-persist

clientの永続化ストレージにstateを自動的に保存または復元する。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import { InMemoryCache } from 'apollo-cache-inmemory';
import { persistCache } from 'apollo-cache-persist';

const cache = new InMemoryCache({...});

persistCache({
  cache,
  storage: window.localStorage,
});

// Continue setting up Apollo as usual.
const client = new ApolloClient({
  cache,
  ...
});

apollo-link-error

GraphQLまたはネットワークエラー発生時のロジックを提供する。
以下のオブジェクトキーが利用できる。

GraphQL Server

apollo-server

名前の通り。
https://github.com/apollographql/apollo-server
JavaScript GraphQLサーバー。schmemeとresolverを定義。

バックエンドに既存のREST API、Database, Microserviceの場合、それぞれが持っているミドルウェアと一緒に組み込むことが可能。
またAmazon LambdaやMicrosoft Azure Functionsなどのサーバーレス(Faas)をバックエンドに使うことも可能。

apllo-serverのintegrationには以下がある。

• apollo-server-express
• apollo-server-koa
• apollo-server-hapi
• apollo-server-lambda
• apollo-server-azure-functions
• apollo-server-cloud-functions
• apollo-server-cloudflare

Mocking

フロントエンドの開発者がバックエンドの実装を待つことなくUIコンポーネントと機能を構築できるようにするためにmocking機能がある。

モックの例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

const { ApolloServer, gql } = require('apollo-server');

const typeDefs = gql`
  type Query {
    hello: String
  }
`;

const mocks = {
  Person: () => ({
    name: casual.name,
    age: () => casual.integer(0, 120),
  }),
};

const server = new ApolloServer({
  typeDefs,
  mocks,
});

server.listen().then(({ url }) => {
  console.log(`Server ready at ${url}`)
});

MockList Resolver

モックの作成を自動化するためにMockListクラスを利用できる。

1
2
3
4
5
6
7
8
9
10

const { MockList } = require('apollo-server');

const mocks = {
  Person: () => ({
    // a list of length between 2 and 6 (inclusive)
    friends: () => new MockList([2,6]),
    // a list of three lists each with two items: [[1, 1], [2, 2], [3, 3]]
    listOfLists: () => new MockList(3, () => new MockList(2)),
  }),
};

Resolver

リゾルバーはGraphQL操作をデータに変換するための方法を提供します。

Resolver Map

すべてのクエリに対応するために、スキーマはすべてのフィールドに対して解決関数を持っている。
この関数の集合をResolver Mapという。
スキーマのフィールドと型を関数で紐付ける。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

const { gql } = require('apollo-server');
const { find, filter } = require('lodash');

const schema = gql`
  type Book {
    title: String
    author: Author
  }

  type Author {
    books: [Book]
  }

  type Query {
    author: Author
  }
`;

const resolvers = {
  Query: {
    author(parent, args, context, info) {
      return find(authors, { id: args.id });
    },
  },
  Author: {
    books(author) {
      return filter(books, { author: author.name });
    },
  },
};

型とリゾルバは組み合わせることができるので、複数に分けて管理することは可能。

リゾルバ関数

schemeで定義されたフィールを返すPromise関数。

contextの例

1
2
3
4
5
6
7
8
9
10
11
12
13

const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ req }) => ({
    authScope: getScope(req.headers.authorization)
  })
}));

// resolver
(parent, _, context) => {
  if(context.authScope !== ADMIN) throw AuthenticationError('not admin');
  ...
}

react-apollo

ReactのためのApolloClient拡張。
GraphQLサーバーからデータを取得し、ReactのComponentにprops経由で接続する。
よく見られる高階関数パターン。

1
2
3
4
5
6
7
8
9
10
11

import ApolloClient from 'apollo-boost';
import { ApolloProvider } from 'react-apollo';

const client = new ApolloClient();

ReactDOM.render(
  <ApolloProvider client={client}>
    <MyRootComponent />
  </ApolloProvider>,
  document.getElementById('root'),
);

でコンポーネントにclientを渡すことができる
https://github.com/apollographql/react-apollo/blob/master/src/ApolloProvider.tsx#L9

各コンポーネントからクエリを発行する。
複数のクエリをcomposeして発行することも可能。

ということでここまでで時間切れ。

参考ページ

• https://graphql.org/
• https://www.apollographql.com/docs/
• https://graphql.github.io/graphql-spec/
• https://gql.foundation/

v11.7.0でworker_threadsが取り込まれたことで、スレッド処理が可能になった。

https://github.com/nodejs/node/pull/25361

ちなみにv11.7.0 以前では worker_threads の利用の際には--experimental-workerオプション付きで利用できていた。

並行処理

EventLoop

Event Loop Explained

IOバウンドな処理を考慮した場合、処理の実行タイミングを変更することで、回避することができる。
一般的なEventloopを利用したバックグラウンド処理がそれにあたる。
負荷の高いコードを分割して、setImmediateを活用し、IOの後で評価することができる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

'use strict';
const num = [],
      start = 0,
      end = 50000;

process.on('count', function(c) {
  if (c > end) {
    const result = num.reduce(function(prev, current, _, __) {
      return prev + current;
    });
    console.log(result);
    return;
  }
  num.push(c);

  setImmediate(function() {
    process.emit('count', ++c);
  });
});

process.emit('count', start);

child_process

CPUバウンドな処理が渡されるとJavaScriptはシングルスレッドなので、WebアプリケーションだとUIがフリーズし、他の処理がキューイングされる。
そこで、CPUバウンドな処理の場合はマルチプロセス機構を使い処理することも可能。
マルチプロセスなので子プロセスは独自のメモリを持っているが、プロセス間に共有メモリはない。
また、プロセス間のメッセージングはIPCとなる。

https://github.com/nodejs/node/blob/2c84f6e75cc513fe6e958f0489d104ee883db232/lib/child_process.js#L117

起動時にモジュール、を割り当て(その他のオプションも)、プロセスを起動する。

https://github.com/nodejs/node/blob/2c84f6e75cc513fe6e958f0489d104ee883db232/lib/child_process.js#L59

起動時のメモリ割り当てが高価な点やリアルタイム性から利用できるシーンが決まってくる。

複数プロセス利用はjest-workerなどで利用されているnode-worker-farmのモジュール利用することが現在のところ良さそう。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

// index.js
let workerFarm = require('worker-farm'),
    process    = require('process'),
    workers    = workerFarm(require.resolve('./child'));

let num = [];
const start = 0,
      end = 100;

const child_prosess = require('os').cpus().length;

const range = (start, end, separate) => {
  const result = [];
  const count = (end - start) / separate;

  for (let i = 0; i < separate; i++) {
    let tmp = {};
    if (i == 0) {
      tmp = {
        start,
        end: count,
      };
    } else {
      tmp = {
        start: result[i - 1].end + 1,
        end: result[i - 1].end + count,
      }
    }
    result.push(tmp);
  }
  return result;
}

const ranges = range(start, end, child_prosess);
ranges[ranges.length - 1].end += (end % child_prosess);

for (let i = 0; i <= child_prosess; i++) {
  workers(ranges[i], function (err, outp) {
    if (err) {
      console.error(err);
    }
    num = num.concat(outp)
    if (i == child_prosess - 1) {
      workerFarm.end(workers);
      const result = num.reduce(function(prev, current, _, __) {
        return prev + current;
      });
      console.log(result);
      process.on('exit', function() {
        process.exit(0);
      });
    }
  });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// child.js
'use strict'

const num = [];
const count = function(start, end) {
  for(let i = start; i <= end; i++) {
    if (num.some(function(v) { return v === i }) === false) {
      num.push(i)
    }
  }
} 

module.exports = function (inp, callback) {
  if (!inp) { return }
  const {start, end} = inp;
  count(start, end);
  console.log(`${process.pid} running`);
  callback(null, num);
}

cluster

child_processと同じく、子プロセスをforkする。

https://github.com/nodejs/node/blob/2c84f6e75cc513fe6e958f0489d104ee883db232/lib/internal/cluster/master.js#L162

https://github.com/nodejs/node/blob/2c84f6e75cc513fe6e958f0489d104ee883db232/lib/internal/cluster/master.js#L102

child_processでは実行モジュールなどをオプションとして渡す必要があるが、
clusterは親プロセスと同じモジュールの先頭から実行するため不要になる。

https://github.com/nodejs/node/blob/2c84f6e75cc513fe6e958f0489d104ee883db232/lib/internal/cluster/master.js#L284

Nodejsのアプリケーション自体を並列化する。
clusterモジュールが利用できる。
マスタープロセスにリクエストが来ると、ワーカープロセスに処理を委譲する。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

const cluster = require('cluster');

let num = [];
const start = 0,
      end = 100;

const count = (start, end) => {
  const tmp = [];
  for(let i = start; i <= end; i++) {
    if (num.some((v)  => { return v === i }) === false) {
      tmp.push(i)
    }
  }
  return tmp;
} 

const range = (start, end, separate) => {
  const result = [];
  const count = (end - start) / separate;

  for (let i = 0; i < separate; i++) {
    let tmp = {};
    if (i == 0) {
      tmp = {
        start,
        end: count,
      };
    } else {
      tmp = {
        start: result[i - 1].end + 1,
        end: result[i - 1].end + count,
      }
    }
    result.push(tmp);
  }
  return result;
}

const child_prosess = require('os').cpus().length;

const messageReceive = () => {
  return new Promise((resolve, reject) => {
    let finichProcess = 0;
    cluster.on('message', (worker ,message, handle) => {
      finichProcess++;
      num = num.concat(message)
      if (finichProcess === child_prosess) {
        resolve(num);
      }
    });
  });
}

const mainFunction = () => {
  const ranges = range(start, end, child_prosess);
  ranges[ranges.length - 1].end += (end % child_prosess);
  for (let i = 0; i < child_prosess; i++) {
    let worker = cluster.fork();
    worker.on('online', () => {
      worker.send(ranges[i]);
    });
  }

  const promise = messageReceive();
  promise.then((num) => {
    const result =  num.reduce((prev, current, _, __) => {
      return prev + current;
    });
    console.log(result);
  });
}

const childProcessFunc = () => {
  process.on('message', (data) => {
    const response = count(data.start, data.end);
    process.send(response);
    cluster.worker.disconnect();
  });
}

(async () => {
  if (cluster.isMaster) {
    mainFunction();
  } else {
    childProcessFunc();
  }
})();

マルチスレッド

マルチプロセスを利用した場合は、プロセス生成時に起動時に大量のメモリが消費される。
そこで共有メモリを利用し、マルチプロセスより軽量なマルチスレッドを使うことになる。

https://github.com/nodejs/node/blob/master/lib/worker_threads.js

Workerコンストラクタ。実行するファイルのパスが引数。

https://github.com/nodejs/node/blob/ba4df925eb7143606d5a57f49e4ecb179dd7743b/lib/internal/worker.js#L51

isMainThreadでマインスレッドか判定。
parentPort.postMessage()メインスレッドにメッセージング。
IPCでのメッセージングではない。

https://github.com/nodejs/node/blob/master/lib/internal/worker.js#L106

メッセージの処理は以下にまとまっている

https://github.com/nodejs/node/blob/master/lib/internal/worker/io.js
https://github.com/nodejs/node/blob/8375c706ad51a399451e4f43b075f3795c440dad/src/node_messaging.cc#L802

HTML structured clone algorithmと互換性のある形式のものが転送される。
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#Supported_types

workerData JavaScriptの値で、Workerコンストラクタに渡されたデータのクローン。

https://github.com/nodejs/node/blob/ba4df925eb7143606d5a57f49e4ecb179dd7743b/lib/internal/worker.js#L116

関連するN-APIは以下なのかな？

• napi_threadsafe_function
  https://github.com/nodejs/node/blob/11387e1454d8b8311dfdb1bac6a7ec1a1494946d/doc/api/n-api.md#napi_threadsafe_function

workser threadから非同期的にJavaScript関数を呼び出す。

• napi_threadsafe_function_release_mode
  https://github.com/nodejs/node/blob/11387e1454d8b8311dfdb1bac6a7ec1a1494946d/doc/api/n-api.md#napi_threadsafe_function_release_mode

workser threadが即時終了状態か

• napi_threadsafe_function_call_mode
  https://github.com/nodejs/node/blob/11387e1454d8b8311dfdb1bac6a7ec1a1494946d/doc/api/n-api.md#napi_threadsafe_function_call_mode

スレッドセーフ関数のキューがいっぱいになった時にブロックするか

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

'use strict';
const {
  Worker,
  isMainThread,
  parentPort,
  workerData
} = require('worker_threads');

let num = [];
let start = 0;
let end = 50000;

const count = function(start, end) {
  for(let i = start; i <= end; i++) {
    if (num.some(function(v) { return v === i }) === false) {
      num.push(i)
    }
  }
} 

const range = (start, end, separate) => {
  const result = [];
  const count = (end - start) / separate;

  for (let i = 0; i < separate; i++) {
    let tmp = {};
    if (i == 0) {
      tmp = {
        start,
        end: count,
      };
    } else {
      tmp = {
        start: result[i - 1].end + 1,
        end: result[i - 1].end + count,
      }
    }
    result.push(tmp);
  }
  return result;
}

if (isMainThread) {
  const threadCount = +process.argv[2] || 2,
        ranges = range(start, end, threadCount),
        threads = new Set();

  ranges[ranges.length - 1].end += (end % threadCount);

  for (let i = 1; i < threadCount; i++) {
    threads.add(new Worker(__filename, { workerData: { start: ranges[i].start, end: ranges[i].end }}));
  }

  threads.add(new Worker(__filename, { workerData: { start: ranges[0].start, end: ranges[0].end }}));

  for (let worker of threads) {
    worker.on('error', (err) => { throw err; });
    worker.on('online', () => {
      console.log(`Thread running start ID: ${worker.threadId} ...`);
    });
    worker.on('exit', () => {
      console.log(`Total thread, ${threads.size} running ...`);
      threads.delete(worker);
      if (threads.size === 0) {
        const result = num.reduce(function(prev, current, _, __) {
          return prev + current;
        });
        console.log(result)
      }
    })
    worker.on('message', (msg) => {
      num = num.concat(msg);
    });
  }
} else {
  count(workerData.start, workerData.end);
  parentPort.postMessage(num);
}

参考ページ

Node.js v10.15.1 Documentation Worker Threads

React Hooksとは

Functionalコンポーネントからコンポーネントの状態やライフサイクル機能をフックさせるAPI。
後方互換があるため既存のアプリにも将来的に組み込むことが可能。
提供されているReact Hooks apiから独自のHooksを

React Hooksを試す

React Hooks apiを使って無理やりカウンターを作る。
さすがに全ては使うことができないので、以下の機能を試した。

• Basic Hooks
  • useState
  • useEffect
  • useContext
• Additional Hooks
  • useReducer
  • useCallback
  • useRef

ちなみにReact Hooksは現時点でstableではないので、プロダクションアプリで利用すべきではない。
またTypeScriptなどで利用する場合、必ずしも型情報が充分に提供されているわけではない。
React Hooks apiのリストからわかる通り、useReducer useContext あたりを使うことで、将来的にはReduxは必要なくなる感じっぽい。
(Redux Devtoolsなどのコミュニティが作り上げたエコシステムがあるのですぐには無くならないかもしれない)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

import * as React from "react";
import { render } from "react-dom";

const IncrementAction =  `increment`;
const DecrementAction = `decrement`;
const ResetAction = `reset`;
const InitAction = `init`;

type CounterAction = {
  type?: string;
};

type CountType = {
  count: number,
}

const initialState: CountType = { count: 0 };
const initAction = { type: InitAction };
const CounterState: CountType & CounterAction = Object.assign({}, initialState, initAction);
type CounterStateType = typeof CounterState;

function reducer(state: CounterStateType, action: CounterAction) {
  switch (action.type) {
    case ResetAction:
      return initialState;
    case IncrementAction:
      return { count: state.count + 1 };
    case DecrementAction:
      return { count: state.count - 1 };
    case InitAction:
    default:
      return state;
  }
}

const Counter: React.FC<CounterStateType> = () => {
  // const [state, setState] = useState(initialState);
  const [state, dispatch] = React.useReducer(reducer, CounterState);

  React.useEffect(
    () => {
      document.title = `Counter count is  ${state.count}`;
    },
    [state.count]
  );

  const incrementButton = React.useRef<HTMLButtonElement>(null);
  const onResetButtonClickHandler = () => {
    if (incrementButton && incrementButton.current) {
      incrementButton.current.focus();
    }
  };

  const { increment, decrement, reset } = React.useContext(CounterContext);

  const increaseClickHandler = React.useCallback(
    () => dispatch({ type: "increment" }),
    []
  );

  const decreaseClickHandler = React.useCallback(
    () => dispatch({ type: "decrement" }),
    []
  );

  const resetClickHandler = React.useCallback(
    () => dispatch({ type: "reset" }),
    []
  );

  return (
    <div>
      <h1>Counter Example App</h1>
      <p>count: {state.count}</p>
      <button
        onClick={() => {
          resetClickHandler();
          onResetButtonClickHandler();
        }}
      >
        {reset}
      </button>
      <button onClick={increaseClickHandler} ref={incrementButton}>
        {increment}
      </button>
      <button onClick={decreaseClickHandler}>{decrement}</button>
    </div>
  );
};

const CounterContext = React.createContext({
  increment: "increment (+)",
  decrement: "decrement (-)",
  reset: "reset (0)"
});

const App = () => {
  return (
    <div>
      <Counter count={1} />
    </div>
  );
};

render(<App />, document.getElementById("root"));

その他

React Hooks自体は単純なStack Queueで管理されているので、Root Componentレンダリングのタイミングで各コンポーネントのHooksが発火していく。

React hooks: not magic, just arraysでも言及されているようにその順序を破壊しないように使う必要がある。

1

Don’t call Hooks inside loops, conditions, or nested functions.

Rules of Hooks より

React Hooksの導入でアプリのリファクタリングにかける時間的なコストは下げられそう。
またパフォーマンスの問題などこれまでより考慮することが減りそうなのはとてもよい。

SuspenseなどからもReact Componentがあたかも生物のように自律的に機能することになっていきそうな感じだな。

参考にした記事

Hooks API Reference
Under the hood of React’s hooks system
React hooks: not magic, just arrays

今回作成したサンプル

https://codesandbox.io/embed/vj15lzxx4l

該当の変更は以下を参照

• React.memo()
• React.lazy()

React.memo

PureComponentはstateをshallow Equalによってupdateするのかを決める機能を持っているが、class Componentでしか利用できない。

React.memoはfunction componenをラップしてPureComponentと同じく、shallow Equalでコンポーネントをupdateする機能を提供するAPIである。
このあたりがそれっぽい

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82