CloudflareでもFastlyでもVercelでもDenoでもBunでもService Workerでも動く
HonoというWebフレームワークを作っています。 当初はCloudflare Workers向けに作っていたのですが、同じCDNであるFastlyのエッジランタイム、Compute@Edgeでも動くことが分かりました。また、Next.jsのEdge MiddlewareもしくはEdge API RoutesとしてVercelの環境でも動きます。そして、少々手を加えるとDenoでも動きました。もちろんDeno Deployにもデプロイできます。さらに、先程レポジトリが一般公開されたYet AnotherなJavaScriptランタイムのBunでも手を加えず動きました。 この「CloudflareでもFastlyでもVercelでもDenoでもBunでも動いた件」が、なかなか面白かったのでそれについて書きます。 Web標準のAPI これらの環境で同じように動くのは、JavaScriptでかつ
2020年に立ち上げたWebフロントエンド構成の振り返り
こんにちは、よしこです。 株式会社ナレッジワーク というスタートアップで、2020年4月の創業時から一人目のフロントエンドエンジニアをしています。 初期に考えて組み上げたスタックで1年半ほど開発・運用してみて、なかなか快適に日々開発ができているので 新規開発のプロダクト立ち上げ時にどのようにフロントエンドを構築したのか？ 立ち上げから1年以上開発・運用を続けてきた今、それらの選択はどうだったのか？ を記事にして振り返り、公開したいなと思いました。 （プロダクトの内容はステルスで進めていてあまり対外的な発信ができないので、かわりに技術的なところはどんどんオープンにしていきたいなという気持ちがあります） いろいろな項目ごとに振り返りたいので、この記事は各項目を横断するindexとして項目ごとの概要を簡単に説明し、深堀りは項目ごとに追って詳細な記事を書いていく予定です！ 前提 プロダクトとしての
Next.jsアプリをVercelからGoogle Cloudに移行した話
ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
