user
Shun Namiki

Freelance full-stack Endigneer @ Shibuya, Japan

Published on Nov-24th, 2018 ( 11 min read )

東京Node学園2018(Conference@JP)のまとめ(その2)

前回の続き

👍 WebアプリをNativeアプリにする Capacitor が広げるWebの可能性 by 榊原 昌彦

1. 前提:Cordovaでの開発の課題

  1. バージョン:ビルドバージョンを整えるのが辛い
  2. プラグイン:作るのが大変
  3. デザイン:スマホデザインを真似ているコピーなのでネイティブAPIのデザインが変更されるとここもメンテしないといけない、という危険性がある。
  4. 開発スピード:OSSなのでクリティカルな脆弱性への対応がクイックでない

2. Cordova(コルドバ)の後継であるCapacitorについて

  • HTML5でのWebアプリ開発

    • SPAで作成される
    • 「WebView」+「ネイティブ機能へのアクセス用API」の組み合わせ
  • Capacitorとは

    • Ionic チームの考える最強のCordovaがCapacitor
    • Capacitorの中でNativeAPIを使う
    • NativeAPIとWebViewを部分的に使い融合
    • cordovaよりplugin作成が圧倒的にスマート
    • cordovaプラグインもサポート
    • vs ReactNative:RNはjavascriptCore / native script runtimeを通してswiftにコンパイルされる
  • レスポンス速度

    • HTML5は遅くはない。ただ早くもない
    • Facebookレベルのアプリケーションなら十二分の速度となる実装例もある
    • HTML5遅い説の根拠の大半は実装がイケてないだけのケース
  • まとめ

    • 今後は、Webページ上のPWAでポジティブな体験をしたらアプリをインストールされるようになるのではないか

所感

  • この手のネイティブへのトランスコンパイラ系は学習コストが高いイメージがありかつメインストリームがReactNativeだが他にも色々と存在して群雄割拠な構図、という印象が強くある。そのため、自分としては手を出してみたいが手を出しづらいジャンルの1つなので、手を出すならプラットフォームやFWのサイクルが落ち着いてから手を出すかなーと、どうしてもなってしまう。
  • 登壇者のHTML5 / Capacitorなどへの愛をすごく感じた

👍 実践GraphQL for クライアント側 by 鈴木 亮太

1. GraphQLとは

  • クライアント側からクエリによるサーバ側のデータ取得を実現する機構

    • Query : Get操作
    • Mutation : Get以外操作
  • データのリレーションのネストも1queryで取れる
  • 最近founddationができた

2. GraphQLを使ったプロダクト紹介

  • 広告配信システムの管理画面:GrowLio
  • 特徴:データ同士の関連がかなり多い
  • RESTfulで以前も同様のシステムを構築したが辛さがあった。

3. GraphQLで解決したこと

  1. サバ/クラのコミュニケーション

    • ☓:手動のドキュメント化
    • → ◯:コードからジェネレート可能
    • ☓:型を明確に定義をしていない
    • → ◯:GraphQLのスキーマ中心のコミュニケートになる
  2. 取得の複雑化

    • ☓:たくさんのエンドポイント
    • → ◯:1エンドポイント+スキーマでクライアントで整理可能
    • ☓:型不審
    • → ◯:型安全になりintrospection機能で型の信頼性が担保される
  3. パフォーマンスボトルネック

    • ☓:複数APIを発行するとネットワーク帯域を大きく取る
    • → ◯:ネットワークがボトルネックにならなくなった
    • ☓:不要フィールドが多くある
    • → ◯:サーバ連携なくクライアント主導でパフォーマンスチューニング可能
  4. GraphQLでなくても解決できた内容

    • ドキュメント
    • → Swagger
    • パフォーマンス
    • → BFF
    • → サバ/クラで同一言語
  5. なぜGraphQL?

    • サバ/クラが切り離される
    • 学習コストが低い
    • 学習意欲が高い
    • ブルーオーシャン
  6. GraphQLの痛み

    • エンドポイントが同一になるのでエンドポイントごとのボトルネック探し/トラッキングツールでのユーザ行動履歴が追えない、というネガティブなこともある。
  7. まとめ

    • ネガティブもあるがトータルではかなり旨味があるのでおすすめ。

4. GraphQLで工夫

  • Query / Mutationに名前をつける

    • トラブルシュート可能
    • デバッグしやすい
  • Fragmentを使用する

    • クエリの再利用性を高める
    • ライブラリ/関数経由でクエリを発行すると共通化できている風に見えるができていないケースが多い。

まとめ

所感

  • GraphQLの本番の話でまだ前例が少ないので、本番導入に対するメリデメなどの良い題材
  • 自分もGatsbyでの静的サイト作成でもGraphQLを使ったがこの規模感の実装でも「Query / Mutationに名前をつける」「Fragmentを使用する」は行っていたところもあり、これからサービスの運用・グロースを通して中〜大規模サービスならではのナレッジが生まれるところもあると思うのでそこでの気付きや工夫のナレッジに期待。

❤️ React + Apollo Client (GraphQL) により変化するアプリケーション設計 by 宮崎 優太郎

0 . はじめに

  • メルカリのシステムが古くなってきたので、最新の技術スタックにて作り直しを画策・実施しているre-architectureチームのフロントエンドの人

  • GraphQL Summit 2018行ってきたので、そこらへんのナレッジも共有

  • Redux to GraphQL

    • 「Appollo + GraphQL導入でReduxが不要になる」記事を疑いながら作ったら...
    • 本当にメルカリでもAppollo + GraphQL導入でReduxが不要になっている(ただしまだ全てをリプレイスしていないので今時点では、だが)
    • パラダイムシフトなのでFlux設計ありきで考えずに考えると良い

1. Prerequirements

  • GraphQLとは

    • 前のセッションで語られている通り。
    • 最近ではマイクロサービスのBFF / API Aggregationとしてもよく登場。
  • Apollo

    • プラットフォーマー。色々なことを提供しているが、提供しているものをわかりやすくするために3層で考えると良い

      • Gateway
      • Library ( Server/Client )
      • Development

2. Apollo Client

  • Boost

    • Link

      • サバ/クラの間を管理
    • Cache

      • キャッシュ

3. React Apollo

  • GraphQLのquery/mutationの発行を行うComponentをHoCとして提供されている
  • Local stateへqueryを発行する

5. Compare with Flux

  • Reduxはいらなくなる。なぜならクライアント側に存在するビジネスロジックの代わりにGraphQL / Apolloがその分を代替する。
  • Logic:大きく2つが存在

    1. BusinessLogic:3つが存在

      1. Data Access: RESTfulでデータ取得

        • →GraphQL Server & Apolloが取って代わる
      2. Endpoints Management :エンドポイント管理

        • →GraphQL Serverが取って代わる
      3. State Management:データの整形と保存

        • →Apolloが取って代わる
    2. Presentation Logic:表示管理

      • →Apolloが取って代わる

まとめ

  • 今まではRESTfulはアプリケーション間で異なる設計になりがちなので統一するのは、このレイヤーではできなかったがGraphQLの導入でここのレイヤーで統一化される。合わせてクライアントレイヤーでも管理をする必要がなくなるためReduxが不要になる

  • Apolloが既存のアーキテクチャを差し替えられるような良い塩梅の抽象レイヤーを提供してきたのが大きい

  • 個人的に「このApolloを利用したアーキテクチャに名称がついていない点が普及していない理由なのではないか、とも思う。また、この設計は今の主流なFlux設計などに対する次期アーキテクチャになりえると捉えている。」とのこと

  • このアーキテクチャにより、クライアントサイドで状態の関心が減り、UIのことだけに注力できるようになる

  • ただ、今回の説明のようにビジネスロジックがキチンと分割されていない状態からこのアーキテクチャを導入しても、うまくワークしない可能性もあるので注意。

所感

  • ミーハーな観点で見てGraphQL summit 2018での情報収集などをした上でもメルカリの次期システムへのリプレイスにてこのアーキテクチャを進めている現状であり、また技術的な観点で見てもReduxが不要になるというのはフロントエンドにとっては十二分な程のポジティブなニュースだと思う。総合してかなり将来性の高いアーキテクチャのように感じた。
  • また、技術的に先端の企業がアーキテクチャを先行導入して、それに対して後追いで名称がつき、その後に一般的に普及していく、という流れのケースは今までのアーキテクチャでもよくあるケースなので今回もそのケースになるだけの可能性は十二分に秘めていると思う。

❤️ 貢献できるOSSの見つけ方 -完結編- by Masato Ohba

1. どうやってOSSを見つける

  • 偶発 → 今回のセッションは対象外
  • 自発

    • 好きなプロジェクトをウォッチは長期にはベストだが短期では難しい
    • 小さいプロジェクトを狙う

2. 離脱要因

  • 「プロジェクトを選ぶ」+「課題を決める」ところが体感では一番難しい。

  • ここの壁はメンテナーとコントリビュータの不幸

3. 離脱要因を超える

  • なので、それを解決するサービス:goofiを作った。

    • good first issueというコントリビュートを求めているラベルがあるので、これで対応
    • Github issue readerのjasperとかではノイズが大きすぎた
  • 技術的な課題

    • performance / rate limit

      • GraphQLではgithub上でpointで評価している
    • →キャッシュ入れて両方解決

4. 結果

所感

  • ジョブズ風に歩くプレゼン素敵。自分的には今日の登壇者の中で最も美しいプレゼンをしていたように感じる。あと関係ないけど思想がモダンでかなり自分好みだった。

  • サービスへの共感:今回の「OSS参入障壁の問題」にまさしく自分も殺された経験があって「OSSのコントリビュートしようかな〜・・・、、、結局どのリポジトリのどの内容から入ればいいのか全然わからん」で、くじけたことがある。なのでこのサービスに対して応援したい気持ちがものすごく強いし、OSSコントリビュート経験もそこまで無いのでしばらく自分もこのサービス使っていこうと思った。

  • プロダクトのグロースがリーン開発のお手本のようだった。プロダクトのグロースの観点では、v1はcsv吐き出し見れるレベル→v2はUIの強化→v3はバックエンド強化、とリーンにサービスをグロースしており、フィードバックの観点では今回のような発表などを複数回行って顧客となる我々エンジニアからのフィードバックを取り入れているようである。

  • また、自分の感じていた課題を自分のサービスで解決していたり、自分のやってみたい技術スタックをまるっとそのサービスにブチ込むことで成長・自己満足・ポートフォリオ拡大と見事にすべてをキレイに行っている様を見ると、自分もサービスの作成をしてみたいなーとモチベーションを刺激される良い内容でもあった。

👍 Vue.js/Nuxt.js で 実現できた PWA の リアルタイム動画ラップ・バトル・アプリ by lulzneko

1. 導入

2. Vue.js/Nuxt.js で開発するスマホ向け PWA アプリ

3. サーバーレス Web API w/AWS Lambda + TypeScript

  • PWA

  • Vue.js / Nuxt.js

  • WebRTC / Skyway

  • Realtime Database

  • AWS Lambda

4. Vue.js/Nuxt.js PWA と プレゼン スライド の CI/CD

  • プレゼンスライド自体をCI/CD

    • remark.js使っているが今後はreveal.jsがデファクトになりそうな予兆はある
    • CIでのデプロイ
    • 複数人でのバージョン管理
    • エンジニアへの敷居がかなり低い
    • 作成コストもかなり早く行える
    • スライド中にiframeタグを埋め込めるのでWebアプリケーションならそのまま使える

5. まとめ

所感

  • 最近、自分もフロント学習中な点も相まって、個人開発で「如何に管理すべきサーバを減らすか?」「実装を減らすか?」の視点のプライオリティが上がってきたのもあり、登壇者達のチームのサーバーレスにこだわるスタイルはすごく魅力的に感じたし、今後も自分もその方向をアーキテクチャ選定は進めていきたいと思った。
  • また、サーバレスや外部サービスを多用することで実装量を減らす分、比例して経験量を増やすことも出来てその分が成長に繋がるのでは?と感じた
  • ハッカソンやったことないので面白そうなのでやってみたいなーと思ったが、この「やってみたいなー」から「実際にやった」までのギャップはちょっと広そうなのでまずはライトに出来る箇所を探してみたい。

🎉 総括

1. 自分の所感のまとめ

  • バックエンドとしてのNode.js話だけだと思っていたらフロントエンドとしてのJavaScriptの領域がかなり多くて意外だった。
  • 来年からJS conf(仮)となるようだが、そもそもJS conf的なのが日本でなかったことも驚きだった。
  • 毎セッションごとに移動を行う必要のあるカンファレンスが初めてだったので思ったよりも疲れた。
  • 企業の事例を生の声で多く見ることが出来るので肌感でトレンドやコミュニティの温度感を感じられるので、やはりリアルでカンファレンスに参加するのは有意義だった。
  • セッションのスキマ時間がかなりカツカツでQAタイムも特に無いので気になるところはあったがQAは出来なかった。アフターパーティーに参加して登壇者にQAしに行っても良かったと思う。この手のQAタイムが無いケースではアフターパーティーなどで登壇者にQAしにいく前提で考えていたほうが良いと思う。

2. 発表を聞いた自分のまとめ

  • Node.js:Node v10のWorkersにてシングルスレッドからマルチスレッドになる点はキチンと認識しておくべきポイントだと思う。
  • GraphQL:GraphQLを本番に導入した話やこれからリプレイスしようとしている話などが散見された。発表内容的にも大抵ポジティブな意見ばかりなのでGraphQLでの開発は今後も後追いで増えていくように思う

📊 アンケート

survey

参加者のアンケート結果。技術動向をそれなりに終えている人からすれば特に意外に思うところはないような結果だと思う。



arrow_back

Previous

HTML5Conference2018Japanのまとめ

Next

東京Node学園祭2018(Conference@JP)の1日目のまとめ(その1)
arrow_forward