Next.js Conf 2024 全部聞いてみた
こんにちは、絶賛スウェーデンに留学中のきたぴーと申します！今回は Next.js Conf 2024 をリアタイ視聴して内容を大まかにまとめてみたので記事にして共有してみようと思います！ 聞いてみようと思った背景 個人開発でもインターンでもハッカソンでも、自分はいつでも Next.js にお世話になっているので最新機能や、Next.js 開発チームの思想を直接聞くことで視座を少しでも近づけたいと思ったのがきっかけです。タイムテーブルを見ると、「サーバコンポーネントで向上する UX」のような Next.js の機能について扱うものから、Perplexity や PayPal での導入事例のような応用例まで取り上げられていた、かつ Vercel が公式でピックアップしたものなので情報の密度も濃いものだろうと、非常に興味が湧きました。あとは時間の都合も良く、日本だったら深夜の 1:30 スタート
SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトーク
SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は
Cloudflare Workers | サーバーレスアプリケーションを構築
最新クラウド向けのアプリケーションを構築サーバーレスコードをデプロイして、優れたパフォーマンス、信頼性、拡張性をグローバルに実現しましょう。 Cloudflareグローバルネットワークの全世界330か所以上のデータセンターへグローバルにデプロイする際にインフラの設定や保守をすることなく、Web機能やアプリケーションを構築しましょう。
結合テストを書くときはコードベースを分離している
新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手本的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 3, 4年前から僕と付き合いがある人からすると、 「「「あの sadnessOjisan がテストを書くだと！！！」」」 という感じだと思うのだが、最近はテストに思うところもあってちゃんと書いている。 そしてそのテストコードだが、基本的にはアプリケーションから分離して書いている。その話をしたい。 OGP OGP は野方ホープで海苔が分離されて出てきた時の画像だ。 アプリケーションから分離したテストとはどういうことか 最終的にはテスト対象のサーバーを Docker コンテナで固めて、そのコンテナに対して HTTP リクエストを投げてその結果や DB の中身を検証するコンテナを docker
【感想】『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』：Lambdaで本格サービス開発まで - Rのつく財団入り口
サーバーレスアプリケーション開発ガイド Lambda関数を用いたサーバーレス開発をもっと知っておこうと思って読んだ本の感想です。2018年4月刊行、サーバーレスの主要サービス解説にコードはPython、のみならずフロントはVue.jsを使った本格開発まで、実践的な内容が詰まった本です。 作者は現Amazon Web Services Japan所属のKeisuke69こと西谷圭介さん。Twitterでもよくお見掛けします。(@Keisuke69) サーバーレスアプリケーション開発ガイド Chapter1 サーバーレスアプリケーションの概要 1-1 サーバーレスアプリケーションとは 1-2 ユースケースとアーキテクチャパターン 1-3 サーバーレスアプリケーションのライフサイクル管理 Chapter2 Amazon Web Services（AWS）利用の準備 Chapter3 インフラを自
AWS Application Load Balancer 複数ポートの設定メモ
AWS Application Load Balancer は、アプリケーションレイヤーで負荷分散ができるロードバランサーです。HTTPリクエストを元に、ロードバランサー配下のサーバーに処理を振り分けられるのが特徴とされています。また、HTTP/2、WebSocket、セッション維持などにも対応しています。 Application Load Balancer の設定は、HTTP(S) 標準のポート80番やポート443番だけで設定するのであれば、特に迷うことはないと思いますが、たまたまロードバランサーやサーバーの待ち受けポートを変えて複数設定することがあり、ポートの設定方法に小一時間悩んでしまいました。そこで今回は、AWS Application Load Balancer を複数ポートで設定する手順をメモしておこうと思います。
SPA+SSR+APIで構成したWebアプリケーションのセッション管理 - Pepabo Tech Portal
カラーミーショップ サービス基盤チームのkymmtです。この記事では、サーバサイドレンダリングするシングルページアプリケーションとAPIサーバからなるWebアプリケーションのセッション管理方法について紹介します。 アプリケーションの構成 構成の概要 今回は例としてEC事業部で提供するカラーミーリピートをとりあげます。構成としては、Railsで作られたAPIサーバ1と、Vue.jsで作られたシングルページアプリケーション(SPA)からなります。また、SPAはExpressが動くフロントエンドサーバでサーバサイドレンダリング(SSR)します。APIサーバはSPAかフロントエンドサーバだけが呼び出します。各ロールはサブドメインが異なります。 APIサーバでセッションIDを持つCookieを発行し、Redisを用いてセッション管理します。また、APIサーバへのセッションが有効なリクエストはフロント
AWS Amplify と Vue.js を使って、基本的な認証と CRUD 操作ができる Web アプリケーションを作る- builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは、JAWS-UG 浜松支部の松井です。 普段からモノリシックな環境やそれに準じる環境での Web アプリケーションの開発、保守に取り組んでいますが、継続的にサービスを運用していく上では様々な悩みが尽きません。 OS のバージョンアップ、セキュリティパッチはどうするか ? 言語やミドルウェアのバージョンはどうするか ? ステージング、本番等の環境のデプロイはどうするか ? コスト最適化はどうするか ? etc・・・ そこで、サーバーレスアーキテクチャを採用することにより、こう言ったホストマシンやネットワークの管理に起因する悩みを軽減することができます。 とはいえ、いきなりサーバーレスに着手するとしても、 本当にちゃんと動くのか ? 設計、構築が難しいのではないか ? コストはどのくらいかかるのか ? まずどこから手をつければ良いのか ? と言った疑問があると思います。 今回はそう言
【書評】「初めてのGraphQL」を読んで、サーバーレスアプリケーションのための新しい武器を手に入れるのだ | DevelopersIO
2020年11月12日追記： Apollo Client V3 がリリースされ、大幅に内容がかわっています。本書のサンプル記述はV2ですので、利用法が異なる可能性があります。ご注意ください。 apollo-client/CHANGELOG.md at main · apollographql/apollo-client きっかけは サーバーレスアプリケーションの実装で 本格的に AWS AppSync を使いたいと考えたところでした。Amplify + AppSync なチュートリアルやサンプルもたくさんありますが、要素技術を習得してから使い始めたいと考えました。私が執着している考えのひとつに、 サービスやライブラリがどこまでの責任をカバーしてくれるのかを把握してから使う があります。今回の場合だと、 AWS AppSync が GraphQL の実装サービスとして、どこまでやってくれるの
Docker でロードバランサ・アプリケーションサーバ・DBサーバの環境構築 - A Memorandum
はじめに Nginx でロードバランサを構成する Webサーバ1号機の作成 Webサーバ2号機の作成 ロードバランサの作成 ロードバランサとWebサーバの起動 Web アプリケーションの準備 Docker でアプリケーションをビルドする DBサーバの準備 ロードバランサとアプリケーションサーバの起動 まとめ はじめに 前回は Docker のインストールからイメージビルド・コンテナ起動・Compose までの流れをみてきました。 blog1.mammb.com 今回は以下のような、一般的な Web アプリケーションの開発環境を構築していきます。 前回の記事とあわせて、Docker の活用方法を理解いただければと思います。 Nginx でロードバランサを構成する 最初に、単純な Web サーバを Nginx でロードバランシングする環境を作成して動作を見てみます。 このような構成となります。
「AWS Toolkit for Visual Studio Code」正式版がリリース。AWS Lambdaのステップ実行、ローカルデバッグなど可能に
AWSはオープンソースとして開発されているコードエディタVisual Studio Codeの拡張機能として、これまでプレビュー公開されていた「AWS Toolkit for Visual Studio Code」が正式版になったことを発表しました。 AWS Toolkit for Visual Studio Codeと、AWS Command Line Interface（AWS CLI）やDockerなどを組み合わせることで、サーバレスコンピューティング環境であるAWS Lambdaのローカル環境でのステップ実行やブレークポイントの設定などのデバッグ操作などが可能になります。 そして開発したアプリケーションをAWSの任意のリージョンへのデプロイもVisual Studio Codeから手軽に行えるようになります。 AWS Lambdaのローカルデバッグが可能 AWS Toolkit f
新しいフレームワークを学ぶならTodoMVCではなくRealWorldを参考にしよう - Runner in the High
よく新しいフレームワークを学ぶにはTodoアプリを作ってみるのがよい、と言われる。実際、Todoアプリを様々なフレームワークで作ってみたサンプルをまとめたサイトもあったりする。 ところが、実際に業務で作るようなアプリケーションはTodoアプリの範疇を超えている。とくにSPAにもなると、画面遷移やWebAPI連携、大規模な状態管理などなどの条件が増えるので、Todoアプリを作っているときには考慮できていなかった大変さが出てくる。 そこで参考になるのが RealWorld example apps と呼ばれるプロジェクト 端的に言うと、TodoMVCの大規模版。 規定のスペックに沿って、様々なウェブフレームワークで作られたアプリケーションのリポジトリがリストアップされている。 スペックについて "Conduit" is a social blogging site (i.e. a Medium
AWS公式で「形で始めるサーバーレス設計」が紹介されています！ | DevelopersIO
AWS公式で「形で始めるサーバーレス設計」が紹介されています。この内容をご紹介するとともに、簡単ですがひとことコメントを載せました。 はじめに サーバーレス開発部の藤井元貴です。 サーバーレスな設計や開発は意外と難しいものです。特に「やりたいこと」が「サーバーレス」で実現できるのか？ を常に意識し続け、トライ・アンド・エラーを繰り返すことが重要です。 そこで、先日みつけた形で始めるサーバーレス設計をご紹介します。簡単ですが、ひとことコメントもあります。 上記の内容を知らなくとも、結果的に「あ、同じ構成（考え方）だ！」となる場合が多いです。 そのため、事前に知っておくことで手札を増やすことができ、より効率よくサーバーレスな設計を実現できると思います。 おすすめの方 サーバーレスに興味がある サーバーレスな設計を知りたい 形で始めるサーバーレス設計 下記となります！ 形で始めるサーバーレス設計
GraphQLを使ったアプリケーションがリリースされたので勘所を考えた - Feedforce Developer Blog
小飼です。Dropbox上場のニュースをみて『Rustで上場』という標語を考えたんですが、ロジックが乱暴過ぎるとの評価を頂きました。 さて、フィードフォースでは去る3月8日広告出稿・運用支援ツール『EC Booster』をリリースしました。 この新サービスにはクライアント・サーバ間コミュニケーションのインターフェースにGraphQLを採用しています。 GitHub, Apolloなど、海外では採用事例の増えてきている印象のあるGraphQLですが、国内における採用事例はまだあまり多くはないようです。 そこで本稿では、フィードフォースで実際のプロダクションに採用してみての、初期の使用感などをお伝えしたいと思います。 なお、本アプリケーションはAPIサーバ及びアセット配信サーバとしてのRailsアプリケーションが、 React/Apolloで構築されたクライアント側アプリケーションと、Grap
メモ DigdagによるRedshift + EMRの自動制御とデータ分析アプリケーションの開発 #tdtech - by shigemk2
digdag github.com (途中参加) ワークフローエンジン Aをやって、Bをやって、でもBが失敗したらCをやる、というのを、コードを書かないで制御する サーバー どこの環境でも動くこと ワークフローが手元でも動く ステップを足す→ローカルで実行する サーバーでアプローチすればサーバーで動く Luigi 上から下へワークフローを動かす digdag digdag ネスト出来るようにした グループを作れる ある別のシステムがファイルをアップロードする→アップロードできたらコピーする パラメータは一部ビルトイン tdのクエリを実行する redshiftのクエリを実行する big query td for each ポスグレ メール などなど… slackへ通知も出来る ローカルで実行する→デプロイする サーバAで実行する→サーバBでも実行できるようにする 特定のプログラミング言語を特
金融機関の口座集約アプリの危険性について - プログラマでありたい
先日、銀行口座の口座集約のとあるiOSアプリの記事について、危険だよなぁと何気なく呟いたら中の人からリプを貰いました。Twitterで呟いているのですが、文字だけでは解りにくいのでまとめてみます。ただ、そのアプリ固有の問題ではなく、構造的な問題なのでアプリ名は開示しません。（安全なので安心ですという論調は、どうかと思いますが。。。） 口座集約アプリの構造 口座集約のアプリは、アカウント・アグリゲーション(Account aggregation)サービスと言われています。サービスの実体は、複数の銀行の口座情報とID,Passwordを預かり、代行でログインして結果のhtmlを解析（スクレイピング）して利用明細や残高を集約するものです。口座とID,Password情報、解析エンジンをどこに置くかで、クライアント型とサーバ型に分類されます。 サーバ型アプリケーション まずサーバ型アプリケーション
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
system-design-primer/README-ja.md at master · donnemartin/system-design-primer