Cloudflare Workers それは Frontend / Node.js が CDN Edge Side まで拡張されるもの
最近は Cloudflare Workers が熱くて、週末はずっとその調査しています。この記事はそのまとめです。 注意点として、手元でいろいろなパターンで動かして試してはいますが、プロダクション環境で運用したわけではないです。それを踏まえた上でお読みください。 特に断りが無い限り、引用文は DeepL で翻訳したものです。 Cloudflare Workers とはなにか Cloudflare Workers | サーバーレスコンピューティング | Cloudflare 一言でいうなら 「ServiceWorker の API が CDN Edge 上で動く JavaScript 処理系」 です。 Technology Radar では、まだ ASSESS(調査) フェーズという扱いです。 Cloudflare Workers | Technology Radar | ThoughtWo
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
大統一 Node ツールチェイン Rome の野望 現状の実装
つい先日 beta リリースされたフロントエンドのツールチェインの Rome について、その思想とコードを読んだ結果の現状について。 Rome Frontend Toolchain この記事は公式ドキュメント以外にもソースを読んで得られた undocumented な部分も含んでいるので、すぐ古くなる。その前提で読むように。 問題の認識とその解決手段 フロントエンドの最適化は実行前のプリプロセスに、エコシステムの開発リソースの多くが当てられている。Node のツールチェインが発達するにつれて、自前の パーサ+AST 定義を持つ実装が増えていった歴史がある。 acorn(estree) babel prettier typescript terser それぞれのツールの生成する AST はそのツールの都合で微妙に/もしくは大幅に定義がずれている。typescript に至っては完全に別物。こ
next.js + vercel + firebase authentication で JWT の検証を行う + Graphql
今個人で作ってるアプリの 認証 + Graphql の部分を抜き出して GitHub に公開した。 mizchi/next-boilerplate-20200727 next.js + vercel + firebase は (パーツを良く選べば) 最高 next.js はルーティングを持つページを作るには最高で、サーバー、静的サイト、JAM スタック、AMP と必要に応じて選択できる。React ベースならこれ一択。 認証サーバーの実装は毎度疲れるし、Firebase Athunetication はこの点においては OAuth Secret を置くだけ + Custom Provider も作れるので、最高。 それと比べて firestore は、ちょっと前に firestore べったりでアプリを試作したことがあったのだが、型がないためにかなり扱いづらく、また読み書きの速度が遅くパフ
ノーコードは形を変えた現代のRPGツクールなのではないか
この記事について。 2030 年 「エンジニアです。コードは書けません。」｜__shinji__｜ note 自分はそもそもビジュアルプログラミングやオーサリングに興味があり、ノーコードは興味の範疇でありつつも、現状のもの、現状の「コード抜きで作れる」ような謳い文句は厳しいと思っています。それを、RPG ツクールを例に説明します。 はじめに、ノーコードを分類する 本記事では、「専用の管理画面で編集し、出力のためにコードを書かない、もしくはコピペ程度」のものをノーコードとして扱います。 その中でさらに種類ごとに分類してみます。このような定義があるわけではなく、自分の主観的で暫定的な分類です。 タイプ 1: データベースから自動的にフォームを生成 Google App Sheet MS Power Apps タイプ 2: 高水準 API のパイプライン Zapier IFTTT 古の Yaho
IE First を避ける
まず、去年の実績として、IE のシェアが 9% から 5% になっています。 Browser Market Share Japan | StatCounter Global Stats 世界だと 1.4% です。これは途上国などでは Android Chrome が支配的だからです。 https://gs.statcounter.com/browser-market-share/all 国内で「IE シェア」などでググって出るサイトは 9% と出ていますが、これはデスクトップのみの数字で、モバイルを含めた数字は 5%前後です。日本はさらに Chrome ベースの新 MS Edge の正式リリースがコロナと確定申告の影響で延期されており、リリースのタイミングでさらに減ることが予想されます。 去年の実績値でいえば、来年度には 2% 台、再来年には 1%を切っている可能性があります。これは to
Hello, Deno v1.0.0
Deno 1.0.0 がリリースされて、ちょっと遊んでみたので、その感想。 圧倒的ゼロインストール感 自分は mac なので brew install deno しました。deno コマンドが入ります。セットアップはこれで終わり。 GitHub の trending に上がっていた https://github.com/oakserver/oak という web server を試してみます。 // server.ts import { Application } from "https://deno.land/x/oak/mod.ts"; const app = new Application(); app.use((ctx) => { ctx.response.body = "Hello World!"; }); await app.listen({ port: 8000 }); この
next.js の amp モードで tailwind.css を purgecss と合わせて使う
このリポジトリ でやったこと。 やろうとしたこと tailwind.css は Utility First と銘打った CSS フレームワークで、コンポーネント化を前提としたモダンフレームワークと相性がいいです。今回は next.js の amp-mode で tailwind を使おうとしてみました。 Tailwind CSS - A Utility-First CSS Framework for Rapidly Building Custom Designs 問題 前提として、 amp には inline css の容量制限があり、75kb を超えると AMP と認識されなくなります。 tailwind はビルドして使うのが前提のフレームワークですが、全部入りの tailwind.min.css は 1.3 M あります。これでは到底、75 kb に収まりません。 AMP の CSS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
