node.js + express + TypeScript サーバーサイドの app の Tips!!
おんちゃんが、node.js + express + TypeScript サーバーサイドの app を書いているときに、知った事を、書いてみました。
1. サーバーサイドプログラムでおんちゃんが想像する、必要な機能や、スキルを挙げてみた。
1) html テンプレートを使った、html ページの表示。
ejs を利用する。
2) DB 操作。
データの、 新規、更新、削除 、検索と一覧。
検索&一覧で、1ページに収まらない時は、ページめくりをする。
3) 画像ファイルのアップロード。
及び、画像ファイルの削除。
4) クッキーの使用。
5) 認証
6) バックグラウンド(別プロセス)での、メール送信。
及び、メール文面のテンプレートを使った、文章の作成。日本語対応。
7) node,js の ssl 対応は?
8) ハッキング対策。
SQL Injection 対策、クロスサイトスクリプト対策、と、form 送信のなりすまし対策
9) クライアントサイドからの非同期通信への応答。
10) テキストファイルの操作、及び、その時の排他制御。
この場合、排他制御が、必須みたい。方法は、いくつかあるみたいだが、
proper-lockfile のサンプルを、google ai で、教えてもらうのが、簡単じゃ?
perl のフィルロックと同じ要領みたい。ただし、ロックの解除し忘れ対策として、必ず、一定時間が経過したら、
フィルロックが自動で消える指定をすることが大事。
11) データエントリーページ。
入力データのチェックは、ブラウザー上とサーバー上のダブルで行う。
ブラウザーの戻るボタンで、戻った場合も対応する。システム上に重複したデータが登録されない事。
とにかく一般的ユーザは、でたらめな操作をする事を前提に、プログラムすることが需要!!
12) 複数ページに対応した、プログラミング。
次項の、"4. 複数ページに対応した、サーバー プログラミングに関して。" を参照しとうせ!!
ここからは、エキスパート。
1) node.js のクラスター構成。
2) クラスターでの排他制御。
最後は、
1) 公開サーバーへのデプロイ。
単独か、niginx 等との併設か?
2. Basci 認証のプログラム。
認証時にの username、password のチェックは、express-basic-auth.basicAuth callback の中で書ける。
注1) express-basic-auth.basicAuth を使うと、
req.auth: { user: string, password: string} が、上がってくる。
ただし、そのまま、 req.auth では、コンパイルエラーになるので、
declare global {
namespace Express {
interface Request {
....
を定義しておく。
注2) 公開サーバーで実際に使う場合は、これだけでは不十分で、
エラー回数を決めて、それをオーバーすると、無視する処理が必要。
google で、"express-basic-auth callback で、認証エラー回数を制限する" を検索すると教えてくれる。
3. node.js は、くせ強い
File I/O を伴う場合は、async 、await で、発行した、I/O 処理の終了を待ちながら、コードを書かないと、処理の順番が保証されないみたいじゃ。
逆に言えば、処理順がどうでも良い場合は、不要だ。と言うことか?
ちょっと言葉が足りないか、
async のついた関数、クラスメソッドを呼び出す時、await をつけてコールしないと、コールされた側の処理の完了を待たないで、
コール側の次のコードステップへと制御が進む。
と言うことじゃ。コッホ!!
4. 複数ページに対応した、サーバー プログラミングに関して。
ChatGTP で、"node.js + express + typescript サーバープログラムで、表示ページ数が増えても、入口プログラムは、1箇所でしょうか" と質問した。
そしたら、複数ページ向けの、プログラム構成 を教えてくれた。
今まで、目にした、Web上 のサンプル例では、思いもつかなかった。
今までのサンプルでは、
index.ts、app.ts ... の一箇所で、ただひたすらに、上がってきた、request を振り分けて、応答処理を書くパターンだった。
それを、分散できる仕組みになる。なるほど...
大雑把に書くと、Router と、Router で振り分けられた、各リクエストに対する、処理の実装部分(Controller)を分ける構成にできる。
かつ、Router、Controller を処理するページに応じて、複数使える。と言うことじゃ。
これで、大規模のサイトの案件が来ても、対応ができる気がしてきた。
こっほ!!
今後は、このプログラム構造で、全て書くように、今から、始めなきゃいかん!!
5. S3 / Cloud Storage を、勧められた。
"4. 複数ページに対応した、..." の流れで、POST ファイルアップロードの仕方を、Chat GTP に教えてもらっていたら、
アップロードした画像ファイルなどは、最終的に、S3 / Cloud Storage へ保存するのが、いまの常套手段だそうじゃ!!
6. google ai も役には立つが、同じ項目に関する、回答が、かなり違うときがある。
あまり、鵜呑みにはできない。
場当たり的回答みたい。全体の整合性を考慮した回答ではない気がする。
最後は、プログラム自体のマニュアルを読んで、
自分で幾つかある回答の中から、自分で判断して選ばないといかん。
プログラム初心者が、すぐ、鵜呑みにするのは、危険じゃ!!
例を上げると。
だが、google ai の回答の中に、ここで、 catch(error) が上がってくるのは、
loc.lock() を発行した時だけだ!!
だと、自信ありありで、回答してきた。
そうではないのでは無いのか、try{} の中で生じた割り込み、全て
誰かが、 throw すれば、それら、全てに対して、catch(error) に制御が来る。
経験が無い、初心者は、この間違いに気が付かないかもしれない。
loc.lock() を発行したときだけではなくて、
try{} から抜けるまでは、全て拾われる。