Next.jsのstandalone buildをbunとかdenoで1ファイルに固めて、NodeすらないDocker Imageにのせて、Lambdaで動かすやつやりてぇ。
なおるよ！！
Next.jsって意外と検索ボリュームが少ないな。
https://trends.google.co.jp/trends/explore?date=all&q=Next.js,Angular,React,Vue&hl=ja
npm trendsでの結果の方が私の肌感覚と一致する
https://npmtrends.com/@angular/[email protected]/qwik-city-vs-astro-vs-next-vs-react-vs-remix-vs-svelte-vs-vite-vs-vue
Next.jsにおいて、ファイルをサーバーサイドコンポーネントでのみ利用可能にするライブラリをインポートする構文
「AmplifyのDataStoreやめるかぁ」
→ついでにNext.jsのServer Actionに統一するかぁ
→AmplifyのGraphQLのAPIをいい感じに叩けるようにするかぁ
→ついでにAmplifyJSをv5からv6にバージョン上げるかぁ（互換性なし）
→DataStoreのキャッシュ使わなくなったから画面遷移が遅くなったし、サーバー側で動かせるキャッシュ機構作るかぁ
とかやってたら、これまで作ったシステムの土台部分がほぼ書き換えになった。
あちこちのReact ComponentでDataStoreが使われているのを、いつかDataStoreを辞めようと思って少しずつまとめていたが、それでもかなりの量のコードを書き換えることになった。
Next.jsのApp Router、わかるかこんなもんってなって半年放置してたら、今日になって「わかり」が来た。
Amplifyに乗っけたNext.jsから直接DynamoDBたたくの大変っぽい。テーブル名を同定でけへん。
src/middleware.ts
import { NextRequest, NextResponse } from 'next/server'
// IPホワイトリスト
const IP_WHITELIST = ['::1', ...JSON.parse(process.env.IP_WHITELIST ?? "[]")];
const IP_RESTRICT = process.env.IP_RESTRICT === 'true';
export async function middleware(request: NextRequest) {
if (IP_RESTRICT) {
// IPアドレスを取得
let ip: string = request.ip ?? request.headers.get('x-real-ip') ?? '';
// プロキシ経由の場合、x-forwarded-forヘッダーからIPアドレスを取得
const forwardedFor = request.headers.get('x-forwarded-for');
if (!ip && forwardedFor) {
ip = forwardedFor.split(',').at(0) ?? 'Unknown';
}
// 取得したIPアドレスがホワイトリストに含まれているかチェックし、含まれていない場合はアクセス拒否
if (!IP_WHITELIST.includes(ip)) {
return NextResponse.json({ message: 'Unauthorized' }, { status: 401 });
}
}
return NextResponse.next();
}
python3 -m transformers.onnx --model=sentence-transformers/paraphrase-multilingual-mpnet-base-v2 onnx/ --opset=18
optimum-cli onnxruntime quantize --onnx_model ./onnx --output onnx_quantize/ --arm64
服薬をサボってたらメンタルを不調が襲ったので、薬をのんだ。
実家から送られてきた5kgのみかんが残り半分以下になっている。「週明けに職場で配ろう」とか思ってたら、このままなくなる勢いだ。
年末も近づき、実家の親のことが思い出されて情緒が不安定になる。親の寂しさを思ってしまうが、その実私が寂しいのかもしれない。一人暮らしが長い。
そろそろ年末の帰省に向けて、実家への飛行機のチケットを取らねば。
Next.jsのServer Actionを性懲りもなく試しているが、どうにもうまく動かない。エラーが出るが、どこがエラーを出しているのか判別がつかない。諦めよう。
ServerSidePropsに切り替えていく。引数でデータをバケツリレーするのは面倒だが、想定した動作をする可能性が高い。
オンデマンドISRのrevalidateはこれではできない。これでrevalidateされるのはfetchのキャッシュ。
import { revalidatePath } from "next/cache";
import { redirect } from "next/navigation";
export default async function revalidate({ params }: any) {
const { kno } = params;
revalidatePath(`/${kno}`);
redirect(`/${kno}`);
}
一年以上に渡って放置していた耳鳴りで耳鼻科に来たら、慢性鼻腔炎とのこと。
薬を鼻から入れてもらった。
次の来院は来週の土曜日2023年11月25日の予定。
近所のうどん屋さんに再訪して、アボカドうどんを頂いた。瞬間風速的に美味しいわけじゃないんだけど、定期的に食べたくなる良さがある。写真左上のやつは茎ブロッコリーの天麩羅らしい。こちらも美味しい。何だこのうどん屋。贅沢かよ。
Misskeyのルビ機能実装に伴い、カタカナ・希哲館訳語変換サービスの改修をした。
ついでに生のHTMLとJavaScriptで書いていたのを、Next.jsに置き換えた。
あと、変換エンジン部分も複合語の変換に対応させた。ただし、長文を入れるとしばらく固まる。
Misskeyへの共有機能もちょっとテクった。GETパラメータであれこれやっている。説明は難しいので省く。君の目で確かめてくれ！ 1万円とかくれたら教えるのはやぶさかでない。
こっそりデプロイ済みだが、Misskey.ioがアップデートされると共に報知したい。
『t_wの輪郭』がライトモードに対応できていないことが発覚した。１ヶ月近く気づかずに放置していた。なんで誰も指摘してくれないのぴえんとかMisskey.ioで言ってたら、「ダークモード使ってるオタクしかいない」という指摘が来た。異常なコミュニティだわ……。
今月のAWS利用料が60USDほどになりそうなことが発覚し、財布へのダメージに慄いている。すべて『t_wの輪郭』をAmplifyに移行したせいだ。AppSyncが全面的にコストを引き上げている。
取り急ぎ個別ページのgetServerSidePropsをgetStaticPropsに切り替え、データの生成結果が24時間に渡って再利用されるようにした。これでマシになるだろう。問題は内容の更新に追従できないことだが、On-demand ISRを導入して、ボタンで内容の更新を掛けることができるようにした。ボタンの場所は秘密♥。まあ連打されても、その上にキャッシュを噛ませているので、特に問題はないようにしてある。revalidateのAPIは隠すのが通説っぽいけど、ウェブからボタンで叩けたほうが便利っちゃ便利だろう。
あとはRSS生成時に生APIを叩いていたので、こちらも24時間再利用されるキャッシュを使うようにした。こっちが本命っぽい雰囲気はある。
ついでにNext.jsを14にアップデートした。
ネットワークタグを見ている感じでは、リンク先のデータを先に取得しているっぽい？getStaticPropsによるものだろうか。なんか表示がめっちゃ速くなった。getStaticPropsを使っていないトップページは変化がない。トップページもgetStaticPropsにしたくなる。
朝、体が冷え切って目が覚める温度になってきた。そろそろ布団を出さないと体調を悪くしてしまう。
上司と、私の今年の目標達成率について1 on 1をした。お互いに、「毎日の定例で30分話してるし、話すこと無くね？」みたいな感じだったが、普通に予定していた時間いっぱいまで話した。評価は上司の更に上がするので、まあどうなることやらである。
設定した目標を完全に忘れていたが、自己評価においては目標達成率は思いの外良かった。ちゃんと、自分が走りそうな方向に目標を置いておいたのが良かった。
ちなみにこの目標管理は給与とかボーナスには影響しない。という建付け。多分参考にはする。
仕事で問い合わせを出して、その回答待ちなのを良いことに、すげーダラダラしていた。
Next.jsでSMTPを受ける方法とか検討していた。無理そう。コレができるとシステムでできることの幅が広がるのだが。普通にマネージドサービスを使ったほうが良いんだろう。
そうこうしていたところ、仕事でクラウド上に作ってるシステムが、全部吹っ飛んでいることが判明した。DBやらファイルやらユーザーアカウントやらが全部消えた。まだ本番運用前で良かった。
上司と話したところ、週明けに原因調査しようということになった。定時直前に発覚して、上司に相談した上で泣きながら帰宅した。
何も心当たりのある操作してないんだよなぁ……。クラウドのコンソールにログインするアカウントが不正ログインされた形跡もなかった。クラウドのシステム自体の不具合で消えたんだったら、一発アウトなので別のクラウドに移行しないといけなくなってしまう。
CI/CD・DB・ストレージ・認証・認可・API生成の全部入りのマネージドサービス（フレームワーク付き）でこの事象が起きちゃったので、まじで影響範囲がでかい。死ぬ。たのむ、俺のミスであってくれ。
Fediverseで「複雑なマネージドサービスって怖いよね〜〜」という話をしていた。はい。実感。
布団を出してカバーを付けた。カバーをうまく付けられなくてモタモタしてしまった。疲れで不器用になっている。俺はもうだめだ。
フロントエンドのビルドの設定をいじる（baseDirectory: .nextにする）。
frontend:
phases:
preBuild:
commands:
- npm ci
build:
commands:
- npm run build
artifacts:
baseDirectory: .next
files:
- '**/*'
cache:
paths:
- node_modules/**/*
WEB_COMPUTEに切り替える。
aws amplify update-app --app-id {app_id} --platform WEB_COMPUTE
フレームワークを誤認識する場合はNext.jsと明示する。
aws amplify update-branch --app-id <value> --branch-name <value> --framework 'Next.js - SSR'
https://github.com/aws-amplify/amplify-hosting/issues/3168
上記設定の後に再構築する。
コマンドをやるときは、CloudShellが便利。
Node.js 20を指定する
「ビルドの設定」ページの「Build image settings」の項から変更できる
特に記憶に無いです。
「Next.jsを使えば忌々しいAmplifyのDataStoreを無くせるんじゃね？」とか思って、社内システムの移植を開始した。もともとReactで動いていたので、3時間ほどでシステムがNext.jsの上で動くようになった。Next.jsの恩恵が受けられるのはこれからだ。
「Next.jsを使えばBERTでSentence Embeddingを取るAPIをサーバーレスでつくれるんじゃね？」とかおもって実装した結果、比較的高性能な開発機であっても計算に3秒もかかることがわかり、検索には使えず無事死亡した。
「あれ」ってどんなんだったっけと思って、デライトで検索しようとしたところ、デライトが落ちていた(障害のお知らせ)。普段当たり前のようにデライトが使えているが、knownetの開発を通じてデライトが安定稼働していたことの異常さに気付きつつある。knownetの方はちゃんと動いている期間のほうが短い。
探そうとしていた情報については『t_wの輪郭』を参照して見つけられた。いざというときの保証として機能してくれた。
ブログのお引越し作業中
実質システムの作り直しなのでまだまだ時間がかかる
うぐー！！！！純朴なPostgresqlで作ったブログシステムに、読み込み速度で勝てない！！DynamoDB使ってるのに！！！
Postgresql先生、DynamoDBで2秒かかってるものを、300msで返してくるのは止めていただきたく。
DynamoDBつーか、AppSyncのAPIを叩きまくってるアレのせいな気はする。
Next.jsのcacheを有効化したら、ページの取得に2秒とか要していたのが、100msになった。良き。
むむ、localhostで動いてたのをAWSに移すと遅くなるな。そりゃそうか。
AWSに移したら遅くなったのが気に入らなかったので、CloudFrontに乗っけた。
運が良くCloudFrontのキャッシュにHitすると10ms程度でページが取得されるようになった。
https://main.d21776nrisgiy.amplifyapp.com/
version: 1
backend:
phases:
preBuild:
commands:
- wget --no-verbose https://go.dev/dl/go1.21.0.linux-amd64.tar.gz
- rm -rf /usr/local/go
- tar -C /usr/local -xzf go1.21.0.linux-amd64.tar.gz
build:
commands:
- '# Execute Amplify CLI with the helper script'
- export PATH=$PATH:/usr/local/go/bin
- go version
- amplifyPush --simple
frontend:
phases:
preBuild:
commands:
- npm ci
build:
commands:
- npm run build
artifacts:
baseDirectory: .next
files:
- '**/*'
cache:
paths:
- node_modules/**/*
Next.jsとGraphQLという現代兵器を使うから高速化出来るかな〜〜と思ったけど、むしろ遅くなってて残念。
むしろなんのチューニングもしてないPostgreSQLとExpress.jsでコレだけ速い現行版が謎。
現行版と比べてみると、無駄なクエリを投げてるな。コレを現行版に似せてやればよろしい。
現行版はキャッシュがなければ170msぐらいで飛んでくるので、そこまで行ければ嬉しい。
AmplifyでNext.jsが動いたああああああ
https://main.du4rqori3cgjf.amplifyapp.com/
こっからどうしたら良かったんだっけ……
Next.js触ったのだいぶ前なので忘れてしまった。
ノリと勢いで『t_wの輪郭』をReactで作り直しだウェーイってしてるけど、SEO死ぬんじゃねこれ
あとOGP対応無理くねコレ
何ならRSSも無理っぽい
AWS AmplifyでSSRする方法探すか
使用できますAWS Amplifyサーバー側レンダリング (SSR) を使用する Web アプリをデプロイしてホストします。現在、Amplify ホスティングは Next.js フレームワークを使用して作成されたアプリをサポートしています。
公式の日本語が怪しいけど、AWS AmplifyはNext.jsでSSR出来るらしい。
React+DataStoreからNext.jsに切り替えるぞッ！！！！
ここまで作ったフロントエンドを捨てることになるけど、メリットはあるし、やるしかねぇ。
We recommend using Static Generation over Server-side Rendering for performance reasons. Statically generated pages can be cached by CDN with no extra configuration to boost performance. However, in some cases, Server-side Rendering might be the only option.
パフォーマンス上の理由から、サーバー側レンダリングよりも静的生成を使用することをお勧めします。静的に生成されたページは、パフォーマンスを向上させるための追加構成なしで CDN によってキャッシュできます。ただし、場合によっては、サーバー側のレンダリングが唯一のオプションになることがあります。