「GitHub Marketplace」開店 開発ツールを検索・購入
販売するツールは今後増えていく見込み。自分のツールを販売したい開発者はこちらから申し込める（GitHubアカウントが必要）。一般のアプリストア同様に審査がある。 同社はまた、「Integrations」を「GitHub Apps」と改称し、認証関連を改善したことも発表した（詳細は解説ページ）。 さらに、「GraphQL API」を一般公開した。 関連記事 GitHub Developer Program、無料アカウントでも参加可能に GitHubが、これまで有料アカウントユーザーにのみ提供してきた「GitHub Developer Program」を、無料アカウントユーザーにも提供する。 GitHub、“過去最大の”アップデートでレビュー機能やプロジェクト管理機能を強化 ソースコード共有ツールのGitHubがプラットフォームをアップデートし、レビューやコメント機能の改善、Trelloのよう
GraphQL入門 - 使いたくなるGraphQL - Qiita
本記事は Livesense Advent Calendar 2016 - Qiita の24日目の記事になります。 公開から1年ほどたち、当初はRESTの次の潮流か！？みたいな感じになったものの、イマイチ盛り上がってる気配のないGraphQL。 ただ、気になっていた技術だったので、気にせず2016年が終わる前にざっと調べてみました。 ここ2日ほどでざっと調べたもののまとめなので、理解や解釈に誤りや言ってる意味がわからないところがあればご指摘いただければ幸いです。 TL;DR 内容をコンパクトにしきれず（Queryにばかり集中して、Mutationについては全然触れてないのに！）かなり長くなってしまいました。実際は、 GraphQL | A query language for your API のTOPページを読んで雰囲気を掴み、 The GitHub GraphQL API | Git
RESTの次のパラダイムはGraphQLか - Qiita
のようなクエリをクライアントが発行することになります。 なぜこのようなシステムが必要かの説明の前に、RESTの問題点を挙げてみます。 RESTの問題点 Server Side Renderingの場合 コントローラでEager Loading等のクエリ最適化を意識しないといけない ビューを実装するときも結局裏側でどのようなクエリが発生するかを意識しないといけない Client Side Renderingの場合 コンポーネント毎に必要な情報をリクエストする場合、AJAXリクエストを何度も発行する必要がある 提供されているAPIが不十分だと、クライアント側でテーブル結合が必要となる 共通する問題 クライアント毎にちょっとずつ違うAPIを用意してメンテしないといけない 端末に応じて異なるサイズの画像を返す ネイティブアプリとウェブアプリで異なる結果を返す 等など APIに「暗黙的な契約」が発生
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
