Vue Fes Japan 2018 に行ってきた #vuefes

Vue.js メモ

Vue Fes Japan に行ってきました。簡単に所感をまとめます。

vuefes.jp

今回参加したセッションは以下の通り。メモから抜粋。スライドが公開されたらリンクを貼っておきます。尚、英語セッションはリスニング力がショボすぎて理解が誤ってるかもしれません...。

キーノート

docs.google.com

  • Vue 3.0 Updates
    • 速度向上が重要
    • サイズを小さくする
    • メンテナンスしやすく
    • ネイティブ向けに

より速く:

  • 仮想 DOM の実装をフルスクラッチで作り直す
    • 最大100%の速度改善！
  • 後方互換あり、内部実装を作り変える
    • ライブラリ作者は少し調整が必要になるかも
  • JavaScript の新しい言語仕様を使うようにする
    • 3.x ではプロキシを使うように書き換えている
    • 2.x では ES5 の getter/setter を使っている
    • プロパティの追加/削除を検知できるようになる
    • ネイティブプロキシによるプロパティプロキシの高速化
      • Object.defineProperty は使わない
  • 実行中のオーバーヘッド削減のため、コンパイル時にヒントを追加
    • Render Function
    • コンパイル時にテンプレートの情報を取得する
    • これまでは実行時に解析していた
    • 必要な情報をコンパイル時に取得することで実行時の速度が向上する
  • Render 関数にあるスロット機能を最適化 (スロットの生成を最適化)
    • 2.x ではスロットは親のスコープで生成されるため、子要素は親要素を参照する必要があり、描画時に依存の階層が深くなる
    • 子要素が変更されたときは子要素のみ再描画すればよい
    • React にはこの仕組みはない
  • static tree hoisting (静的ツリーの巻き上げ)
  • static props hoisting (静的プロパティの巻き上げ)
    • ツリー全体を再描画するのではなく、中身だけ再描画する
  • inline handler hoisting (インラインハンドラの巻き上げ)
  • コンポーネントインスタンスの初期化を高速化
  • 省メモリ、パフォーマンス向上
  • Vue をアップデートするだけでパフォーマンス向上が可能

より小さく:

  • Tree-shaking への対応
  • Webpack や Rollup では Tree-shaking に対応している
  • オプション機能のコードをバンドルに含めないようにする (10KB以下も可能)

よりメンテしやすく:

  • アーキテクチャをよりクリーンなものに
  • パッケージの分離
    • リポジトリはモノリポジトリ
    • 独立した機能ごとにパッケージとして分ける
    • 実行環境に依存しない、js が動く環境であればどこでも動かせる

よりネイティブに:

  • iOS, Android
  • カスタムレンダラAPI
    • ブラウザ以外の環境向けに出力できる
    • NativeScript, Weex
    • ネイティブ向けに出力するために作った

コードの品質向上:

  • どのオプジェクトのプロパティでも監視できるようになる
  • Vuex を使わなくもよくなるかも

リアクティビティAPI:

TSX による TypeScript サポート:

  • Vue 2.x では完璧なものではなかった
  • props の型を表示できる (違う型を指定すると警告を表示してくれる)
  • 子コンポーネントと親コンポーネントの警告をコンソールに表示してくれる

(Experimental) Hooks API:

(Experimental) Time Slicing:

  • 描画に時間がかかるコンポーネントが複数あるとき、ブラウザが固まってしまう
  • Time Slicing を使うだけでレスポンシブになる
  • 60fps で収まるように js 関数をスロットリングする
  • イベントが連続したときに、古いイベントはスキップする

Vue.js と Web Components のこれから

  • Web Components
  • Web Components Specifications ★
    • HTML Template はもう使われなくなる？
  • Vue CLI 3 の Build Targets
    • --target wc オプションをつけてビルド
    • Vue.js コンポーネントを Web Components に変換してくれる
    • web-component-wrapper
      • Vue.js をラップしている
    • Vue.js コンポーネントを Web Components にスムーズに移行できる
  • Vue, React, Angular で共通のUIフレームワークとして使い回せる
  • Fully Scoped
    • Vue.js は Scoped っぽくなっている
    • Shadow DOM なので完全に Scoped
    • グローバルの css や js に影響しない
  • デメリット ★
  • 現時点では Vue.js でコンポーネントを作った方が機能的にいいかも
  • Micro Frontends ★
    • Web アプリを機能の集合と見なす
    • 一般的なフロントエンドはモノリシックになっている
    • 独立した機能で分割する
    • Shadow DOM は Scoped なので、変更が他のコンポーネントに影響しない
    • Web Components は Micro Frontends を実現するのに適している
  • 柔軟な Web サイトに
  • Vue.js の方が機能的に強力ではあるが、Web 標準であることの強みは将来の負債を減らす
  • Web Components は Vue.js を置き換えるものではない
    • Web Components は HTML 要素をカプセル化するもので、Web アプリを作るものではない
    • UI を相互干渉なく作るためのもの
    • Vue.js は Web アプリを作るためのもの
  • UI を Web Components に任せることで負債を減らす

Unit testing a Vuex store

slides.com

  • なぜテストをするのか
  • Three approaches ★
  • Don't
    • UT を書くのにも時間はかかる
    • E2E tests test store implicitly
  • store のパーツごとにテストする
    • Mutations
      • state と payload を渡して mutate して update されていることを assert
    • Getters
      • state を渡して getter を解決、戻り値を verify
    • Actions
      • HTTP リクエストはしない (テストがスローダウンするため)
      • jest.mock で API の戻り値をモック化する
      • mock の store を渡して、action が data を commit していることを assert
    • 粒度が細かいが、メンテが大変
  • store インスタンスをテストする
    • ブラックボックス？
    • Vue.use(Vuex) はだめ
      • グローバルな Vue インスタンスに影響を与えないため
      • localVue.use(Vuex)
    • store.dispatch で action を呼び出して、state を assert
    • 必要に応じて API 呼び出しをモック化
    • 粒度は荒いが、メンテはラク
  • 複雑なテストを何度も回せるようにファクトリ関数を用意している
  • vue-test-utils はベータ
  • Vue 3 ではブラウザの DOM を使わずにレンダリングできる
    • これを使ってテストすることで高速化できるかも？
  • テストのときに本物の store を使うか、モックの store を使うか
  • コンポーネントのテスト
  • カバレッジを上げることより、何をテストするのかを見極めることが大事
    • 無駄にテストするより、新機能を開発することに注力する方がいい
  • TDD

Nuxt.js 2.0

  • レンダリングモード
  • モダンブラウザ対応のビルド
  • ブラウザと REST サーバーの間に Nuxt サーバーを置いてもいい (BFF)
  • https://hn.nuxtjs.org/
  • ブラウザ => APIサーバーだとユーザーごとにリクエストが来る？
    • SSR なら Nuxt サーバーで中継できる？
  • 静的ファイルはECサイトみたいな動的サイトに向かない
  • SPA
  • 2.3 でクライアントとサーバーのバンドルを分離できる
    • クライアントフォルダ / サーバーフォルダ
  • ES Modules 対応
  • 新規追加したコンポーネントは自動でルーティングなどに設定してくれる
  • asyncData のコンテキストはドキュメント参照
  • Vue 2.x のサポートが続くので、Nuxt 2.x のサポートも続く
  • Vue 3.x に合わせて Nuxt 3.x もリリースされる予定

note のフロントエンドを Nuxt.js で再構築した話

  • Angular.js 1.x
    • 初期表示が遅い (特に低スペックな端末)
    • SSR 未サポート
  • Nuxt.js によって規約が手に入る ★
  • パスベースで移行、Dog Fooding
    • 移行完了するまで二重メンテになるのがデメリット
    • チームを分ける
  • Lighthouse によるパフォーマンス比較
    • 指摘されているのはほとんど画像関連
  • Vuex + Atomic Design
  • mutations/actions/getters のタイプには定数を使う
    • grepability
    • エディタ補完
  • Vuex モジュール肥大化問題 (特に Actions に処理が集中しがち)
    • パーツごとにファイルを分離
    • 機能単位でモジュール分割できないか
  • Atomic Design
    • レイヤごとの責任分離が明確に
    • 名称があることでコミュニケーションが円滑に
  • コンポーネント視認性問題
    • Storybook
  • ユニバーサル JavaScript
    • クライアント/サーバーのどちらでも動作する
    • window, document は undefined
  • Polyfill.io
  • Nuxt on Lambda
    • Node.js のバージョンが固定されるため、Nuxt.js の最新に追従できない
    • ファイルサイズ上限が50MB
    • コールドスタート問題

1年間単体テストを書き続けた現場から送る Vue Component のテスト

  • 半数以上のサービスで Vue を使っている
  • 外部から見た振る舞いをテストする ★
  • Public Interface
  • Output
    • HTML/CSS, Event(Emit), Vuex/Action
  • ↑これらがテストターゲット ★
  • mount or shallow mount
    • 外部から見た振る舞い、設計の可動域の確保の観点から mount
  • router から読み込む Page Component をテストする
    • Page Component でカバーできないものは別途テスト
  • テストツールの役割を整理する ★
    • ブラウザが必要 or ブラウザが不要
  • Lifecycle Hooks ★
  • Props / Vuex State ★
    • 見た目にかかわるところ
    • Snapshot Testing ★
      • コンポーネントの DOM を比較する
      • 修正前後の DOM を比較する (差分があればチェック)
    • Visual Testing
      • Snapshot Testing の画像版 (CSS もテスト可能)
    • Storybook + reg-suit (画像の差分抽出) ★
      • Visual Testing を開発フローに乗せる
      • 以前は手元に checkout して起動したり、修正前後の画像をキャプチャしたり
      • レビューの負荷を下げることができる
  • User Interaction
    • スクロールなどの複雑な操作は難易度高い (できないことはないが諦める)
    • karma-nightmare でテスト中にスクリーンショットを取る
    • 画像は reg-suit で開発フローに乗せる
    • 重要なフォームだけでもテストする
    • 難しいところは割り切って諦める
  • テストをしっかり準備することでレビュー負荷を下げられる

所感など

登壇者が豪華で、改めて Vue.js の盛り上がりと勢いを感じます。全体的に学びと刺激が多いカンファレンスでした。キャンセル分のチケットが購入できてよかった...！

最初の KEYNOTE で 3.x の話がありましたが、特にパフォーマンスを改善する仕組みが多く取り込まれているようです。後方互換もちゃんと考慮されていて、Vue.js をアップデートするだけでパフォーマンス向上が期待できる模様。ぜひ使ってみたい。あと、個人的にはテスト関連のセッションがとても参考になりました。過去に自分が書いたテストは方向性としては決して間違ってなかったけど、足りてないところや改善できるところがまだまだたくさんあります。

Nuxt.js はまだちゃんと使ってないので、勉強中。

あと、Web Components や Micro Frontends あたりもなかなか興味深かったです。要復習。他のセッションも資料が公開されてるものがあるので、あとで読む。

というか、本当にもっと英語力を鍛えなくては...。

Spring Fest 2018 に行ってきた #jsug

Spring メモ

Spring Fest 2018 に行ってきました。簡単に所感をまとめます。

springfest2018.springframework.jp

今回参加したセッションは以下の通り。メモから抜粋。(スライドのリンクは随時更新します)

KEYNOTE

  • Spring ユーザーの4分の3は Java 8
    • Java 7 は2割くらい
  • Spring のベースラインは LTS の Java バージョンに合わせる見通しか
    • 中間の Java リリースに対応できるように Spring もシームレスにアップデートしていく
  • GraalVM (Substrate VM)
  • Kotlin が伸びている (Android 開発によるもの)
    • メジャーな JVM 言語になる可能性あり
    • ネイティブライブラリが使える
    • さまざまなエコシステムの開発に使える
    • 記述の簡潔さ、immutable、静的型付け
  • Spring 5.1
    • 5.0 => Java 8
    • 5.1 => Java 8, 11
    • Java 9, 10 はベストエフォートでサポート
    • 5.1 を使うだけで省メモリ、高速化が可能
  • Spring Boot 2.1
    • Java 11 サポート
    • Spring Data JDBC starter
    • 起動時間短縮、パフォーマンス改善、省メモリ
  • Kotlin サポート
    • Spring 5.2 / Kotlin 1.3 ベースライン
    • Coroutines サポート
    • モバイル領域の言語なので省メモリで高パフォーマンス
  • GraalVM
    • Spring 5.1
    • ミリ秒レベルで Spring Boot アプリケーションが起動できる
  • R2JDBC ★
    • リアクティブプログラミングサポート
    • ブロッキングな JDBC の代替
    • Reactive SQL SPI (experimental)
    • PostgreSQL ドライバのみ (他は今後サポート予定)
    • Spring Data R2DBC
    • 検索結果が Stream (Flux, Mono) で返る
    • Database Client で functional に書ける
  • RSocket
  • Spring Fu ★
    • incubator intended to mature experimental
    • Spring Boot 2.1 より省メモリで高パフォーマンス
    • Kofu Configuration
      • functional に configuration できる

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

www.slideshare.net

  • 支援ツールを内製化して運用作業を自動化
  • サービス監視
  • 開発支援
  • Pivotal Cloud Foundry ★
    • Pivotal Container Service (Kubernetes)
    • Pivotal Application Service
    • Pivotal Function Service
  • 抽象化レイヤが違う、サポートしているプラットフォームが違う
  • PAS を使うことでデプロイ速度向上が可能 (1min)
    • ベンダー&オンプレだと1ヶ月以上かかることも
  • 開発チームの責任分担
    • 12 Factor App に従う
    • ベンダーロックインはない
  • PAS 以外のコンポーネント(VM)は BOSH で管理
  • Dev, Prod の2環境
    • Dev で問題ないものを Prod にあげる
  • API Gateway に Spring Cloud Gateway の ProxyExchange (ユーティリティ) を使っている
  • Hystrix で Circuit Breaker
    • ある決済機関で発生した障害が API Gateway まで伝搬しないように
    • 処理がブロックされてスレッドが枯渇する
  • 非同期処理は RabbitMQ + Spring Cloud Stream
    • ある加盟店で障害が発生したときはキューに退避して再送する
    • Hystrix で Circuit Breaker
  • PCF App Autoscaler
  • 12 Factor App ★
    • ログは標準出力に出力すればプラットフォーム側で集約
    • ロストしたくないログはRDBに保存する
  • JMeter による E2E テスト
    • JMeter の HTML レポートが意外と使える
  • Java の複数バージョンでのユニットテスト
    • Docker イメージを使って各バージョンでテストする
    • アップデートの弊害を早期に検知する
    • 複数バージョン同時にテストできるCI環境
    • 簡単にデプロイできる Dev / Staging / Prod 環境
  • Observability
    • Metrics, Tracing, Logging
    • Grafana (Micrometer)
    • Kibana
    • Zipkin
      • サービス跨ぎでどこの処理に時間がかかっているか分かる
      • SQLの実行時間を確認できる

Spring ♥ GCP ー Spring と GCPの素敵な関係（アプリ実行環境としてのGCPを考える）

  • GCP を使うメリットはスケール感
  • Cloud Function は Java 未サポート
  • App Engine
    • 2番目にサポートした言語が Java
  • フレキシブルの中身はVM
    • 起動に時間がかかる
  • スタンダードはサンドボックス
    • フレキシブルより使えるライブラリに制限が多い
    • ランタイムのサポートを広げる (普段のランタイムと同じように使えるように)
    • スタンダード第二世代 (Java サポートあり)
  • App Engine にデプロイするときは war でパッケージングする
    • ランタイムが Jetty なので
  • アプリのモジュール化
  • App Engine 上でバージョニング
    • Splitting Traffic
    • 新旧バージョンでリクエストを振り分ける
  • GKE
    • zero-ops を目指す
    • master ノードは Google がメンテする
    • worker ノードはオプションを提供している (オートスケールなど)
    • アプリケーションがコンテナ化されていること (Docker)
    • Container Registry に登録されていること
    • Docker 化されたアプリは pod という単位で扱われる

Amazon Cognito使って認証したい？それならSpring Security使いましょう！

www.slideshare.net

  • Core, Web, Config
  • SecurityFilter は複数ある
    • Security Filter Chain
    • 実行される順序は決まっている
  • AccessDecisionVoter ★
    • Voter は複数持てる
    • Voter の投票結果から Manager がアクセス権を判断する
    • Manager も複数ある
  • Amazon Cognito
  • 認証成功でユーザープールトークンが返る
  • アクセストークン
    • JWT
    • 有効期限は1時間、切れたら更新トークンを使って更新する
  • アクセストークン検証
    • JWTの構造、署名、クレーム
    • 何を認証するかは Cognito のリファレンスを参照
  • テストでは MockMvc に SecurityFilter を追加する
  • メソッドセキュリティ ★
    • メソッド呼び出しのレベルでアクセス制御する
    • Post... は戻り値に対してチェックする

Pivotal認定講師が解説！基礎からのOAuth 2.0とSpring Security 5.1による実装

  • 認可サーバーがアクセストークンを発行する
  • Keycloak
    • SSO基盤
    • OAuth2, OpenID Connect をサポート
  • 認可コード
    • 認可サーバーからアクセストークンをもらうときに使う
      • アクセストークンをブラウザに保持させたくない
    • クライアントは認可コードと引き換えにアクセストークンを受け取る
      • アクセストークンを持ってリソースサーバーに問い合わせる
  • どのように認可するかは未定義
    • 開発者が自作するか、ライブラリ依存
  • クライアント > 認可サーバー への認証がある (ベーシック認証)
  • アクセストークンが本当に認可サーバーから発行されたものかチェックする必要がある
    • 認可サーバーに問い合わせてアクセストークンを検証
    • スコープをチェックしてレスポンスを返す
    • チェックの方法は OAuth2 で未定義 (何かしらの形でチェックせよとしか書いてない)
  • JWT
    • 電子署名は認可サーバーの 秘密鍵 で暗号化される (認可サーバーの 公開鍵 で復号する) ★
    • 本来の秘密鍵/公開鍵の使い方とは逆
  • JWK: 公開鍵を算出するための情報群
  • JWT を使うときはアクセストークンの有効期限を短くする ★
    • 認可サーバーに問い合わせないため、認可サーバー側では無効化することができない
    • リフレッシュトークンでリフレッシュする
  • Spring Security
    • 認可サーバーは OAuth2 未対応
    • 5.2 以降？

Spring Boot with Kotlin, functional configuration and GraalVM

  • Kotlin
  • WebFlux, Spring Data Reactive
  • Spring Fu
    • faster, lighter な Spring Boot
  • Lambda を lazy な factory bean として使う
  • Auto Configuration を functional bean として使う
  • セルフドキュメンテーション
  • Kofu, Jafu
  • functional に configuration する
  • Reactive API vs Coroutines API
  • Spring Boot & GraalVM

業務で使いたいWebFluxによるReactiveプログラミング

スライドが公開されたら要復習。

所感など

前回は Spring 5 がリリースされたあとだったので、そのあたりの話題で盛り上がりましたが、正直、今回は前回ほどの目新しい情報はないかなとか思ってました。が、いろいろと実験的な機能含めてどんどん新しい機能が追加されている/今後追加されていくようで、キャッチアップするのが大変そう...。とはいえ、今後の Spring の動向が知れてよかったです。今後の Spring において優先度の高い観点としては、簡潔さ、容易さ、省メモリ、(起動時間含めて) 高パフォーマンスあたりであると思われます。特に Spring アプリをコンテナ化したときに必要に応じてすぐに立ち上がることは大事。

いよいよ R2JDBC で DB 側がリアクティブサポートされるようです。ただ、WebFlux あたりはあまり使ったことがないので、要復習。あと、WebFlux は js フレームワークと組み合わせたときはどうなるんだろうか。要調査。

Kofu, Jafu の話はきちんと理解できず。要復習。

Google の話は聴いてよかったです。最近は AWS ばかり調べてましたが、Google のクラウドサービスもウォッチした方がよさそう。

メソッドの命名にはオーソドックスな単語を使おう

雑記

これの補足ですが、処理の内容を端的な名前で表現できないとき、必要以上に複雑さを抱えている可能性があると考えていいと思います。なので、calculate みたいなやや抽象的なメソッド名を業務ロジックの中に見つけると不安になります。あと、execute とか、バッチアプリケーションのエントリポイントとかであればいいんですが、個人的にはこれも業務ロジックの中には出てきて欲しくない名前です。

そして、だいたいそういう名前のメソッドは処理が長くて多くの責務を持っている傾向にある気がします。一般的によく使われる単語で端的に名前が付けられないときは一旦立ち止まって考え直した方がよさそうです。あと、createXxxYyyZzz みたいに目的語(？)が多いときとか。

これらは設計の見直しやリファクタリングのサインになるわけです。

その他

自分はあまり見かけることはないですが、参照系のメソッドには副作用があってはいけません。あと、処理に必要なデータが存在しない場合、デフォルト値を返すか、例外とします。安易に null を返してはいけません。

find 系のメソッドは検索を伴い、リストを返します。条件に一致するものがなければ空のリストを返します。Optional を返してもいいと思います。null を返してはいけません。

delete は完全な削除、remove はある集合から取り除く、別の領域に退避するようなイメージです。ここは意識的に使い分けたいところ。

現場からは以上です。

Java EE (Jakarta EE) 周りの名称や用語のメモ

Java

Java EE (Jakarta EE) 周りで似たような名称や用語によく出会うので、簡単に調べてまとめてみました。個々の詳細や比較については書いてません。また、間違ってる箇所があるかもしれません。他にもいろいろあるので随時追記していこうと思います。たぶん。

Java EE / Jakarta EE

Java Platform, Enterprise Edition の略。旧称は J2EE。エンタープライズアプリケーション開発で利用される機能の仕様をまとめたもの。2017年に Oracle から Eclipse Foundation に移管されて、Jakarta EE に改称。

Web Profile は Java EE の一部の仕様を抜き出した(？)もの。

EE4J は Jakarta EE を管理するプロジェクト。これは Java EE の頃から同じ模様。Eclipse Enterprise for Java の略。

GlassFish

Java EE アプリケーションサーバー。Java EE から Jakarta EE の改称に併せて、Eclipse GlassFish に改称。

WebLogic

Java EE アプリケーションサーバー。正式名称は Oracle WebLogic Server。GlassFish とは別のものと捉えてていいと思われる。

MicroProfile

Java EE をベースにしたクラウドやマイクロサービス向けの仕様。Java EE の一部ではなく、補完するものという位置付けの模様。現在は Eclipse Foundation で管理されている。なので、正式名称はおそらく Eclipse MicroProfile と思われる。

Payara / Payara Micro

GlassFish ベースのアプリケーションサーバー。Payara Micro は、Eclipse MicroProfile 互換で、クラウドやマイクロサービス向けのアプリケーションサーバー。

JBoss / WildFly

Java EE アプリケーションサーバー。商用版は Red Hat JBoss Enterprise Application Platform で、OSS 版は WildFly と呼ばれる。WildFly の旧称は JBoss Application Server。

WildFly Swarm は Java EE アプリケーションを実行可能 jar として生成できるもの。現在は Thorntail という名称らしい。

WebSphere

IBM の Java EE アプリケーションサーバー。正式名称は WebSphere Application Server。

WebSphere Liberty / LibertyProfile

WebSphere Application Server の一部で、アプリケーションサーバーの ランタイム。

Open Liberty

WebSphere Liberty の OSS 版。

補足

Tomcat や Jetty は、JSP や Servlet など Java EE の一部を実装したもの。なので、Java EE アプリケーションサーバーではない。

GraphQL を Spring Boot で試してみる 1

GraphQL Spring

最近、GraphQL が気になっています。学習を兼ねて簡単なサンプルを作ってみようかと。今回、Spring Boot で Query を試してみます。

サンプルコードはこちら。

kntmr/playground/graphql-spring-examples - GitHub

GraphQL

graphql.org

2015-2016年頃に登場してしばしば名前を見かけることはあったのですが、自分の観測範囲ではあまり盛り上がりを感じられず...。ただ、REST API の煩雑なところをいい感じに解決してくれそうで、今さら魅力を感じるようになってきました。

よく言われる GraphQL の特徴は以下のあたりかと思われます。

  • エンドポイントを1つにまとめることができる
  • 1リクエストで必要なデータを取得できる
  • スキーマファースト (ドキュメントファースト)

とはいえ、レスポンスとして返して欲しいデータをリクエストで指定したり、Swagger などを使うことで同等のことは実現できるかと思います。ただ、当然、サーバー側でそれなりに実装したり、ツールを導入する手間はかかるわけで、そのあたりは GraphQL を使うメリットになりそう。あと、今回は試してないですが、コードを自動生成するツールもあるようです。

あと、AWS がマネージドサービスとして提供するようになったので、今後、適用事例も増えていくんではなかろうかと思っています。

aws.amazon.com

以下、備忘録。

依存ライブラリ

GraphiQL を追加すると、/graphiql で GraphiQL が使えるようになる。

<dependency>
    <groupId>com.graphql-java</groupId>
    <artifactId>graphql-java-tools</artifactId>
    <version>5.2.4</version>
</dependency>
<dependency>
    <groupId>com.graphql-java</groupId>
    <artifactId>graphql-spring-boot-starter</artifactId>
    <version>5.0.2</version>
</dependency>
<dependency>
    <groupId>com.graphql-java</groupId>
    <artifactId>graphiql-spring-boot-starter</artifactId>
    <version>5.0.2</version>
</dependency>
schema / データクラス

resources/graphql/schema.graphqls にスキーマを定義。データクラスでは、参照先のクラス側に ID のフィールドを定義する。今回のサンプルでは、あるグループに所属するユーザーの ToDo リストを返すことを想定。

type Group {
    id: ID!
    name: String!
}
type User {
    id: ID!
    name: String!
    group: Group!
    todos: [ToDo]
}
type ToDo {
    id: ID!
    content: String!
    completed: Boolean!
}
DAO / Resolver

DAO は適当にダミーデータを返すように実装。Resolver は、Query の場合は GraphQLQueryResolver インタフェースを実装する。

@Component
public class UserQueryResolver implements GraphQLQueryResolver {
    private UserDao userDao;
    public UserQueryResolver(UserDao userDao) {
        this.userDao = userDao;
    }
    public User getUser(int id) throws Exception {
        return userDao.findById(id).orElseThrow(() -> new Exception("User not found."));
    }
}

データの関連を解決する場合は GraphQLResolver<T> インタフェースを実装する。今回、グループとユーザーの関連を解決する場合は次の通り。

@Component
public class GroupResolver implements GraphQLResolver<User> {
    private GroupDao groupDao;
    public GroupResolver(GroupDao groupDao) {
        this.groupDao = groupDao;
    }
    public Group group(User user) {
        return groupDao.findById(user.getGroupId()).orElse(new Group(0, "Undefined"));
    }
}

ユーザーと ToDo の関連を解決する場合は次の通り。

@Component
public class TodoResolver implements GraphQLResolver<User> {
    private TodoDao todoDao;
    public TodoResolver(TodoDao todoDao) {
        this.todoDao = todoDao;
    }
    public List<ToDo> todos(User user) {
        return todoDao.findByUser(user.getId());
    }
}
リクエスト

アプリを起動して、http://localhost:8080/graphiql にアクセスする。以下の形式でリクエストする。指定したフィールドをレスポンスで返してくれる。

query {
  getUser(id: 1) {
    id
    name
    group {
      id
      name
    }
    todos {
      id
      content
      completed
    }
  }
}

所感

今回は簡単なサンプルでしたが、スキーマが複雑になるほど必要なデータクラスや Resolver が多くなりそうです。ただ、このあたりは自動生成のツールを使うことで解決できるんだろうか。スキーマファーストというだけあって、やはりスキーマの設計がキモなんだろうと思われます。いかに無駄なくシンプルに設計できるか。

次は Mutation を試してみようかと。あと、全体的にまだ理解が浅いのでドキュメントを読んで勉強する。その他、自動生成などの開発ツール周りを調べたい。

参考

JJUGナイトセミナー「JDK 11リリース記念：今知っておくべきJDK 11の重要ポイント」に行ってきた #jjug

Java メモ

先日、JJUGナイトセミナー「JDK 11リリース記念：今知っておくべきJDK 11の重要ポイント」に行ってきました。簡単に所感をまとめます。

jjug.doorkeeper.jp

メモから抜粋。(詳しくは資料をご参照ください)

Java Is Still Free

Java Is Still Free の翻訳がついに来た。ありがたい。

www.sakatakoichi.com

JDK 11 リリースなので改めて「新しい JDK リリースモデル解説 (サマリー&アップデート)」

www.slideshare.net

  • Oracle OpenJDK
    • GPLv2 + Classpath Exception
    • オラクルによるセキュリティアップデート提供
  • Oracle JDK
    • 今まで(v9/v10)までのライセンスと少し違う
    • 商用ライセンス or OTNLA for Oracle Java SE
    • JDK11以降は社内もしくは個人での開発/テスト/試作/デモの用途では無償で利用可能
  • OTNLAが6ヶ月で切れるかどうかは未定 (LTSと同期間になる可能性はある)
  • JMCは個別にダウンロードできるようになる
  • Subscription
    • Javaが実行される可能性のあるすべてのハードウェアが対象
    • デスクトップとサーバーが対象 (クラウド含む)
    • Named User Plus (1台から購入可能、個人でも購入できる予定)
    • Processor

Java 11 : サポートとVM機能編

www.slideshare.net

サポート

  • 開発サポート
    • OpenJDK コミュニティ
  • 配信サポート
    • OpenJDK コミュニティは配信はしていない
  • 問い合わせサポート
  • AdoptOpenJDK
    • 配信サポート期間が一番長い(4年)
  • OpenJDK の開発サポートは現時点では3年間
    • 今後より長くなる可能性もある
  • Oracle JDK から OpenJDK のマイグレーション
    • 証明書周りがネックになるかも (配信元による)
    • だいたいはライセンスの問題
  • AdoptOpenJDK のリリースが遅れているかのは大丈夫か
    • テスト期間があるので1-2週間は遅れる
    • ゼロデイ攻撃が心配なら Oracle OpenJDK の利用を検討する
  • JRE
    • コンテナなどで、バイナリサイズを削減したいなら jlink を使う
    • モジュール化が進むとより効果がありそう
  • 特に理由がなければ OpenJDK の開発サイクルが短いバージョンは無視してOK
  • 多くの場合、必要なのは配信サポート
    • AdoptOpenJDK が4年なのでマイグレーションに1年の猶予がある
    • 問い合わせサポートは予算とSLAに依存する

VM機能

  • JEP 330
    • ソースファイルを java コマンドで実行
    • Java ソースをスクリプトのように扱う (バージョン指定可能)
  • JEP 328 (Flight Recorder)
    • プロファイラ
    • Oracle JDK のものとはオプション構成が違う
  • JEP 318 (Epsilon)
    • No-Op GC
    • 主に開発や研究用途を想定
  • JEP 333 (ZGC)
    • アプリケーションスレッドとGCスレッドの並列化
    • 従来のGCとはアルゴリズムが異なる (世代別GCではない、など)
    • 64bit, Linux 限定

Java 11 : APIの変更点編

  • JEP 181 (Nest-Based Access Control)
    • Nestmates
    • 第5のアクセス制御 (インナークラス間の private メンバ参照)
    • NestHost, NestMembers
  • JEP 309 (Constant Dynamic, condy)
    • Constant Dynamic が Constant Pool に入る
    • static final フィールドではなく、class-file 上の定数
  • JEP 320
    • Java EE & CORBA 関連モジュール削除
    • Maven artifact を使う
  • JEP 321 (HTTP Client)
    • モダンな API, HTTP2, Reactive
    • 非同期呼び出しの場合は Flow が返る
  • JEP 323
    • ローカル変数の型推論が Lambda で使えるように

API

  • trim は全角空白は取れないが、strip は全角空白が取れる
  • Collection#toArray が IntFunction を取るように
    • List.of("aaa").toArray(String[]::new) (要素数を指定せずにメソッド参照で書ける)
  • Predicate.not
    • 今までメソッド参照が使えなかったところが使えるように (String::inEmpty とか)
  • 新元号対応 (Japanese Era)
    • "JapaneseEra.HEISEI 31/5/1" 以降を指定するとエラーになる
  • += のバグ
  • TimSort

JDK12

  • JEP 326 (Raw String Literals)
    • バッククォートで囲む
    • 変数の埋込は今のところない
  • JEP 325: Switch Expressions

さり気なく JShell のバージョンが JDK 12 っていうのがなんとも。

Developers.IO 2018 に行ってきた #cmdevio2018

AWS メモ

先日、Developers.IO 2018 に行ってきました。

dev.classmethod.jp

セッションレポートと発表資料は以下にまとめられています。

Developers.IO 2018 セッションレポートと発表資料まとめ #cmdevio2018

今回参加したセッションは以下の通り。最後までいるつもりだったけど、16時過ぎで体力切れ...。無念。

1000件以上の活用を見てわかった絶対に失敗しないAWSベストプラクティス

おなじみの AWS Well-Architected Framework の話です。

基礎から応用までじっくり学ぶ「AWSでのネットワークの作り方」

ネットワーク関連はあまり知見がないため、基礎の部分はとても勉強になりました。最後の方は若干理解が追い付かず...。

クラスメソッドにおけるWeb APIエンジニアリングの基本的な考え方と標準定義

今回聴きたかったセッションの1つ。API アクションやユースケース、パス、リソースなど、Web API を検討するときにどういうことを考えるのか、とても参考になりました。CQRS のエッセンスを取り入れるのはいいけど、例えば、RDB から ES に大量にデータを連携するときにタイムラグは発生しないのだろうか。

あと、クラスメソッドさんもドキュメントに GitBook を使っているということを知れてよかったです。自分のプロジェクトでも使ってるけど、あまり開発がアクティブじゃないっぽくてちょっと不安になってたのでｗ

dev.classmethod.jp

次世代モバイル向けクラウドサービスAWS AppSyncを使って店舗スタッフと顧客の体験を最大化する方法

最近、GraphQL に興味があって、今回聴きたかったセッションの1つ。スキーマをもとにコードを自動生成するツールが豊富というのはちょっと意外でした。GraphQL 自体の前提知識は必要なものの、スキーマファーストの開発は確かに効率がよさそう。

AWSのセキュリティ設定がどうなっているか抜け漏れなくちゃんと確認する方法

責任範囲の理解、現状把握、対策。必要に応じてツールや専門家を活用する。あと、初めて生の徳丸さんを観ました。徳丸本第2版ポチるか。

ビジネスを阻害しない！AWSアカウントのID・権限管理について

IAM の構成要素やベストプラクティスの話。AWS を使う上で特に重要な内容の1つだと思います。要復習。

その他

ありがたいことにほとんどの資料はすでに公開されています。今回参加できなかったセッションの資料もあとで読もうと思います。