ID:7632さん

APIサーバのドキュメンテーションとモックサーバを両立させる方法を複数のプロダクトを通じて行っていました。 easymockやstubcellといった軽量のものを使っていましたが、いかんせんドキュメンテーション能力が弱くただのモックサーバとして、一時的に用意されたが以降はメンテナンスされない、APIの概要を知りたいのに結局サーバのコードを読まねばならない、という課題を抱えていました。 ドキュメンテーションとしてモック用意することで、上記の課題を解決しようと当時探して出会ったのが、APIBlueprintとSwaggerでした。 当時の要求からSwaggerは機能過多で、情報の追従にチームが疲弊するだろうと考え、比較的記述が安易（Markdownという馴染みのあるフォーマットでかける）であると感じたAPI-Blueprintを採用しました。 しかし、API-Blueprintの提供しているモックサーバーは現状の要求に噛み合わず、自身で作成することで導入のハードルを下げました。 実装当時は、テスト・ドキュメント・モックという3種の神器を満たすAPIツールはまだ試行段階でしたが、このOSSを開発・導入することで、以前に比べてこの課題に悩む頻度は減りました。 現状運用上でまだいくつかの課題が残っている部分があるので、今後改修を視野に入れて、また新しい技術の挑戦を行っていくつもりです。

AngularJS上で動作可能な、軽量のSingleStateFluxがほしかったので自作しました。 設計方針としては、以下の指標を元に行いました。 1. reduxのようなsingleState 2. reduxよりも非同期通信をカンタンに 3. ユーザの行動をActionという入り口で作る 4. データの取り込み整形はActionCreator 5. データの出力整形はreducer 6. なにが起きるかわからないので柔軟な拡張性を 2年ほど運用し、現在もプロダクトで利用しており、不定期に改善を行っています。 運用をおこなったことで、意図しない障害も発生しましたが、拡張によって柔軟で素早い対策が行えました。 また、よりシンプルで扱いやすいデータフローを心がけた為、カンタンな説明で利用を促すことができたと思っています。