Spring Framework
作成日時:2024-08-01以前
更新日時:2024-08-26
メモ
- DIコンテナー
- シングルトンなら必ずスレッドセーフにしなければならない。
- トランザクション
- 伝搬に気を付ける。
- rollbackForを指定しないとExceptionが投げられてもロールバックされない。
- @Transactionがついていれば必ずトランザクションが発行されるわけでは無い
- Isolation確認
- 呼び出し元確認
- キャッシュ
- HTTPとしてのキャッシュ(HTTPヘッダーに)
- メソッド単位のキャッシュもある。
- セキュリティ
- ググれ。「Spring Security (JWT|OAuth|パスワード)」とか。
- CORS/CSRFを忘れるな。
- セッション管理
- サーバーを複数台建てるならLBでスティッキーセッション
- もしくはRedisサーバーでセッション管理。SPoFになる。
- MyBatis
- 個人的にはXMLで定義するのが面倒くさい
- アノテーションベースで書く。
- クエリが面倒くさければSqlProviderで書く。
- 下の構成案。serviceやrepository。実装が1個ならimplは要らないと考える。密結合になるけど。
- 契約による設計。
- Spring WebFluxとか使う現場とかあるのかな。nginx/Netty。
- 別言語でやればいいのでは
- GraalVMでバイナリ吐いてもGo/Rustに勝てるか。
- Tomcatのバージョンが正しいか確認。古いと動かない。
Springディレクトリ構成案
- Spring Initializer使ってプロジェクト作ってもディレクトリ作ってくんないのめんどいからメモ。
- とりあえずこんな感じでしょ。
- testディレクトリは末尾にTestでもつけとけ。
- 怪しいのもあるけど現場のメンバーと会話して修正とかしろ。
ディレクトリ構成
- security
- SecurityConfig.java
- config
- XXXConfig.java
- controller
- v1/v2(api)
- admin
- Admin系のController.java
- AdviceController.java(例外投げられたときとかここでキャッチすればいい)
- InterceptorController.java(ログ出力)
- XXXController.java
- domain
- bean
- XXXBean.java
- service
- impl
- XXXServiceImpl.java
- XXXService.java
- model
- XXXRequest.java
- XXXResponse.java
- dto
- extension
- テーブルに無い奴
- XXXDto.java
- aspect
- XXXAspect.java
- common
- XXXUtil.java
- enum
- XXX.java
- repository
- impl
- XXXRepositoryImpl.java
- mapper
- XXXMapper.xml
- XXXRepository.java
- resources
- application.properties
- message.properties
- log4j2.xml
- logback.xml
- templates
- something_group
- XXX.html
- static
- js
- css
- img
セキュリティ
Spring Securityで準備されているインタフェースを実装すればよし。
アカウントロックや失敗回数とかはユーザ検索サービスで書いて
エラーメッセージは例外とかで返しとけ。
インジェクション
コンストラクタインジェクションに変更+フィールドをfinalに。
↓
モックの注入と不変性の確保。
および設計の見直し。
コンストラクタインジェクションの定義が面倒ならば、
それはSRPに反している。
親コンポーネント呼べる。
コンストラクターinjectionでもいい。
Content-Encoding
圧縮するように。
Spring Boot アプリケーションプロパティ設定一覧 - リファレンス
循環参照
Springで循環参照したら別クラスにしろ。
SpringとノンブロッキングI/O
nginxにはノンブロッキングI/Oを載せろ。
Netty,Node.jsとか。
Spring MVCとSpring WebFlux
Spring MVCが適している場合
- 小規模なウェブアプリケーション:
- ブログ、個人サイト、企業内ポータルなど、ユーザ数が比較的少なく、トラフィックが予測可能なアプリケーション。
- 従来の同期型処理が要求されるアプリケーション:
- 伝統的な同期型のWebアプリケーションやAPIで、非同期処理やリアクティブなデータ処理が不要な場合。
- 既存のSpring MVCベースのアプリケーションの拡張やメンテナンス:
- 既存のSpring MVCプロジェクトを拡張し、新しい機能を追加したり、既存のコードベースをメンテナンスしたりする場合に適しています。
Spring WebFluxが適している場合
- 高トラフィックおよび大規模なユーザーベースを持つアプリケーション:
- ソーシャルメディアプラットフォーム、電子商取引サイト、大規模なオンラインサービスなど、大量の同時ユーザーアクセスが予想されるアプリケーション。
- 非同期およびリアクティブなデータ処理が必要なアプリケーション:
- リアルタイムデータ処理、IoTデータの収集、ストリーミングアプリケーションなど、非同期性やリアクティブなアーキテクチャが必要な場合。
- クラウドネイティブなアプリケーション:
- コンテナー化された環境でのデプロイメントやマイクロサービスアーキテクチャに適した、軽量でスケーラブルなアプリケーション。
デプロイ先はApache+Tomcatのようにnginx/Nettyのようなノンブロッキングの組み合わせが必要らしい。
Spring Batch
バッチ管理用のメタテーブルが必要。
保持する必要が無いならば、H2を使用して、バッチ終了時に破棄する。
キャッシュ
Spring MVCのキャッシュ、デフォはキャッシュしない。