コラム

キュレーションメディアを支える技術[サーバサイド編]

2016-01-20

RM STAFF

WRITER:

RM STAFF

 

こんにちは!オープンウェブ・テクノロジーという会社で、CEO兼雑用を担当している白石です。

この度は、普段からとてもお世話になっているリッチメディアさんのテックブログにデビューさせていただくことになりました。

初めての記事寄稿ということで、今回は、ぼくらが先日リリースしたTechFeedというサービスで使っている技術を軽く紹介させていただこうかと思います。

 

TechFeedはテクノロジーやプログラミングの最新情報を世界中からお届けする

ITエンジニア向けのキュレーションメディアです。

 

TechFeedの技術の裏側

 

shutterstock_209728471

 

 

と言っても、ぼくらはたった3人のベンチャー企業

新しくてワクワクするような技術にチャレンジしたいのは山々ですが、時間という貴重なリソースを、新技術の習得に使ってしまうのも悩ましい…ということで、実は割と技術的には保守的だったりします。

また今回は、キュレーションの内部的な処理などについては触れずに、ぼくらが現在使用している技術にフォーカスして執筆させていただきました。「キュレーションサービスを手掛けるスタートアップ」が実際にはどんな技術を使っているのか、そして「意外と普通」という事実をお伝えする記事になるかと思います。

そういった心持ちで、以降の文章を読んで頂けるなら幸いです。

 

Node4を採用しました

 

自分たちで作ってみて初めて実感したのですが、キュレーションサービスは、サーバサイドの処理を大量に書く必要があります。インターネット上からリソースをフェッチする、フェッチしたリソースをパースして、フィルタリングして評価する…と言った処理を、定期的にバッチプログラムを走らせて実行しています。

 

ユーザーの操作に応答するためのアプリケーションロジックの部分ももちろん重要ですが、前述のバッチプログラムが、バックエンドにおいて非常に大きなウェイトを占めています。

ぼくらは、こうしたバッチプログラムやWebアプリケーションを、全てNode.jsで開発しています。

Nodeを採用した理由はいくつもありますし、記憶もあいまいになりつつありますが、一番大きな理由としては、「メンバーがWebエンジニアばかりだった」というところが大きいように思います。

ぼくらが使用しているNodeのバージョンは4です。4は今年(2015年)の9月にメジャーバージョンアップされたばかりで、正直採用するのにはためらいもありました。そのため、つい先日まで、以前のバージョンの0.12を使っていました。

 

Node 0.12と4の一番大きな違いは、ECMAScript6 (ES6) への対応度合いです。

ES6は魅力的な新機能が満載です。特にアロー関数(functionの代わりに=>という記法で関数定義できる)やテンプレート文字列、letconst、クラス定義などが使えるのは、単に目新しいというだけではなく、ぼくらの開発効率を大きく向上してくれそうでした。最終的には「技術的な関心」と「開発効率向上への期待」、そして何より「新しい技術を使うことによるモチベーションアップ」を期待して、思い切ってNode4にバージョンアップしたという流れです。 結果として、Node4へのバージョンアップは大成功だったように思います。

バージョンアップに際しては意外とトラブルも少なく(npm cache cleanをしなかったせいで、C/C++で書かれたモジュールが古いまま…という罠にはハマりましたが)、期待していた効果は絶大でした。個人的には、ES6の以下の機能(Shorthand Property)がやたらと嬉しかったのが印象に残っています。

 

(ちなみに、ぼくらがNode4に切り替えた次の日に、バージョン5がリリースされたのには大変驚きました。。今のところ、5の採用は見送っています)

 

Node.jsをフル採用した所感など

 

Nodeを使った開発なんて、今ではそんなに珍しくもないですが、一応数ヶ月どっぷり使ってみた所感などを書いてみたいと思います。

 

個人的にNode.jsを使っていて一番ありがたいのは、クライアント(ブラウザ)のコードもサーバのコードもJavaScriptで書くことになるので、頭の切り替えが必要ないことです。

ぼくらは人数が少ないので、クライアントサイドもサーバサイドも一人のエンジニアが担当しなくてはなりません。そんなとき、プログラミング言語のコンテキストスイッチが必要ないのは、思った以上に脳力の節約になっている気がします。また、それほど量は多くないながらも、クライアントとサーバの間でのコード共有(入力値チェックや定数の共有など)もスムーズに行えています。

また、Node.js界隈はだいぶ成熟してきているので、「欲しい」と思うモジュールが、ほとんどの場合既に存在するというのが非常に心強いです。それらのモジュールが、ぼくらのサービスの開発効率の向上にどれほど役立っているかは測り知れません。

 

例えばキュレーションサービスの宿命として、自然言語処理を行う必要があります。

そうした場合、例えばNodeにはnaturalという包括的なライブラリもありますし、著名な形態素解析エンジンであるmecabをNodeから使用するためのmecab ffiというモジュールもあります。

Web上からフェッチしたHTMLのパースには、「Node上で使えるjQuery」という表現がピッタリのcheerio というライブラリが大活躍します。またぼくらのサービスは、HTMLメールで日々のニュースハイライトを配信しているのですが、HTMLメールでは外部のスタイルシートが使えないため、CSSをstyle属性にインライン化するためにinline-cssと言ったモジュールも使用しています。

 

一方で、Node.jsを使った開発のつらいところは、

「JavaScriptが自由すぎる」

「JavaScriptのコードスタイルがまちまち」 というところでしょうか。

 

Node.jsは非同期で処理していくのが通常のコードスタイルですが、ここ数年で、コールバックスタイルからPromiseスタイルへと大きく変わりました。Promiseも、慣れないうちは「Promiseのreturnを書き忘れる」という初歩的なミスを繰り返し、デバッグに長い時間を費やしたこともありました。

しかも今後はECMAScript6の普及により、コードスタイルはまたもや大きく変わろうとしています。ES6ではletconstがあるので、これまで何千回と書いてきたvarキーワードがもはや無用の長物と化しつつありますし、async/awaitが広く使えるようになったら、Promiseを明示的に使用することすらも激減するでしょう。

こうした、「常に進化途上」というつらさは、JavaScript界隈においては、今後数年間続いていくものと思われます(まあ、進化が止まってしまうよりもずっと楽しいのですが)。

 

Loopback先生

 

ちょっと長くなってきましたが、最後にぼくらが大きく採用しているアプリケーションフレームワーク Loopbackの話を軽くしたいと思います。

Loopbackは、Expressという非常に著名なWebフレームワークの開発元である、StrongLoop社(現在はIBMに買収されています)が開発しているフレームワークです。Loopbackの特徴としては、以下の様な事柄が挙げられます。

 

  • データベースを「モデル」という形で抽象化したレイヤーが存在する – モデルを定義するだけで、Web APIを自動的に作成してくれる(今話題のSwaggerの実装を内包しています)
  • カスタムのWeb API(リモートメソッド)を作成するのが容易 – ベースはExpressなので、Expressに関する知識や、ミドルウェアは同様のものが使用できる
  • 定型コードを自動生成するためのコマンドラインツールや、Web APIをブラウザから簡単にテストできるツール(API Explorer)など、周辺ツールも充実

 

ちなみに、ぼくらはデータベースにMongoDBを採用していますが、Loopbackのおかげで、DBに依存したコードは最小限で抑えられています。 Loopbackは、APIの設計思想やセンスも良く、フレームワークがカバーしている範囲も広いため、良いことづくめです。

採用しない手はありません。ぜひあなたも明日から、いや今日からLoopbackを使いましょう!

 

…と言いたいところですが、一つ、大きな注意点があります。 Loopbackで開発していると、なぜかよくハマります

なぜなのかは、いまだによくわかりません。。

Loopbackのせいで意味不明な(と思える)挙動に捕まり、Loopbackのコードをひたすら追いかける…といったことに、ぼくらは何時間費やしたことでしょうか。「ドキュメントも豊富、API設計も悪くない、フレームワーク自体のバグがすごく多いわけでもない、なのにハマる」という謎の現象に対する畏敬の念を込めて、いつしかぼくらはLoopbackのことを「Loopback先生」と呼ぶようになりました。

ここではLoopbackに関する詳細には触れませんが、皆さんも素敵で不思議なLoopback先生の世界に飛び込んでみませんか?

 

まとめ

 

今回は初めての記事ということで、キュレーションの内部的な処理などについては全然触れませんでした。

もし次の機会があ
ったら、そういったあたりのお話もぜひできればと思います。

もしよろしければ、TechFeedも使ってみてください。

フィードバック大歓迎です! では、どうぞ今後ともよろしくお願いします。

 

採用バナー③

 

【関連記事】

DSP実務者にオススメ!代表的なDSPの使いやすさを比較してみました

WordPress以外のCMSも使ってみよう!Drupalとは?

Apple TV アプリを作ってみよう!!第一回「Apple TV とは?」