😽

My Technical Rader(お気に入りの技術スタック)

2022/09/26に公開約8,600字

https://www.thoughtworks.com/radar

ThoughtworksというITコンサル(日本のITコンサルとは全く違う)の会社のテクノロジーの評価です。

自分も色々触ってきてて、これ失敗したなぁとか結構あるのでその辺をまとめる。ただ、好き勝手にいってるだけなので評価軸が違うとか言わんでください。おねがいします。。

ADOPT : プロジェクトにマッチするならば、採用を強くおすすめしている。
TRIAL : プロジェクトでリスクを管理できればやる価値はある。
ASSESS: どのような影響をあたえるか理解するために採用するときがある。(今後のために採用するときがある)
HOLD : 採用する場合は慎重に進める必要がある。

データベース

Adopt: PostgreSQL
ほとんどのクラウドでサポートされている。
ロジカルレプリケーションを使ったイベントの処理。
GCPでは、AlloyDB for PostgreSQLを発表。
また、NewSQLとしてPostgreSQL互換のCloudSpannerもある。
HasuraなどのGraphQLサーバーでのサポート。
supabaseのデータベースもPostgreSQLをストレージに使用している。
WordPressを使用するときはMySQLしかないのが悲しい。

Hold: DynamoDB
正直使い所がない。NoSQLとして、PartitionKeyによって書き込みがスケールするのはいいけれど。
Indexの設計に癖がある。SQLが使えないので分析が難しい。大体のアプリケーションはRDBでパーティション化したテーブルにしたりとか、AlloyDBを使うことで事足りる。EventStoreを実装するのに必要なversionを使った楽観ロックと、change data captureができる。
Viewを作ることができない。DynamoDBのレコードを読み出したときに、独自の型情報で返ってくるのでしんどい。protobufとか、jsonschemaとか、avroならまだ許せた。

Adopt: Redis
Keyの前方一致ができる。AWSのMemoryDBを使ったら永続化もできる。PubSubができる。勧告的ロックが容易に実装できる(すでにこのキーがあって同じキーを登録しようとしたら失敗するみたいな挙動を使ったロック)。SherdingとReplicationの機能をそろえている。AWSの場合は、ダウンタイム少なくサーバーの追加(キーの再配置)ができた。

Assess: Memcache
MemcacheはRedisに比べたらパフォーマンスがいいらしい。なぜいいかは、毎回忘れて毎回調べる。
ただ、Redisのスループットを上げたやつはあったりする。

https://zenn.dev/quiver/articles/0fdc22e9076551
keyの前方一致ができない。Clusterの設定がないので、FailOverさせたいときにたぶんReplicationするのは自前でやらないといけない。AWSにElastiCache MemcacheでClusterモードとかあるけど、replicationしたりしてくれるわけではないと思う。揮発性、永続化できない。

Adopt: S3およびCloudStorage
S3に互換性あるようにCloudStorageが設計されていたりする。どちらにしても、ファイルを置くときはいい感じ。

Hold: AppSync for DynamoDB
AppSyncでDynamoDBをbackendとしたGraphQLを構築できたりするけれど、DynamoDBエンジニアとして生きてきたエンジニアじゃないと割と辛い。ちょっとカスタムロジックを挟もうとすると、VTLを書かなければいけない。学習コストが高いし、VTLのユニットテストどうすればいいねん。
学習コスト高い、テストしずらい、データベース使いづらい。

LowCode

Assess: Wordpress
メディアサイトをサクッと作りたいときに使用する。ただ以下の条件を呑めることを前提にする。

  • デザインファーストではなく有料テーマファーストにして、TypoGraphyをちょっと修正したりするというフローが許容できるとき。
  • テーマはswellであってほしい。まあ別のやつでもいい。
  • レンタルサーバーの使用がOKなら最高。出なければ、ECSとEFS(ファイルの永続化が許容されている)。個人情報をレンタルサーバーに置くのは断固として反対なので、formは自前で作るかformrunのようなサービスの使用が認められてほしい。
  • すでに稼働しているdomainに連携するならCloudFrontのようなCDNでのroutingの制御とlocation headerの書き換えが必要。

Serverless Computing環境

Hold: Serverlessframework、AWS SAM、Lambda、CloudFunctions
データ処理基盤でデータのTransformするくらいならさほど問題ない。
アプリケーションの一部で使うには、テストの容易性。ほかのサービスとの連携。関連するベンダーロックインのマネージドサービスのローカルエミュレートの状況などを考慮して扱う必要がある。基本的には、DXが悪いので使いたくない。

Adopt: CloudRun
DockerをServerless環境にデプロイできる。Lambdaの場合は、LambdaのAPIにアクセスできるようにライブラリを追加しないといけないが、CloudRunの場合はそんな必要がない。Nginxだって、Railsだって、Next.jsだって、Nestjsだって、Dockerならば何だってデプロイできる。Java関連のDockerfileも第二世代の実行環境とNoCpuThrottlingを設定することで安定して稼働する。Debezium-serverやKeycloakで動作確認をした。ただ、ストレージの永続化ができないので、その場合は別のComputing環境を構築するか、ObjectStorageにファイルを保存するなどの工夫が必要。

Adopt: ECS on EC2、ECS on Fargate
EC2を選ぶときは、節約したい時がほとんど。EC2よりも1.4倍くらいFargateが高いので。あとは、EC2であれば、EBSでストレージの永続化ができるのに対して、Fargateの場合はEFSを使用することになる。EFSはあまりにもストレージのIOが多いとバーストして結構な料金がかかるはずなので、前段にCDNを立てるなりしてOriginサーバーにアクセスが行かないよう工夫する必要がある。
具体的には
Wordpressのサーバーを自前で立てるときに、ファイルストレージが一時的でアップロードしたファイルがサーバーの停止と共になくなるのは非常に困ったりするので永続化する。

イベントバス

Adopt: Cloud Pub/Sub
めっちゃいい。Schemaを管理する機能もある。ただSchema管理機能は使ったことはない。TopicExchangeができるQueueという認識。
まだベータ版だが、一定時間内のイベントの重複削除ができる。
イベントの配信を厳密に一回設定できる。

Adopt: SNS x SQS
Cloud Pub/SubのTopicExcangeの部分をSNSがになって、Queueの部分をSQSが担っている。また、Lambdaと連携した際には処理が例外を履いた場合DeadLetterQueueに自動で入る。便利。

Adopt: Kafka
金があって、リアルタイムで何かする必要があって、高スループット、低レイテンシーを実現するときはこれ。
ConfluentのManagedなKafka環境を使わせてほしい。KSQLとかのManagedサービスはConfluentでしか提供されていない(ライセンスの縛り)。KSQLがあれば、コードを書く量が減ると思っている。Kafkaはデータベースでもあるのでその辺は単なるQueueのSQSやCloud Pub/Subと異なる。当然exactly onceとmessage keyが同じ場合は順序が保証されてイベントが配信されるなどができる。

フロントエンドのフレームワーク

Adopt: Next.js
Next.jsはマーケットがNext.jsの一強になっているのでEdgeでの実行やSSG、SSRなど半端ない。開発環境でのhot reloadのBuildが遅すぎて使わない時期があったけど、めっちゃ早くなっている。bunとかでもssrでの実行をサポートして高速化されている。ssrはマジで扱いやすい。認証をcookieに持たせることができるのがまず最高。あとは、Reactのエコシステム成熟しすぎ。学習コストはtsできる人であればそこまで高くない。

Asses: Svelte, Sveltekit
Reactとの違いは、ReactはReactの実行環境の上でうごくけどSvelteはBuild時にPureなjavascriptにcompileするところ。pureなjsにcompileするのでだいぶsizeが小さいし、computingコストも小さい。
tailwindのサポートなども公式側で用意してくれてる。ただ、Reactのエコシステムが成熟しすぎて、車輪の再発明が結構必要だった。ペライチのページとかならいいかも?(Next.jsでもペライチのページ作れるけど。。。)

フロントエンドのスタイル

Trial: Tailwind css
tailwind cssはutilityベースのスタイリングを可能にしていているし、使用しているclassだけをbundleするのでよい。cssのクラスメイトかFLOCSSとか割とどうでもいいレビュワーのレビューから解放される。最高。FLOCSSを厳密にやるより、その部分書き直した方が早くない?再利用性もないし。。。

Adopt: ChakraUI
ChakraUIはReact依存ではあるがすたいりんぐするところは非常にTailwind cssと似ている。ちがいは、Tailwindの場合は、jsはheadless jsみたいな感じでゴリゴリ自分で描く必要があるのに対して、ChakraUIはwebで必要なほとんどのパーツが事前に提供されている。
TailwindはUIコンポーネントを提供しないが、ChakraUIはUIコンポーネントも提供している。
どちらもデザイントークンの運用ができるようにテーマの設定をconfigファイルに記載することができる。

TypeScriptのValidation

Adopt: zod schema
入力値やDTO、Entityといったアプリケーション内でのデータの正確性を高めるのに使用する。zod以外にも、ajvやyui、joiなどの選択肢があるが、validation後のデータにTypeがつくのはzodくらいしかないと思っている。ajvもできなくはないけれど、jsonSchemaを冗長に描きまくって腱鞘炎になるので却下。preprocessやCustomTypeも表現可能。primsa-zodをつかったら、primsaのschemaからzodスキーマを作成可能。コメントをつけて、value object的に扱うのも容易。

Assess: ajv
たぶん、ベンチマークをみても圧倒的に速い。がしかし、それがbottoleneckになるには思えない。とりあえずデータベースとか通信系のIOから見直そうか。jsonSchemaを知っていたら、学習コストがない。validationしたものにtypeを付けるにはtsconfigを一部修正する必要があるのでそこだけ注意。あと、interfaceから自動生成できるようにparserとか作らないと腱鞘炎になる。コードは最小限でいきたいわ。

ちょっとした自動化とScrapingツール

Adopt: puppeteer
自動化に使用する。いくつかsnippetを作ったらあとは、コピペ作業。ちょっとした自動化とか、scrapingはこれがよい。というのも最近はいろんなbot検知システムがあって、https://www.npmjs.com/package/puppeteer-extra-plugin-stealth この辺はpuppeteerでしか対応できてない。playwriteでも実装され始めているようだけど、まだ途中。機会をみて乗り換えたい。

テスティング TypeScript

Adopt: playwrite
e2eテストのために使用する。testingフレームワークがサポートされていて非常にいい。あとは、画面をぽちぽちしてコード生成ができる。cypressなどにもrecording機能などあるけれど、有料でどこまでのものなのか確かめられていない。無料でこんなことできるのは今のところplaywriteだけでは?chromeのrecording機能でpuppeteerスクリプトも生成できるけど、puppeteerはテストのことを考慮されてない。

Adopt: jest
最高

言語

Asses: Golang
まず、Golangでwebアプリケーションを作るのは絶対にやりたくない。データ処理基盤の一部に使うとか広告系のようなシステムに使うのは理解できる。ただ、webはTypeScriptでいいという気がしてならないというのが今のスタンス。第一級のprimitiveにstring | nullとかそういうのがないので、毎回そこを考えるところから始める。すでにちゃんと運用されてて、CleanArchitectureとかじゃなければ開発生生産性はぎりぎりよさそう。golangで始めるなら、可能な限り薄いライブラリを使用して、読んだら挙動がわかるみたいなところを担保していきたい。デプロイはめちゃくちゃ簡単でそれは好き。

Hold: PHP
... Laravelとか結構使いづらくない?WordPressのカスタムとかつらいよー。。

バックエンドの技術

Adopt: Nestjs
NestjsというフレームワークによってDIが簡単に実現できるようになっている。覚えることはちょっと多い。ただ、APIのフレームワークなので、RoRとかLaravelみたいに時間がかかるわけじゃない。詳しい人に教えてもらえるのであれば一日あればいけるのでは?DIなのでテストがしやすい。RBACとかも参考実装できるし、参照できるプロパティの制限もできる。AuthGuardを作れる。すでにいろんな人の手で、データストレージとかにアクセスするmodule(Nestjsの用語)が作られている。パフォーマンスが気になるなら、expressベースからfastifyベースに切り替え可能。GraphqlのAPIも作れる。EventBusとしても使用可能。Cloud Pub/SubやSQSをsubscriptionするのもお手のもの。つよい。

Assess: Hasura
RDBでReadModelとしてデータ取得するときにはアリな選択肢。HASURA_ADMIN_SECRETが流出すると死ぬので、認証をかけて保護するか、Privateなネットワークに配置する必要がある。あとは、クライアントサイドのjsとかから呼び出すときは、データベースのスキーマがそのまま露出するのでView作ったりして調整したりする必要がある。あとは、エンドポイントが露出してADMIN SECRETの総当たりで攻撃仕掛けられてもやなのでNext.jsやらでproxyしてリクエストする必要がある。

その他

Adopt: Chrome Extension
React x TypeScript x Esbuildみたいな感じのtemplateがその辺に落ちているのでサクッと拡張が作れる。機能をフルスクラッチとかで作るよりも拡張で何とかできることが結構あったりする。成果物をどこかに置いておけば、それを読み込むだけどお手軽に使える。
自分は、local開発の時のsession cookieを強制的に作るときとかに使っている。毎回ログインページ開いたりするの面倒すぎる。あとはフォームの問い合わせとか毎回入力したくない。

Hold: React Native
jsの資産が使いまわせるからいいかなとかも思った。けど、React NativeとFlutterを比較したときに、FlutterはOSのバージョンの後方互換性を保って開発されているのに対して、React NativeはそのバージョンごとにReact Nativeのバージョンが対応していたりするらしいので辛そう。複雑な機能を作らずに、メルカリみたいにNativeAppの一部のシンプルな画面を提供するのならやっていけるのかもしれない。

Iac

Adopt: Terraform
IacはTerraformだけで生きていけてる。ただ、k8sは知らない。Terraform Cloudと連携してサクッとCI/CDを作れるのも魅力的。個人で使うにも5人まで無料で招待できる。

Hold: CloudFormation
Cloudformationは苦痛でしかない。TerraformがAWS ConsoleなどGUIの挙動とできるだけ同じなるようにproviderの実装がされているのに対して、APIの呼び出し部分を静的なYAMLで提供された感じ。かなり使用者に丸投げ感がある。YAMLを生成するCLIなどがなければ苦痛でしかない。腱鞘炎の原因。APIで取れる情報も取れなかったりして、shellscriptで連携させたりとかつらたん。

全文検索エンジン

Adopt: Elasticsearch
Elastic Cloudでhostingしたらそこまで運用も難しくない。API KeyごとにどのIndiceにアクセスできるか制御可能。ただの全文検索エンジンではなくで、ReadModelを作るのにもすごい活躍する。RDBでゴリゴリ複雑でチューニングされたSQLを発行するよりも、ElasticSearchでReadModelを作った方が楽。とくにDebeziumとかKafkaとか、Supabaseでデータベースのobject操作のキャプチャができるのであればあとは、それをeventbusに流して登録するだけ。batch処理とかだとタイムラグがあったり、重複した処理が発生するのでやりたくない。ただ、ReadModelのmappingは頻繁に作り直すことになると思うので、テーブルのデータを再構築する処理の実装は必要です。

Asses: Algoria
お金がかかる。ただ、必要なデータを送ったらレコメンドを作ってくれたり便利そうではある。ただ高い。

これから調べることリスト

ObjectStorageと権限。

DRMで保護するまでも行かないコンテンツだけど、何かしらのアクションした人だけが見れるコンテンツのベストプラクティス探し。
S3であれば、sigendURLしかない。

protobuf

schemaの定義としてはavroと比較されることが多い。protobufは静的じゃないのでprotobufの制約をうけてドメイン知識を構造体にするのに妥協することはないらしい。その点avroはちょっとそういう対応が必要みたい。kafkaのschema registry、cloud pubsub、そのほかのところでもprotobufによるschema定義を受け入れ始めている。TypeScriptにprotobufがどれだけ親和性があるのか、開発生産性が上がるの蚊はこれから調べる。

CDK、Terraform for CDK

宣言的なコードやYamlファイルでインフラを管理するのは結構辛い。宣言的なのと命令的なのの中間くらいがちょうどいい。その点、CDKはよさそう。それも相まって、ECSのCI/CDとかを一発で作れるモジュールとか豊富なmoduleの提供がされている。terraformでECSのCI/CDを一発で作るテンプレ作るのに時間かけたのにちょっと悲しい。ただ、デプロイ周りどうなっているのかとか調べなければいけないことは結構ある。

FlutterFlowとrowy

STUDIOとmicrocms

まだ書ききれてないけど、疲れたので後のへんで切り上げ。。。加筆修正は随時していきます。

Discussion

ログインするとコメントできます