令和のフルスタックWebフレームワークは、T3 Stackじゃないかな〜

qiita.com

ここに書いてあるBeforeのコードに強い危機感を覚えている。あそこまでこんがらがってはいないけど、jQueryとテンプレートエンジンでお茶を濁してバックエンドとフロントエンドの境界が曖昧になり、つらみがある点は自分も同じなので。

RailsでフルスタックWebフレームワークの扉が開き、様々な言語でRailsインスパイアなWebフレームワークが作られ、jQueryと共に成長してきたはいいけど、UIの表現力が乏しいのでフロントエンド周辺がカオスになってしまう。すごくよくある話だと思う。

この状況だと、フロントエンドがどんどんバックエンドを侵食すべきで、フロントが書ける人間がバックエンドを書けばいい。で、TypeScriptで統一しちゃって、メンバーがフロント・バックの両方を書けるようになるのが一番いい気がしている。なので、T3 Stackに大いに可能性を感じている。

今まで(Rails,Cake.Django等)のフルスタックなWebフレームワークは、MVCのMCがメイン。Vが弱くHTMLを吐き出すテンプレートエンジンがある程度で、UIの状態管理がフレームワーク側でできないので、jQueryでカオス(煩雑で似たようなコード)を多く生み出してしまう。UIに関する変更コストって結構高いんだよね。

令和のフルスタックは、Cを意識しなくて良くなる。エンドポイントが自動で生えるから。tRPCとか使うと。VとMがスキーマを共有してつながり、Viewは宣言的にスッキリと作れ単体でテスト可能になる。いいじゃん、これで。この開発体験で気持ちよい。

TypeScriptのエコシステムはどんどん拡大している。ReactからZodでバリデーション決めてtRPC叩いてORMまで一気通貫。T3 Stackがまさにそれ。

３年後ぐらいにTypeScriptできるエンジニアの市場価値がもっと上がる！はず・・・！

T3 Stackすげえ。2023年はこれを追いかけるわ。

create.t3.gg

ちらっとTodoアプリを作ってみたけど、これが令和のフルスタックWebフレームワークなのかと驚いた。特に tRPC がすごい。どういう理屈なのかわからないけど、フロントとバックをシームレスにつなげてくれる。APIのエンドポイントを書かなくていい（自動で作ってくれるのだろう)という体験は初めてだった。

Webシステムのつらみの多くはフロントとバックエンドがつながってないこと。CakePHP+jQuery製UIをReactでシンプルにした件 - Qiitaが典型例。状態管理やUIの再構築を中途半端にjQueryとPHPのテンプレートエンジンでやると「おお、もう」となる。それが嫌でReactに手を出したらNext.jsが流行りだして、T3 Stackが出てきた。

Node.jsのおかげで、JavaScriptはクライアントからサーバーサイドまで実装できるようになり、TypeScriptで最強の型演算ができるようになって、フロントとバックエンドが真につながったのかも。それが2022年なのかもしれん。フロントエンド出来る人がバックのコード書けるのが一番生産性高いじゃん。

Pythonより面白いわ。TypeScriptがんばろっと！！

イミュータブルの次は何が来るのかな

ここ数年のソフトウェア開発の大きな傾向として「イミュータブル(不変)」というキーワードがあると思う。

インフラはIaCが当たり前になった。IaCは、インフラのイミュータブル化。ChefやAnsibleが10年ぐらい前に出てきてIaCのムーブメントがあって、インフラはイミュータブルになった。作ったインフラを都度変更するのでなく、スクリプトを書いてリビルドすれば最新化されるので、不変という意味。フレッシュな環境が持ち運べるようになるなんて、ホンマに素晴らしい。

フロントエンドはReact/Vue/Flutterに代表される、const/finalな宣言的UI。特に関数が宣言的になる(関数型プログラミング)とフロントエンドは相性が良い。サーバーサイドもなるべくconst/finalが良いし、多分ほとんどの変数はfinalになるでしょう。イミュータブルでないコードを書くとLintにぶち殺すって言われる時代だし。

自分はPythonの書き味が好きだけど、結局人類には型が必要なんだよね。

イミュータブルなプログラミングをするためには、型で表現できないとなんにもならないので。コンパイラがチェックできないし。昨今流行している T3 Stackの肝は、データベース、サーバーサイド、フロントエンドでスキーマ(型)を共有できることだよね。そこに辿り着くためには Stackの言葉にあるように、色んなライブラリを積み上げる必要があるわけなんだけど。

オブジェクトという単位でプログラミングを行うことから大きなパラダイムシフトが起こるような気はしない。RDBに変わるデータ演算の仕組みが無いのと同じで、それより合理的な仕組みがなさそう。関数型プログラミングでもオブジェクトは必要だし。

プログラミングの表現としてはオブジェクトを宣言的に使う感じになっていって、webAssemblyの勃興によりブラウザがよりネイティブアプリに近づいてくのかな。

WTFormsで GETで飛んできたパラメータを捕捉する

ちょっとハマった。結論から言うとこれで動いた。

@app.route("aaa")
def user_summary():
    form = UserForm(request.args)

request.argsを引数に入れると、フィールドの変数と同じ名前のパラメータのデータを紐付けてくれる。 この引数が入っていないと、フィールドのdata変数が全部 Noneになってしまう！

class UserForm(FlaskForm):
   keyword = StringField("キーワード")

HTMLはこんな感じ。

  <form action=" method="get">
        <div class="row g-1 inline">
            <div class="col-auto">
                {{form.keyword.label}}
            </div>
            <div class="col-auto">
                {{ form.keyword(class_="form-control")}}
            </div>
            <div class="col-auto">
              <input type="submit" value="検索" class="btn btn-primary" class="form-control" />
            </div>
        </div>
    </form>

Cloud Runのアイドル時間課金がすごく大きくなってしまった話

今月の半ばから、VPS/Herokuを卒業して、全てGCPに移してCloudSQL x Cloud Runに切り替えた。

BtoB向けのシステムをやっている関係上、営業時間がすぎるとほとんどアクセスされない。CloudRunの最小インスタンスを1にしておくと、アイドル時間にもメモリとCPUがAllocateされるため、課金対象になることに今更気づく。

アイドルの課金額が実際にリクエストを処理している課金額より圧倒的に高くなってしまい、これは・・・と。

• 最小インスタンスをゼロに（これでアイドルしてるインスタンスが消えるはず）
• 営業時間(*/30 8-19 * * 1-5)内にヘルスチェックするだけのスケジューラーを仕込んだ。

20時以降にダウンタイムが発生した所で、多分2〜3秒だし。

そんな所で。

2022.12.26 追記

最小インスタンスをゼロにしてアイドル時間を減らしたら、課金額が大幅に減りました。立ち上がりには1〜2秒かかりますね。ブーストONにしても。全然OKです。

2023.06.10 追記

常にCPUを割り当てる設定にすると、料金が跳ね上がった。CPUに仕事をさせると高くなるよね。 Cloud Run、もしかしてお高い・・・？ 小規模ならGAEのほうがコスパ高いんかな。

Tailwind CSSを学習しているメモ

MITなBootstrapテンプレートをゴニョゴニョして今ひとつな管理画面テンプレートを場当たり的なCSSとjQueryでカオスになる人生に終わりを告げたいので、Svelte/Reactでリスキリングしている。

というわけで、CSSの再学習にちょうどよいなと思ったのが、ユーティリティのCSSがたくさん詰まっているTailwind。ショートハンドなクラス名の意味や指定を学びつつ、今どきのCSSだとこうやって書くんだなという文法の整理をしている。

確かに覚えないといけないCSSクラスはいっぱいあるけど、チートシート的なサイトはいっぱいあるのでそこまで辛くない。CSS in JSみたいなハードコアなやり方に比べると良さげ。

flexを知らないと何も出来ないな

ちょっとレイアウトを組もうとすると、display:flexをちゃんと知らないと何も出来ないね。まぁ大して覚えることもないけど。

focusなんて疑似要素忘れてた

Tabなどでinput要素にフォーカスが当たった時のものだ。思い出した。

odd,evenなんかも用意してある

<tr class="odd:bg-white even:bg-slate-50"> みたいな書き方ができる。便利〜。

インプット要素のスタイリング

• disable
• invalid
• required
• checked

formのinput要素の状態に応じてスタイリングをまとめて組むことができるみたい。

一旦終わり。随時追記。

Google Playにリリースする時だけ、Firebase Authenticationが動かない

Firebase Authenticationに限らないと思いますが、半日ハマったので備忘録。こちらにすべてが書いてあった。

minpro.net

「Google Play」を経由してAndroidアプリとしてリリースする場合は、Android Studioで取得した「SHA-1」「SHA-256」ではなく、「Google Play Console」で設定されているものをFirebaseのコンソールに追加する必要があります。

おーん。まじか。知らなかった。道理で直接インストールしたRelease Buildが動くわけだ。

公式ドキュメントもう1回見てくる。探せなかった。