GraphQLはいつ使うか、RESTとの比較
さぼです、沖縄でWebと設計について考えてます。2023/09/23 に沖縄で行われたTechBaseOkinawa2023 にて上記のタイトルで登壇しました。 今回の内容は GraphQLを設計の観点から考えてみる GraphQLの目的や用途を整理する GraphQLを使う時、または使わない時のヒントを持ち帰ってもらう 最近、GraphQLじゃなくてRESTで良くないと思うケースがなんとなくわかってきたのでそれを共有する という感じで話しました。話した内容を文字に起こし少し改修してZennでも共有することとします。 まえおき 最近はクライアントAppとサーバーAppを分けて実装する事が増えてきた クライアントの環境はますます複雑になっている クライアントとサーバーはWebAPIで通信を行う クライアントが複雑になるのと同時にWebAPIの要求が更に増して来ている APIの要求・応答を効率
Redshiftのデータをサービス改善に役立てるデータ転送システム Queuery - クックパッド開発者ブログ
こんにちは、技術部データ基盤グループの佐藤です。この記事では最近業務として主に取り組んでいたDWHから外部へのデータ転送基盤であるQueuery（きゅうり）について、OSSとしてGitHubへの公開しましたのでこの記事でご紹介をします。 github.com Queueryというシステムは2017年の春頃にid:koba789の手により作られ、クックパッドのデータ基盤における重要な立ち位置を担っています。 背景 従来、RedshiftでSELECT文などの取得系クエリを実行するためにはRedshiftに直接接続してクエリを発行していました。この方法ではクエリ結果が巨大な場合にクライアント側のリソースを逼迫させることがありました。 しかし、それを避けるためにカーソルを使おうものなら今度はたちまちRedshiftのリーダーノードの具合が悪くなってしまいます。Redshiftから巨大な結果を得る
React Storybook で変わるUI開発フロー (Redux Flavor) - Qiita
SPAを考える会 (D3勉強会 2016.10.06) by @kitaly (twitter: @kita_ly) 自己紹介 @kitaly Twitter: @kita_ly ソフトウェアエンジニア REST API開発 (Scala/Play) SPA開発 (TypeScript, Angular.js, React.js) ビズリーチ HRMOS プロダクト開発部 採用管理 (2016年6月リリース) 勤怠管理, 評価管理, その他HR系サービス (Coming Soon..) 過去の発表資料 サーバサイドエンジニアが 1年間まじめにSPAやってみた ビズリーチではDBFluteハンズオンやってます はじめに React / Redux / Webpack 前提の話ですが 他のコンポーネント志向FWなどでも、ユースケースやワークフローは応用可能だと思っています 新しいツール
オレの最弱のES6開発環境 - Qiita
ブラウザのES6サポートが急速に良くなってきています。社内ツールとかElectronとか、ブラウザの普及率を気にしなくていい環境ならそろそろ使えるのではないかと思って調べたり試してみたりしています。 更新 https://caniuse.com/#search=es6 http://kangax.github.io/compat-table/es2016plus/ これを見るともうほぼ実装は完了していますね。Node.jsも対応していますし使えるブラウザが限定できるならもはや変換なんかしなくても大丈夫。注意点としては以下の2つ。 IE11は渋い ES6 modulesはまだまだ ソースをES6で書いて、結果もそのままES6という手抜き開発に使えるツールのメモです。手抜きなので、おそらく経年変化の影響はほとんどないはずです。対象としてはブラウザだったり、ElectronでのSPA開発です。
APIデザインにおける七つの大厄介 | POSTD
(編注：2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか（私がしたことを見てください）。 リスティクル（箇条書き形式の記事） を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
State of the Art in Microservices by Adrian Cockcroft - Qiita
概要 2014 年の 12 月アムステルダムで行われた DockerCon のキーノートのひとつ "State of the Art in Microservices" についてのまとめとメモ。 開発スピードをあげるための組織再編 コンテナ化されたマイクロサービスアーキテクチャ Docker が普及したあとの開発スタイル といった内容が盛り込まれている。元のスライドとビデオはこちら スライド ビデオ 内容は Adrian が話していることに加え自分が調べたり学んだ内容を補足やメモとして追加しているので間違った理解をしているなと思ったらぜひ編集リクエストください :) キーノートをまとめることについては Adrian 本人に許可をもらえました！ @adrianco クラウドアーキテクトとして 6 年間 Netflix に勤めていた 現在は Battery Ventures という工業の会社の
APIの後方互換性を保つ工夫 - ワザノバ | wazanova
Stripeの決済サービスの成長は、APIが使いやすいというエンジニアの間での評判がかなり寄与したと記憶しています。 同社のAPIは現在、 エンドポイント: 106 バージョン: 65 APIクライアント: 6 ユーザ企業を煩わせることなく後方互換性をしっかり担保したいという方針を守るための工夫を、Amber Fengが紹介してくれています。 1) ユーザが利用するバージョン情報の把握 ユーザ企業が最初にAPIコールをしたときのバージョン情報をStripe側で保管している。それ以降、ユーザ企業はバージョンのことを意識することなく、最初のバージョンのAPIを利用し続けることができるようにしている。ユーザ企業側でバージョンの変更をしたい場合は、ダッシュボードでの設定や、リクエストヘッダーに情報を付加することで可能。 2) バージョンと機能の整合性 YAMLファイルでバージョンとその振舞いの情報
クライアントアプリの為のREST API設計 - Qiita
エンジニアがアプリ担当とAPI担当で分かれているチームで、API担当のエンジニアがアプリ開発経験が無かったりすると、アプリ担当のエンジニアはどんなAPIがクライアントアプリにとって使いやすいのか、上手く伝えるのに苦労する事がありますよね?本記事はそんな場面でAPI担当のエンジニアに読んでもらう事を想定しています。 APIと型 アプリ側はRESTクライアントにRetrofitやRestkit等、既に広く使われているライブラリを使用する事が多いです。それらのライブラリは、オブジェクト・JSON間の変換機能があり、アプリ側ではJSON等シリアライズされるデータ形式を意識せずに、処理系上のオブジェクトをそのまま扱えます。即ちAPI経由でやり取りされるデータは全て型を持つのです。 例えばAPI側のコードで以下の様に定義されたクラスが
APIドキュメントを実装と乖離させないために - Qiita
内部用APIであるか外部の開発者向けのAPIであるかに関わらず、ドキュメントと実装との乖離は極力避けたいものであるが、注意深く開発を進めない限りこの状況は容易に起こり得る。何が乖離を引き起こし、どうすればこの状況を回避できるのか考えながら、JSON Schemaの利用例を紹介する。なおこの投稿では、HTTP経由でデータの通信を行うような狭義のAPIのことをAPIと呼ぶことにする。 同じ情報源を参照する APIドキュメントと実装が同じ情報源を参照するようにすれば、論理的に関連した要素は統一的に変更され、これらの変更は完全に同期が取れたものになる。つまり、変更時に乖離が生じにくくなる。但し情報の見せ方によって乖離が発生する可能性は十分にだろうし、乖離が発生するのは理解しようとする側の認識の問題であるから、論理的に全く起こり得ないということではない。 この参照の形には、両者が別の情報源を参照する
HerokuのHTTP API設計ガイド
HerokuのAPIチームの一員、Wesley Beary氏がHTTP+JSON API作成のためのガイドラインを要約した形でまとめた。 これは一般的な推奨からはじまっている。 API呼び出しはすべてTLSを使う必要がある。非TLSの呼び出しには403 Forbiddenを返す。 APIには必ずバージョンを付けること。バージョンの指定にはAcceptヘッダを使う。デフォルトバージョンに頼る代わりに、クライアントはAPIバージョンを指定する必要がある。 リソースのキャッシングをサポートするために、ETagヘッダを使うこと。 X-Request-IDの付いたレスポンスを識別すること。これはログやデバッグに役立つ。 大きなレスポンスを扱うために、Range、Content-Range、Next-Rangeを使うこと。 リクエストについて、次のように述べている。 以下のような適切なステータスコード
Squareの内部APIの仕組み - ワザノバ | wazanova
http://corner.squareup.com/2014/09/squares-api.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 SOAにおけるサービス間のコミュニケーションについては、CODE CLIMATEにおいて、Protocol Buffers vs JSONという比較が取り上げられていて、「ブラウザやJavaScriptが直接データを利用しないケース、特に内部サービス間のコミュニケーションにはProtocol Buffersの方が向いているのでは。」と紹介されています。 せっかく整合性のあるデータ構造を用意しても、サービス間のデータのやり取りの際に苦労させられることが多い。Protocol BuffersならProtoフォーマットにしてエンコーディングするだけで、意図す
5分でわかるBatteryHistorianによるAndroidアプリの解析方法 - クックパッド開発者ブログ
モバイルファースト室の@tomorrowkey です。 Google I/O 2014で発表されたProject VoltaのBatteryHistorianについて調べました。 目次 注意 Battery Historianってなに？ BatteryHistorianを使おう 開発中のBatteryHistorianを使おう 各項目の解説 まとめ 参考 注意 この記事は2014年8月12日 現在 正式リリースされていない開発中のツールを解説しています。 正式リリース時にはツールの使い方や解析結果の見かたなどが変わる場合がありますので、ご注意ください。 Battery Historianってなに？ Google I/O 2014でProject Voltaが発表されました。 Project VoltaはAndroidアプリの電力消費の解析をするためのツールを作ったり、アプリの電力消費を抑え
マイクロサービス（microservices）とは何か – recompile.net
マイクロサービス（microservices）という言葉をご存知でしょうか？ 今、エンタープライズ界隈のソフトウェアエンジニアの間でマイクロサービスという言葉がにわかに盛り上がりつつあります。 マイクロサービスはJames Lewis氏によって提案された言葉です。詳細については、彼がMartin Fowler氏と共著で書いた「Microservices」という記事を参照してほしいのですが、ようするにひとつのアプリケーションを、Railsのような一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。 上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組
HATEOASって何だ? - uehaj's blog
Grails 2.3のRest機能のドキュメントを読んでいたら、拡張の一つとして「8.1.7 Hypermedia as the Engine of Application State」というのが書いてあって、調べると面白かったので、この資料(REST: From GET to HATEOAS)を読んだだけでの、私の理解する限りのメモを記しておきます。 一言でいうと、HATEOASとは、Restfulパターンを拡張するアーキテクチャパターンで、Restful原則に対する追加的な制約。どういうものかというと、HTMLアプリの画面遷移を抽象化した、状態遷移を表現するRestful API(=Restful WebアプリのWebインターフェース)を設計するための具体的な方法論になってる。 もちろんGrailsに特化したものではなく、Restと同じレベルのWebアプリケーション一般概念でありRes
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
アプリをiOS 7対応する時に知っておきたいことまとめ - Qiita
＠himara2 です。iOS Advent Calendar の20日目を担当します。 iOS 7対応時に知っておきたい情報をまとめます。 はじめに iOS 7が登場から3ヵ月が過ぎ、普及率が75%を超えるほどiOS 7は浸透しています。 先日にはついにAppleが「2014/2/1以降に申請するアプリはiOS 7に最適化されている必要がある」とアナウンスしました。 これからアプリのiOS 7対応は必須化していきます。 この記事ではこれからiOS 7対応をする方向けに、新APIやiOS 7対応時に助かるリンク集をまとめてみます。 1. 見た目関連のAPI Custom Transition ViewController間の遷移が簡単にカスタマイズできるようになった NavigationController, TabBarController, Modal などの遷移を自作できる UIVi
ようこそ、HTML5裏APIの世界へ - HTML5 Conference 2013
Canvas、WebGL、WebRTC、WebSocketなど、HTML5の花形スターとも言えるモテ系APIは、常に世間の注目を集めている。これらAPIを使いこなせるウェブディベロッパーはどこからも引っ張りだこだろう。しかし、注目度が低いながらも、今後のウェブを支える（かもしれない）最新のAPIが数多く存在する。このようなAPIは派手さが足りないゆえに話題になることもない。しかし、これら非モテ系のAPIも含めてHTML5だ。 本セッションでは、ありきたりのモテ系APIに飽きたマニアな貴方のために、普段は陽の当たらないAPIを一挙紹介する。もちろん、どれかのブラウザーに実装されているAPIのみだ。今から使おうと思えば使えないことはない。そして、W3Cにて仕様策定が始まって日が浅いため、明日にはどうなるか分からない。無くなるかもしれないし、大幅に変更されてしまうかもしれない。今覚えても役に立た
Readabilityの非公開API - Takebayashi.Asia
気になるブログエントリとかを読みやすく整形してくれるみんな大好きReadability。自分のアプリに組み込めるようにAPIも公開されています。が、API Docsの冒頭に次のような一文が。 All requests to the Readability service require access tokens. 認証マストですって。OAuth。わざわざページを読みやすくするためだけにOAuth認証なんてやってられません。現にみんな大好きReederは認証しなくてもReadabilityによる整形が可能じゃないですか！ というわけで、認証せずに使えるReadabilityの非公式なAPIをご紹介します。認証せずにページを整形するには、次のような手順を踏めば良いみたいです。 CSRFトークンを取得 記事IDとセッションIDを取得 整形済みドキュメントを取得 こんな感じですね。ではもう少し詳
PICTORRIA： 最先端の一枚画像認識アルゴリズムをWeb APIでシェアするプラットフォーム | DERiVE コンピュータビジョン ブログ
Tweet 公開後に、まだ実際の運用は始まっていなくてComing Soonの状態が続いているサイトではありますが、以下の「PICTORRIA」という、起業家コンペから生まれたWebプラットフォームを紹介します。 http://www.pictorria.com このサイトは、Deva Ramanan先生のところの学生が起業家コンテストのアイデアとして作ったWebサイトのようで、最先端のCompute Visionによる画像認識アルゴリズムをシェアするためのサイトとなるそうです。（参考：彼らの出身である、カリフォルニア Irvine校による、起業家コンペの報告記事） PICTORIAでは、Deva Ramanan先生のラボの技術である、Deformable Part Modelsによる物体検出やFlexible Mixture of Partsによる人物姿勢推定などの、「パーツベース物体認
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
