yoshiki-0428

# 案件概要 「[みんなのサブスク](https://review.subsc.cc)」という**今までなかったサブスクレビューサービス**をゼロから企画をし開発しました。**「本当に必要なサブスクサービスをあなたに」**というキャッチコピーでわかりやすいデザイン、レビュー入力しやすいデザインで構成しています。  ## 開発に至った経緯 サブスクサービスが年々急激に増えていくのに対しユーザにとって適切なサブスクサービスを選びづらい状況だと考え企画兼開発をしました。サブスクはいわば固定費となるので**ユーザにとっては慎重に選びたいと考える**はずで私自身も様々なサブスクを登録しておりどれだけお金を支払っているのか管理できなくなりつつあったので、登録している全サブスクの月料金を確認でき、サブスクのレビューやユーザストーリーを確認できるWebアプリが必要とされていると考え開発に至りました。  # 課題解決 ## 管理画面をゼロから作らない工夫 今回、[Strapi](https://strapi.io/)というCMS OSSを利用し開発に至っています。よくあるCtoC Webアプリでは管理画面の開発がボトルネックかと思います。今回の開発予算もそれほど多い案件ではなかったため、どうにか管理画面というコストを下げるべく、様々なCMS SaaSを検討しました。 ### 検討したCMS SaaS - Contentful - esa.io - airtable ですが、結局どれも伸びてきた頃にはデータの移行作業が発生してしまいあまり拡張性がないと判断し、StrapiというCMS OSSを選択しました。StrapiはGUI or JSONでDB定義を設定でき、DBもMySQL, pg, MongoDBなど様々なOSSを選択することができます。伸びてきた頃に集計処理や細かいグルーピングなどをしたくなってきた頃にAPI開発を行えば良いと判断し選択しました。 結論を言うと**「まずはMVPを重視しStrapiを選択」**しました ## toC アプリなのでBackendコストよりもFrontendコストに注力する 業務アプリならいざしらずtoCアプリはUI/UXが非常に重要です。少ない開発リソースをFrontendに注力するため、Frontendに人員を裂き画面優先で開発を進めました。バックエンドは後からなんとでもなると判断し、UI/UXに注力しました。 おかげで約50人のアンケートで半数以上がデザインが良いと判定をしていただけました。 

# 案件概要 マイクロサービスアーキテクチャで構成されており、医療機器(IoT)からPOSTされるレコードをMessagingAPIでDBに保存をし、保存されたデータをリアルタイムにダッシュボードに表示させ、医療従事者に稼働状況などの監視情報などの価値を提供するシステム開発です。 # 課題解決 ## バックエンド別 ### 1000万レコード以上あるテーブルをサマリーする機能の速度を60秒から0.6秒の100倍にした話 - 1日に1秒間間隔で機器のステータス情報がDBのレコードに保存される仕組みがあり、そのレコードを1日毎、1時間毎でサマリーする機能があった。 - 日時情報を`to_char`関数で変換した値を`Group By`をしており、`レコード量が多ければ多いほど指数関数的にクエリー時間が増える`という課題があり、SQLチューニングし課題解決した - 案件の性質的に`要件定義、設計、実装のフロー`が早く、当時は`とりあえず`の実装になっていた。 - 試行したこと - `to_char`をする項目を増やしその項目に対し、Indexを貼る - 速度は倍になったが、実用でないため`不採用` - `Materialized View`を使用し、1時間毎の集計データをViewに保存し解決 - `100倍になりました。` ### Matelialized Viewの更新を`k8s`のCronJobタスクで自動化 - Materialized Viewは定期的にRefreshが必要であり、以下の方法を模索しコストの低いCronJobタスクで解決をした。 - 対象テーブルのInsertをトリガーにViewを更新する - 1秒間隔でInsertされるため、DBコストが高いため`不採用` - `k8s`のCronJobタスクで指定時間にRefreshコマンドを起動させる - 要件的に更新されるべきタイミングが1日毎だったため`採用` ### 海外タイムゾーンの対応 - 当時の課題 - システムを将来的には日本以外の国で使うことになるため、GMT基準でシステムが組まれていた。 - 課題は、APIとフロントエンド間は　`どんな形（日時表示なのかUnixタイムスタンプなのか）`で`誰がローカル時間に変換する役目`を担うのか。 - 試行したこと - バックエンド側でバックエンドのシステムタイムゾーンで変換し日時表示で返却を行う - バックエンドの設定タイムゾーンで日時が変わってしまう。 - （アメリカから日本のサーバにアクセスされると日本時間で返却をしてしまう）国別にサーバを置くことは現実的ではないため不採用 - 取り扱う日時をUnixタイムスタンプにし、サーバ側では完全にUnixタイムスタンプで連携し、フロントエンド側で設定のタイムゾーンで変換を行う。 - フロントに一任することによりブラウザのタイムゾーンが適用されるためコストが少なく、海外タイムゾーン対応が実装できた。 ### SPAとAPI間の認証周りを`SpringCloudGateway`で解決した話 - 案件の認証の仕組み - `AWS Cognito`のような外部認証サービスを使用し`OAuth2`で認証することにより、ユーザログインを行う - 当時の状況 - 認証基盤の実装が`とりあえず`のもので正しく実装されていなかった（固定アクセストークンでシステムにログインをするような状態） - 試行内容 - SpringCloudGatewayという最新のFWの認証を使用しOAuth2の実装を完了（Api-keyやSecret-key、Redirect URLなどの設定情報を記述することで認証周りの処理を行ってくれる） - MicroService的な思想で構成されているため以下のような構成となる - `Front` <=> `SpringCloudGateway` <=> `API (BFF)` <=> `その他API` - 当時あまり日本語の情報がなかったが、GitHubのサンプルコードなどを参考にシステムを構築し解決しました。 ### 画像データ、マスターデータをRedisでキャッシュする対策 - 当時の課題 - APIサーバのリソースは限られており、余分に画像の取得などでリソースを無駄に使用していた - 解決内容 - 画像データやマスターデータを取り持つためにRedisでテキストデータで保存し、余分なリクエストを減らすことができた ## フロントエンド別  ### 医療機器の3Dモデルをリアルタイムに動かすことができる`DigitalTwin`（手術ロボット）の稼働部分をThree.jsのAnimationでリアルタイムに動かす - 当時の課題 - TypeScript用のサンプルコードが少なく、Three.jsをリアルタイムで動かすという実装をしている人が少なかった - 解決内容 - 別チームに3Dモデルの作成、パーツごとの動きの設計をしてもらい、MessagingAPIで受け取ったパーツ動作情報をThree.jsに当てはめ、リアルタイムに動く機能を実装した。 - Animationクラスがリアルタイムの動きに対応していないので、別でWrapするクラスを作成し解決した。

# 案件概要 読んだ本に対して`TOI`(問)を与え、回答するだけで本に対して理解が深まる。インプットとアウトプットが両方できるWebアプリです。 構成は、API部（Java）Front部（Vue.js）で別れており, AWS EC2, AWS Amplifyで構成されています。 # 課題解決 ## 本の情報をRakuten Books APIより取得し、本情報を外部化する - 本の情報のリソースを内製すると手間と時間がかかる - `Rakuten Books API`を使用することで外部の本情報を利用することができた - 更に`OpenAPI`のYML形式でAPIドキュメントを作ることでほとんどコードを書くことなく、外部APIの呼び出し部分の作成することができた ## BtoC用に外部ユーザを手軽に取り込めるようにしたい(OAuth2認証を実装) - `Spring OAuth2 Client`を利用することで`OAuth2認証`を手軽に実装。認証に必要な情報を設定するだけでOAuth2の認証を実装 - 認証ベンダーとして`AWS Cognito`を利用。（外部のサービス連携が強く、コストが低い）