GraphQL実践ノウハウv2 https://speakerdeck.com/sonatard/graphql-knowhow-v2 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql GraphQLの誤解 https://speakerdeck.com/sonatard/rethinking-graphql
GraphQL実践ノウハウv2 https://speakerdeck.com/sonatard/graphql-knowhow-v2 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql GraphQLの誤解 https://speakerdeck.com/sonatard/rethinking-graphql
ソウゾウの Software Engineer をやっています、@mookjp です。 8/10 の記事「メルカリShopsの技術スタックと、その選定理由」では、メルカリ Shops のアーキテクチャについて、その全体像を紹介しました。 この記事では、そのうちの BFF(Backend for Frontend) レイヤとして用意した GraphQL サーバについて、NestJS を使った実装例を交えて紹介します。 GraphQL とは GraphQL サーバ周辺の構成 NestJS とは GraphQL Module NestJS で Code First なスキーマ定義をする Object types の定義 Query と Mutation の定義 GraphQL スキーマの生成 スキーマの Breaking Change (破壊的変更)を防ぐ DataLoader を使って Bat
Distributed systems provide a particular challenge to program. They often require us to have multiple copies of data, which need to keep synchronized. Yet we cannot rely on processing nodes working reliably, and network delays can easily lead to inconsistencies. Despite this, many organizations rely on a range of core distributed software handling data storage, messaging, system management, and co
main.go P xi>V ���i>V package main import ( "context" "flag" "fmt" "log" "net/http" "os" "os/signal" "sync/atomic" "time" ) type key int const ( requestIDKey key = 0 ) var ( listenAddr string healthy int32 ) func main() { flag.StringVar(&listenAddr, "listen-addr", ":5000", "server listen address") flag.Parse() logger := log.New(os.Stdout, "http: ", log.LstdFlags) logger.Println("Server is starting
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド・イベント駆動 コネクションN:スレッド1。epoll/kqueue/select を1つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える: サーバーにメッセージを送信 イベントハンドラを登録;このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す 1コネクション1スレッ
Ruby on RailsでDev環境は使ったことあるけど、test・prod環境を考慮した環境構築をしたことがない人にお勧めの内容です。 サーバー構成図 サーバーの役割 リバースプロキシサーバー(ホスト名:rp01) ロードバランサ機能を使ってWEBサーバ二台に処理を振り分け、アクセスを1台のサーバーに集中させない WEBサーバーを外部から隠せることでセキュリティ面の向上 WEBサーバー(web01、web02) webサーバーを2台用意することでアクセスが1つのサーバーに集中しないため、レスポンスを早くできる マスターDBサーバー(db01m) DB内容をもう1台のDBサーバー(スレーブ)へリアルタイムにコピーし、障害でマスターが停止したときはスレーブに切り替える スレーブDBサーバー(db01s) 読み込み専用のサーバー。書き込みをしない分レスポンスが早くなる マスターの内容を常にコ
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
JVM Operation Casual Talksで出てた話としてJavaでhot deployってどうしてんの?ってのがありました。 hot deployっていうのはアプリケーションコードを変更してもAPサーバーを再起動せずに反映する技術です。 この辺別に僕は全然知らないし答えを持っているわけではないですが、まあちょっと興味があったのでLL言語でのhot deployとJavaでhot deployを簡単に調べたのでメモっときます。 コードを変更してAPサーバーを再起動する場合、APサーバーが止まっているときにアクセスが行くと困るので、ロードバランサから外してAPサーバーを再起動してまた戻すみたいなことをやるのがオーソドックスな方法のようですが、hot deployだとそういったことをやる必要が無くなります。 Server::Starterから学ぶhot deployの仕組み - $s
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止(同じサイト内であっても禁止です) SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可(他のサイトに禁止したい場合は主にこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く