読者です 読者をやめる 読者になる 読者になる

40代からのフロントエンドエンジニアリング。

フロントエンドを中心に、Web関連話をゆるく書いていきます。

関西フロントエンドUG勉強会「フロントエンドの人がWeb APIを語る会」

関西フロントエンドUGの6月勉強会「フロントエンドの人がWeb APIを語る会」。

3月の「FRONTEND CONFERENCE」に参加して以降関西フロントエンドUGの勉強会には参加したいと思っていましたが、なかなか予定が合わず。今回は予定は空いていたものの早々と参加者枠は埋まっていました。ただ「ブログ書く枠」が空いていたのでそこに潜り込むという姑息な方法で参加いたしました。

で、勉強会後公私共にいろいろあってなかなか書けず遅くなってすみません。

今更ながら報告ブログです。

※リンク、スライド等は既にアップされている狩野さんのブログから拝借させていただきました m(_ _)m


関西フロントエンドUG勉強会「フロントエンドの人がWeb APIを語る会」

2016/06/11(Sat.) 15:10〜18:10 TAM コワーキング

f:id:mntp:20160703125139j:plain

実はTAMさんに行くのは初めてでした。南森町で降りててくてくと。

※転職時に某サイトから応募したのですがお祈りm(ry

発表者が遅刻というハプニングでスタートは10分遅れ(苦笑)。

今回のテーマは「Web API」。フロントエンドを始めてから、というかWeb中心の業務に入ってからはそんなに経っていないのでまだほとんどWeb APIを使っていないのですが、今後の参考になる……といいな。

Falcorについて

pastelIncさん

動画配信のNetFlixが開発した、JSON Graphでデータをやり取りして透過的、効率的な通信を行おうというOSS「Falcor」の紹介。GitHubでも公開されています

【概要】

  • Netflixが開発したOSSJavaScriptで書かれている。
  • バージョンは……あれ、1.0.0がリリースされている!?(スライド作成時は0.1くらいだったらしい)
  • 効率的にデータを取り出しやり取りする
  • 今までは1つのAPIですべてのデバイスとのやり取りをしていた
  • 単一のJSONモデル(JSON Graph)に集約、すべてのやり取りを行えるようにする
  • ローカルのキャッシュにパスがないときには問い合わせる
    →通信回数を少なく、データ量を少なくより効率的に
  • Falcorを使うと
    • JSON Graphとパスを使うことで透過的な通信
    • JSON Graphとパスを使うことで効率的な通信
    • 使い方を覚えるのは簡単

【感想】

たしかに透過的、効率的な通信は行えそうではあります。1.0になったばかりで普及していくのはまだまだこれからといったところだと思いますが今後も要注目でしょう。

WordPressAPIでぶん回す

岡本秀高さん

【感想】

まあ私もPHPには苦戦しております(;´∀`)
特に最初のWordPressあるあるには……秘伝のタr(げふんげふん)

ともあれ、WP REST APIPHPから解放される日が来る……のか。来て欲しいです。

まだβ版ですが遊びたい方はこちら → WP REST API v2 Documentation

GitHub Pages を Web API として使う

Kiteさん

【感想】

GitHub APIもJekyllもRakefileもいじったことはないのですが(すみません)、慣れれば面白そうかつ便利そうという感触はありました。

学習コストも高くないようなので……時間があればトライしてみようかなと思います。

REST APIなんてもういいですから(GraphQLについて)

おのうえさん

Facebookの提唱するクエリインタフェースの仕様「GraphQL」について。

【概要】

  • 従来のWeb APIだとユーザーテーブルをフロントエンドで実装するのは意外と面倒
  • 最大公約数的なAPI
  • ページごとに乱立するAPI
  • 通信、開発コスト増
    →無秩序に拡大されていくAPI

そこで「GraphQL」

  • Facebookの提唱するクエリインタフェースの仕様
  • graphql.jsもFacebookから公開
  • 入力→結果を試せるサイトも有り
  • クエリが構造化され簡単にできるようになる

メリット

  • 従来のREST APIの弱点を改善する→通信量の増大を防止
  • 柔軟なクエリインタフェースを低コストで実装

まとめ

  • フロントエンドフレンドリーで柔軟なWeb APIを構築
  • クライアントサイド、サーバーサイドそれぞれで比較的自由に構築可能
  • Scala実装もあるよ

【感想】

最初のFalcor同様、データ構造を統一化して透過的、効率的な通信を目指そうというものという認識でいいのでしょうか。確かに便利そうではありますが、既存のものを置き換えるとなると時間がかかるかもしれません。

[LT] Lambda+GItHub+Travis CIで全自動サーバーレスAPI

宮内さん

【感想】

自治体がダメだから自分で作ってしまおうという行動力。そして、郵便番号のデータを提供するサービスはいくつか見たことがありますが、データはコロコロ変わりますし今回のように自動でダウンロードしてGulp等で全自動化するというのはいいですね。

問題は日本郵便のデータのURLが変わってしまった時どうなるかですが、まあさすがにそれはないでしょうと思いたいです。

[LT] Node.jsでWebサイトからAPIを作るプログラムを書いた話

potato4dさん

【感想】

とりあえずWebサイトで公開されているデータとNode.jsとやる気があればなんとかなる。多分。

[LT] 行政のCSVファイルを勝手にAPIにした話

岡本秀高さん(二度目の登場)

【感想】

こちらもWebサイトで公開されているデータをJavaScriptでいじる話。たった26行のコードでも喜ばれるのでみんなやってみましょう(・∀・)

[LT]mocha + superagent + power-assert で始めるAPIテスト入門

後藤知宏さん

qiita.com

【感想】

JavaScriptでテストを書けるのであればいま業務で開発しているシステムのテストにも使えるかなぁと思ったり思わなかったり。いろいろ用途はありそうです。


ざっくりまとめ。

最初に書いたように今の業務がフロントエンド側中心なのでWeb APIはほとんど触っていないのですが、今後役に立って行きそうなもの、面白そうなものなどいろいろあって参考になりました。

書いていて気づいたのですが、LTの4人中3人が「Webサイトからデータをダウンロードしてごにょごにょ」という話だったのは興味深いです。私も作りたくなってきました(・∀・)

ということで参加者の皆さん、お疲れ様でした&ありがとうございました。