SPAセキュリティ超入門
SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。
Next.jsを使う必要がない小規模なSPAの最小構成を考えてみた
はじめに React開発におけるNext.jsのプレゼンスが日に日に増している今日この頃ですが、Next.jsを使う必要がない小規模なSPAを作る場合の型が欲しくなり、色々調べて技術選定をした上で実際に作ってみるところまでやったので、その技術選定理由とセットアップ手順を共有したいと思います。 フロントエンドの移り変わりは速いとはいえ、割とホットな技術を選定できたと思うのでしばらくは使っていけそうです（そう思いたい…）。 前提 趣味で小規模なSPAを作る場合を想定 ルーティングなしの単機能アプリ SSRが必要ない モーダルなどの動きのあるUIが必要ない 技術スタック Vite Preact TypeScript Tailwind CSS Cloudflare Pages 技術選定理由 Vite 少し前まではこういうケースではcreate-react-appを使用していましたが、Viteに置き
SPAはコストが高いのか | foo-x
なぜ僕が「SPAはコストが高い」と考えているのか を読みました。 「反論お待ちしています」とのことなので、書いてみます。 結論としては、 コストが低いのは慣れているほうだよ。 どっちも使えるならSPAのほうが低いよ。 です。 前提 元記事で挙げられている前提をまとめます。 用語 SPAとは、クライアント側でビューを構築する方式を指す MPAとは、サーバ側でビューを構築する方式を指す 背景 エンジニアのスキルはあまり高くない 開発期間は1.5年未満 PMFを意識したフェーズであり、チャレンジを繰り返す ログイン機能が存在するサービスを作る コストの定義 エンジニアの採用のしやすさ サービス開発の 初速 サービス開発の 継続性 分業のしやすさ、手伝ってもらいやすさ web標準の挙動の実現のしやすさ セキュアなデータを流出する可能性の高低 バグがあった時の気づきやすさ / 対応のしやすさ ドキュ
なんでもSPAにするんじゃねぇ！という主張のその先 - console.lealog();
Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
フロントエンドエンジニアがSPAを開発する上で理解しておきたいこと - Qiita
はじめに 近年SPA（シングルページアプリケーション）で構築されているWebアプリケーションが増えてきていますが、 新人エンジニアで初めての開発がSPAのWebアプリケーションという場合も少なくないのではないでしょうか。 初めてのWeb開発がSPAでも問題はない（むしろ幸い？）ですが、 使われている技術・思想などを知らずに開発するのは効率が悪いと感じています。 この記事を読むことで、SPAを支える主要な技術や思想を理解していただき、 今後フロントエンドを開発する際の一助になればと思い書きました。 仮想DOM SPAを構築するためのフレームワークは、 データの状態に対してリアクティブに画面を描画するために仮想DOMと呼ばれる技術を使っています。 したがって、SPA構築フレームワークを使ってWebページを作成するには根底にある仮想DOMを知っておく必要があります。 （そもそものDOMについての
レガシーおじさん、SPAを始めてみた。そして限界を知る
はじめに 最近、Webの記事を見てるとReactだVue.jsばかりが上がっていてJSPやERBの話をしてる人は誰もいません。jQueryの記事ももちろん見ない。 つまり、Webだけ見る限りではほとんどの人がSPAを使ってるように見えます。 私はWeb界隈には居るもののどちらかというとバックエンド寄り、もっというとそもそもWebとか関係ない領域を見る事が多いので、ちょっとキャッチアップを兼ねていくつかの個人プロダクトにVue.jsを採用してみました。 jQueryくらいで頭が止まってたので。サーバサイドもマイクロサービスでAPI化が進んでるのでフロントもそれに合った技術を選ばないとですしね。 というわけで、今回はその中で得た知見というか、従来型のサーバサイドでのWeb開発をしていた人の視点でVue.jsをキャッチアップする流れで書いていきたいと思います。 まあ最終的な結論は正直「これすごく
サーバレスで動く研究室のHPを1年間運用してみて - Qiita
指導教員の無茶振りで作り始めたサーバレス+SPA+GraphQL+ChatOpsで研究室のHPが完成してからだいたい1年が経過しました。(参考: 研究室のHPをサーバレス、SPA、GraphQL、ChatOpsで作った)研究室という、人が数年でほとんど入れ替わる特殊な組織内でどのようにHPを継続的に運用していったのか振り返ります。 HPの概要 Slack Botで更新する研究室のHPです。YAMLを添付して@labbot posts createのようにメンションを飛ばすと記事が作成されます。更新、削除もできます。 このHPは、(1) 研究室のみんなが更新できる, (2) 運用、ID/PASS周りの管理コストを最小限にする, の2点を要件として開発したものです。 大きく分けてフロントエンド、サーバーサイド、Slack Botの3つの部分で構成されており、フロントエンドはNuxt(Vue.j
SPA フルリニューアル計画における技術選定や設計思想（2019年2月版） - 30歳からのプログラミング
SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか
Vue.jsで作成したSPAなアプリをGoogle App Engineへデプロイする - Qiita
せっかくGCP使ってるので、SPAなアプリをGoogle App Engine(GAE)へデプロイしてみました。 Vue.jsの場合、https://hogehogehoge.xxx/index.html とindex.html でアクセスするとルーティングが効かないので、GAEの設定でルーティング設定してやる必要がありました。 前提 GCPのアカウントがあり利用できる gcloud コマンドがインストール済み Vue CLIがインストール済み 環境構築 適当にVue.jsのプロジェクトを作成します。ここではVue CLIを利用して作成しています。 Vue CLI 3 https://cli.vuejs.org/ ソースをアップしているので、よければご参考ください。 https://github.com/kai-kou/vue-js-on-gae
Serverless+SPAで超低費用な個人サービス構築のススメ - Qiita
Serverless+SPA構成 最近低費用でサービス運用できないかと、色々試してたのをまとめてみます。 Serverless構成だとEC2と比べて費用が安くなり、SPAであればルーティングがサーバ側制御ではないためS3のバケットに静的html、css、js、画像の配置にてサービス構築が可能となります。 SPAにはReactJSを採用してますが、Vue.jsやUnityとかのサービスでもいけると思います。 良い点ばかりではなく、デメリットも結構あるのでそれを考慮した上で導入しましょう。 個人でお金をかけたくなくてサービス運用したい場合などには良いかもしれません。 （Lambdaの無料枠＋アクセス量のみで計算される。ドメイン費込みでも月約$3程度） メリット ・ とにかく費用が安い ・ AWSの設定周りの変更だけでスケールする デメリット ・ 利用しているサービスが多いため、デプロイ時などの
Vue.js 2.0 で自社プロダクトを SPA + SSR 化した話
2017.05.27 の 初夏の JavaScript 祭 in mixi でお話した時のスライドです。Read less
やっぱりサーバーサイドレンダリングなんかしなくていいやという気持ち - console.lealog();
個人の意見 aka ポエムです。 界隈的には今さら感がすごいけど。 そんな今さらポエった事情としては、 とある案件でSPAをReactで作りつつサーバーサイドレンダリング（以下SSR）をすることになるかも SPAじゃないページもまとめてReactでSSRすることになるかも ただ個人的にはSPA+SSR不要論者 サーバーサイドのテンプレートとしてのReactも冗長なだけやろ派 でも仕事なのでしゃーない（お客様がそう申されるなら・・ なのでやるからには再考察してみて、前向きにやれる要素を見つけたい！ けどどんだけ考えてもやっぱり意義が見つけられなーい( ´Д｀)=3 という感じで、SSR自体の是非はまあどうでもよくて、ただ個人的に「しなくていい」と思ってる気持ちをまとめたものです。 技術に是も非もないです。大事なのはどう使うかなのです。 ちなみにやってみた結果・・とかいう話ではなく、やってない
AWS をフル活用して「サーバレス」な SPA を実装できる「サーバーレスシングルページアプリケーション」を読んだ - kakakakakku blog
6月末に O'Reilly から出版された「サーバーレスシングルページアプリケーション」を読んだ．ただ読むだけじゃ理解度が浅くなってしまうかもしれないなと感じて，今回は全ての実装を写経してみた．そのため少し時間はかかってしまったけど，フロントエンドには苦手意識があったし，今まで SPA の実装もしたことがなかったので，前半部分は特にワクワクしながら楽しめた．今回，監訳者の id:yoshidashingo にご献本を頂き，本当に感謝しかありません．ありがとうございます！と同時に，ガッツリ読もうと意気込んだタイミングで仕事に忙殺されてしまったりして，書評のタイミングが遅れてしまったのはすみません！ サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス 作者:Ben Rady発売
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
ReactSPAをRailsに戻している話 - Speaker Deck
All slide content and descriptions are owned by their creators.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゆる～と - 全国日帰り温泉・銭湯マップ
SPAをパフォーマンス・チューニングした話
リレーションデザイン研究所