2023年度リクルート エンジニアコース新人研修の講義資料です
マイクロサービスの矛盾先日、「マイクロサービス?モノリス?SaaSアーキテクチャのPros/Cons | SaaS.tech #1」(youtube)(togetter)というイベントを観ました。これは、マイクロサービスのイベントだったのですが、新規のシステム開発において積極的にマイクロサービス化をすすめる方が少なかったのが意外でした。 マイクロサービスの開発経験のある優秀なエンジニアであっても、まずはモノリスからはじめてプロダクト境界を意識して設計していき、functionベースで切り出せるもの(認証や通知、メール送信、バッチ等)は切り出しつつ、必要であればモジュラーモノリスかマイクロサービス化を慎重に検討するということでした。素晴らしい冷静な判断です。 というのは、ドメインの専門知識がないうちにマイクロサービスの複雑なシステムを設計するのは、多くのソフトウェアプロジェクトが陥りやすいリ
室見川“Web フロントエンド”の悲しみと明るい未来という記事を読みました。 これについては全く同感です。 next.js が vercel を提供して CDNからサーバーサイドでの処理までをワンストップに提供しているとか、 firebase がクライアントサイドでの SDK と Cloud Functions をなるべく一貫した体験で提供しようとしていることとか、あるいは今話題の React Server Component とかについて、フロントエンドの最前線がいったいどのような苦しみにあるか、理解できる人は実はあまり多くないのではないか、と僕は思っている。 それは何かといえば、絶望的なまでのサーバーサイド/バックエンドへの忌避感だ。https://anond.hatelabo.jp/20210105164149 というのも、これは私達がvte.cxを提供してからずっと感じていた課題だ
はじめに promiseを使うとき、いつもpromiseメソッドチェーンで記載していますか? async/awaitを利用していますか? もちろん状況によって両方書くのが殆どだとは思うのですが、私はasync/awaitの方が同期的な書き方ゆえに読みやすいため、なるべくそちらで記載しています。しかしながら、エラーハンドリングが理解できていなかったため、エラーの所在を突き止めるのに苦労してしまいました。 そのため、これを機にasync/awaitにおけるエラーハンドリングについて備忘録的にまとめておきます。 この記事のまとめ; catchされるエラーはrejectのみか、throwされたエラーも含まれるか →両方catchできる async関数における処理の順序、awaitがある場合とない場合 →awaitがない場合には同期的に処理が実行され、catchできなくなる エラー処理を外側に伝播し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く