新規サービスをリリースしたので備忘録的な何か
先週新規サービスをリリースしました
結構難易度高かった。。。
自分がやったことの備忘録的なものを書いておきます
自分は今回サーバーサイドで、
プロジェクト構成、認証、api、スクレイピング、DB設計、CI環境、開発環境のAWSのインスタンス作成等々0ベースでガッツリ一人で担当させてもらいました
今回作成したサービスに使用した技術（特徴）としては
- Kotlin for Serverside
- サーバーレス(AWS：SQS, EC2, S3, CloudFront, KMS)
- Webスクレイピング
- シングルページアプリケーション
- セキュリティレベル高め
それぞれをもう少し詳しく書いていくと
Kotlin for Serverside
今までは主にJavaでの開発が多かったのですが、今回は最初からKotlinを採用して開発を進めました。
元々別のプロジェクトで試験的にテストコードをKotlinで書く等はしていたのですが、テストだけではあんまりそのメリットは実感できていませんでした
しかし、プロダクトの開発でKotlinを使ってみるととても使いやすくて（楽）、正直もうJava書きたくなくなるレベルでした
Null安全のメリットも正直使ってみるまではあんまりピンときてなかったんですが、やってみるとNullになりうる箇所が明示できるので、とてもいいと思います
Javaコードとの共存もできるので、既存のJava資産（知識等）も使えます
今回慣れていたこともありフレームワークにSpringBootを選択したのですが、何の問題もなくKotlin×SpringBootで開発できました
今後も使っていきたいなと思える言語でした
サーバーレス(AWS)
AWSは今回始めて使ったのですがいい勉強になりました。
本番用の細かいIAMの権限設定などは、別途インフラチームの方がいるので基本そちらの方にお願いしていたのですが
序盤などはまだインスタンス等も準備できていなかったので、必要なものだけ自分でインスタンス立てて、開発を進めていました（ある都合で締切が明確に決まっていたため時間を無駄にできなかったので。それと自分で色々触ったほうが学びが多いので）
権限の設定等は自分でやったわけではないのであまり良くわかっていませんが、IAMやインスタンスに権限を持たせるといった概念を理解できたのと、AWSを使ったサービスのインフラ設計が学べました
Webスクレイピング
今回開発したサービスでは、Webスクレイピング技術を使用する必要がありました
当初はスクレイピング自体やったことなかったので、どんなものなのかワクワクしていたのですが、
やってみると結構泥臭い作業だなーという印象でした笑
事前調査ではいくつかのライブラリを検討しました(Selenium、HtmlUnit、あと忘れた)
Jconsoleで軽くパフォーマンスも見てたけど、結局どれ使ってもWebのリクエスト飛ばすところが一番重いって感じで特に差が感じられなかった
HtmlUnitのほうがシンプルに使えそうだったため、最初はHtmlUnitで実装はじめました
でも最終的にSelenium(WebDriver)も使っていて、今となっては最初っからSeleniumだけで良かったかもーと思っています
実装する際スクレイピング先のDOM構造などを分析するのですが、サイトによってマチマチで
一つ一つ対応するのはそれなりに大変でした
XPath指定で要素を取得するときは、div[2]みたいな”divの〇〇番目ー”といった感じで取ろうとすると、Dom構造が少しでも変わったとき失敗しやすくなるため、Dom要素の取得には一つ一つ気を使いました
また、スクレイピング先のサーバーに迷惑を書けないように、各画面遷移ごとに1秒のウェイトを設けて、
負荷をかけないようにするというような実装もしました
この辺はユーザビリティとのトレードオフにもなるため、そのへんも意識しながら開発しました
スクレイピングは初めてだったので、こちらの書籍を参考に勉強しながら進めました
Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド-
- 作者: 加藤耕太
- 出版社/メーカー: 技術評論社
- 発売日: 2016/12/16
- メディア: 大型本
- この商品を含むブログ (3件) を見る
シングルページアプリケーション
フロントエンドではReactを使用したSPAにしました（今回は自分は全然触っていませんが）
認証にはjwtを使用したため、サーバーをステートレスにでき、その点はとてもシンプルに作れたと思います
また、今回APIをフロントエンジニア主導で設計する方法を試してみました
フロントエンジニアがデザインを見て必要なものを確認し、APIを設計する
その設計ができたタイミングでサーバーサイドでもレビューするといった感じです
APIはswaggerを使用して、ドキュメント兼モックとしました
API設計の手間がある分フロントエンドの作業負荷が上がってしまったかもしれないのですが、モックがサクッと作れるため、
サーバーの開発を待つことなくフロントエンドが作業を進められたのは非常に良かったと思います
おかげで初めてフロントとサーバーをマージして動作確認した段階でもそれなりのクオリティになっていました
一部自分のAPI設計の確認で甘いところがあったため、そのへんはミスったなという感じでした
設計を見た段階である程度このjsonオブジェクトの構造は難しいなどの判断をもっとちゃんとしなければいけませんでした
この辺はapi version2的なもので後々直したい
また、フロントエンジニアの方にも感想を聞いたところ、この方法のほうがスピーディに開発できたと言っていました（この方法じゃないと今回のスケジュールには間に合わなかっただろうとも言っていました）
確かにサーバーサイドで設計すると、後からアレがないコレがないとなってしまうことが多かったのですが、今回は殆どそういったことが発生しませんでした
また今回SPAであったため、UIの作り込みが普通のwebサイトより求められると思います
こういった設計の場合、ある程度画面に合わせてAPIを設計するというスタンスのほうが良いのではと今では思います
半分思いつき&半分サーバーサイドの開発が重くなりそうだったからAPI設計をフロントに投げたいという発想の元試した方法でしたが、結果としては良かったと思っています
