サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
blog.masuqat.net
引き続き(しばらくは) SaaS 開発をやっていくことになったので、フロントエンドエンジニアではあるが SaaS バックエンドについても知見を持っておこうとしている。前々からの懸念・課題としてマルチテナントの DB をどう安全に実現するかというものがあったため、それを調べることにした。 この記事では、あくまで具体的な動く例を元に解説を加えているだけなので、軽く知りたい方や実例・ストーリーを求める方は記事最後の参照記事を見るだけで十分かもしれない。 ソースはこちらから。 背景 SaaS アプリケーションでは、金銭的なコストやマイグレーションのコスト削減のために DB もテナントで共用する構成(以下、マルチテナント構成)が求められる。 これは一つのリソースユニットですべてのリクエストを捌くという意味でなく、テナント専用の割り当てがないリソースユニットでテナントを選ばず捌くということ。スケールア
English version タイトルのような React 設計の提案を思いついたが、文脈・問題やほかの方法との比較、良し悪しを詳細にしようと書いていたところ時間がかかりすぎ、いつまで経っても手法を公開できず機を逸しそうだったため、先に手法だけ公開しておこうと思う。動くサンプルプロジェクトも何もない。 大きい処理について、サーバーやツールではレイヤーや関心単位により比較的簡単に分割できるが、フロントエンドのコンポーネントでは別の難しい問題がある。それに対して View-Hook Pair と名付けた分割統治方法を(軽く)提案する。 それぞれの対象がお互いにロジックや UI についてそれなりに影響しあうものをご想像いただきたい。<ProjectPane /> のタブを閉じてから開きなおしても、中身は変わらずそのままであってほしい、つまり、 unmount されても <ProjectPane
これは 設計ナイト2020 の感想記事です。 CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、(レポートというよりも)考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話(触ってみたレベルでなく実運用等を経たもの)についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ
Announcing TypeScript 3.7 Beta に “Optional Chaining” と “Nullish Coalescing” という待望の機能とともに “Assertion Functions” が登場しています。 これは従来からある User-Defined Type Guard と似ていて、こちらは条件に合わない場合に例外を投げるような、別言語での assert 構文・関数と似たものを TypeScript のフロー解析に入れる機能追加です。 Assertion Functions については TypeScript 3.7の asserts x is T 型はどのように危険なのか が全体的に詳しいです。 この投稿の本題は、それの制約に関するメモです。 Assertion Functions を使ってトリッキーなことをしようとして阻まれたわけですが、日本語の記事
この記事では、前回( Python で gRPC の単体テスト)に引き続き、 Python で gRPC を使う際の知見をご紹介します。 主に、メタデータとインターセプターの実装法と、そのテスト方法がメインになっています。 まだ experimental API だったり非 public クラスだったりしているので、公式のアナウンスがあるまではプロダクション利用は難しいようにも思いました。 目次 エラーの取扱 メタデータについて メタデータを利用する例 サーバー クライアントライブラリ メタデータを利用するクラスをテストする例 サーバー クライアントライブラリ インターセプタについて インターセプタを利用する例 サーバー用 クライアント用 インターセプタを利用するクラスをテストする例 サーバー用 クライアント用 まとめ エラーの取扱 gRPC のエラーの方法は、 gRPC Errors が
create-react-app は v2.1.0 で TypeScript を公式サポートしました! ということで、悪名高き “eject” をせずにどこまで外部ツールを設定できるか挑戦してみました。 npm run eject をせず、また、 react-app-rewired / craco は使わないようにします。 もう一つの動機としては、私は Webpack が好きなので手で設定をしてしまうことが多いですが、他のメンバーが管理できる範囲に収めたほうが喜ばれそう、というのもあります。 サンプルプロジェクトはこちら。 TL;DR create-react-app でプロジェクトを作った後、 Storybook と Linter(for TypeScript & CSS/SCSS) と E2E テストは自分で設定しなければならない。 ただし、 Storybook は v4.1 から設定
この記事では、 TypeScript FSA で非同期処理するときの知見を忘備録として載せます。 TypeScript FSA 自体は他の方の投稿のほうが詳しく紹介されているので、この記事ではニッチな部分をメインに取り上げて載せています。 サンプルプロジェクトはこちら。 目次 TypeScript FSA 使い方 3.0.0-beta-2 Redux Thunk と一緒に 2.3.0 Redux Saga と一緒に 1.0.0-beta.1 redux-observable と一緒に 1.0.0 最後に TypeScript FSA 使い方 TypeScript FSA は、 “Flux Standard Action” に TypeScript で型を付けることで、 Action 作成関数と Reducer の実装を型安全に行えるようにするライブラリです。 Action の Dispat
最近のフロントエンドの流れから取り残されている感じがしたので、一念発起して React で小さなアプリを作ろうと思いました。 せっかくなので、 React 関連ツールはなるべく統合して使うようにし、コード本体は TypeScript を使って開発しようと設定を始めました。 ( webpack 4 が出てきてしまいましたので、まだ周回遅れです。) 残念ながら、 create-react-app でテンプレートを作成してからツールを追加していくたびにエラーに見舞われたので、メモ書きとして記録しておきます。 執筆に長い期間かかってしまいましたので、もしその間にライブラリがアップデートされ、動かなくなっていたら申し訳ありません。 目次と使用ツール (以下のリンクは関係する部分へジャンプします。) TL;DR create-react-app React 16 TypeScript webpack
この投稿は C# Advent Calendar 2015 の23日目の記事です。 .NET Compiler Platform(Roslyn)が簡単に利用できるようになり、Analyzerなどでよく見かけるようになりました。記事やブログのポストを覗いてみると、Roslyn関係の投稿は大抵SyntaxTreeを解説したもののような気がします。 この記事では、より詳しく分析できるSemantic Modelというものについて紹介します。 Semantic Model Semantic Modelは意味論モデルと訳されます。Syntax Tree(構文木)がソースコードの構造のみから作られるのに対し、Semantic Modelは使用するライブラリの情報を含んで作られます。 構文の形のみによって判別できるものであればSyntax Treeで十分ですが、メソッドの使い方のチェック(引数等)や複雑
このページを最初にブックマークしてみませんか?
『blog.masuqat.net』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く