LINE Engineering
Blog

今更話す、Messaging APIのNode.js版SDK開発

全賢濟 2017.12.04

LINEでフロントエンド開発を担当しています。プログラミング言語に興味を持っています。

こんにちは!LINEでフロントエンド開発を担当しているJunと申します。この記事はLINE Advent Calendar 2017の4日目の記事です。今日はMessaging APIのNode.js版SDKの開発について書きたいと思います。Node.js版SDKのv1.0がリリースされてもう半年以上、今更感がすごくありますが、開発前から今にかけて面白かったことや工夫したことをいろいろ紹介します。

開発のはじまり

Node.js版の開発が始まろうとしていた当時、Messaging API SDKが対応している言語プラットフォームは以下の6つでした。

  • Java
  • Perl
  • Ruby
  • Go
  • PHP
  • Python

各SDKの開発は担当のチームがあるわけではなく、その言語に興味を持っている社内の人がボランティアで開発していました。そしてNode.jsはどんな感じだったのかというと…

誰か書いてくれ~
(社内WikiのMessaging API FAQから)

…という感じでしたね。SDK開発自体はもちろん誰でも参加できる雰囲気ですが、そのプラットフォームの経験があまりないと後のメンテナンスが難しくなるため、Node.jsの経験が豊富なエンジニアが必要な状況でした。そこで普段Node.js環境で作業しているフロントエンドチームが一番適任だったということですね。

開発はフロントエンドチームで行うことになったとして、誰がリードして開発するかという問題が残っていました。幸運なことに、私は以前個人的にSDKのHaskell版を開発していまして、SDK開発グループには参加している状態でした。Haskell版は全然使われなかったのですが、グループに参加しており仕様を把握していたことから、Node.js版の開発を担当するようになりました。Haskell版を開発してよかったです。めでたしめでたし。

Node.js

Node.js版欲しい!

…と言う声は外からも中からも前から聞いていました。実は内部的にはLINE TaiwanのGeorgeさんが作業したリポジトリがもうありましたので、それをベースとして作業することにしました。

Node.jsの開発は環境セッティングとツールの選択から始まるので、どれを使うかによって開発の方法や方向がだいぶ変わります。ボランティアで作業するOSSはメンテナンスしやすいことが一番重要です。そのため、環境の選択で一番力を入れたのは、今後のメンテナンスに手間がかからず、誰が参加しても作業しやすい環境を作ることでした。その結果、以下のような構成になりました。

  • TypeScript:作業者が迷わず作業できるようにするためには型情報があって補完がよく動くのが一番だと思いました。
  • TSLint:コードスタイルの強制を人間がいちいちチェックしては続けられません。ちなみに今はPrettierを使っていて、コードフォーマットも行っています。
  • Express:Expressサーバを直接提供すると、ユーザーの選択肢を制限してしまいます。そのため、最小限の関数と共にConnectミドルウェアだけを提供するようにしました。
  • Mocha:テストにはMochaを使いました。ts-nodeでTypeScriptでも問題なく使えます。
  • GitBook:OSSで読みやすいドキュメントは重要ですね。Markdownから自動生成します。

上の構成で、今でも結構満足しながら開発をしています。新しくOSSを始まる際に試してみてください。

TypeScript

Node.js版の開発でTypeScriptを使った経験については、11月に開催された東京Node学園祭2017でも発表してきました。TypeScriptを使った理由は、ざっくり言うと「使った方が楽だから」です。「型を使うとむしろいろいろ面倒臭くないか?」と思う方もいらっしゃるかも知れませんが、実はその逆です。TypeScriptは以下の2つの点で役に立ちました。

  1. 型とその補完のおかげで開発途中でミスをしない。
  2. 型のおかげで不要な抽象化を減らせる。

特に、抽象化を最小限にできると、管理するコード量が減って構造が簡単になるので、こういう規模のOSSでは一番魅力的な要素だと思います。詳しい内容はNode学園祭での発表資料を公開していますので、以下の資料をご覧ください。

開発からリリースまで

LINEではOSSリリースの時、以下のようなプロセスを通るようになっています。

  • コードレビュー
  • セキュリティーレビュー
  • ドキュメントレビュー
  • ライセンスレビュー
  • 特許チェック

いろいろプロセスが多いので、実はここが一番大変でした。でもOSSを出す時にきちんと考慮しなくてはいけない部分を丁寧に見てもらえるのは、開発者としては嬉しいことだと思います。

上のチェックが全部終われば、やっとリリースです。お待たせしました。リリースはGitHub EnterpriseのリポジトリをGitHubに移すだけですが、内部開発時のcommitはsquashして出しました。

initial release

移した後はリポジトリを公開して、npmに公開して、ドキュメントなどのマイナーな修正をして、リリース完了です。

リリースから今まで

リリース後はだいたい以下のような作業を続けています。

  1. APIの変更・追加に対応
    • トークルームやグループからユーザーを特定するAPI
    • トークルームやグループのユーザーリストを取得するAPI
    • 新しいメッセージやテンプレート
    • リッチメニューAPI
    • などなど
  2. バグの修正
  3. 型の改善
    • Tagged unionの導入
    • 型exportの改善
  4. 開発環境の改善

上の変更を含め、105回のcommitと9回のリリースがありました。今まで貢献してくださった方々に感謝です。

project status

リポジトリはGitHub LINE organizationに公開されています。もし興味がある方はご覧ください。そしてスターも付けてくださいね。

最後に

ここまで読んでいただいてありがとうございます。以上がSDK Node.js版開発のほぼ全てでした。開発の過程で個人的に一番嬉しいのは、やはりコミュニティーの方々からissueやpull requestをいただくことです。これからも全力でサポートしますので、ぜひ開発に参加してみてください。

明日はsuzuki-shunsukeさんによる「Jenkinsに代わるGo製OSS CIツールDrone」の記事です。お楽しみに!

AdventCalendar

全賢濟 2017.12.04

LINEでフロントエンド開発を担当しています。プログラミング言語に興味を持っています。

Add this entry to Hatena bookmark

リストへ戻る