タグ

★goodに関するknj2918のブックマーク (399)

  • アプリ開発の流れを変える「GraphQL」はRESTとどう違うのか比較してみた

    注:単純なデータモデルでさえ、今後の維持や説明が必要になる6つものエンドポイントが含まれています。 あなたがクライアント側の開発者で、movies APIを使い、HTMLとjQueryで単純なWebページを作るとします。そのためには、映画と出演俳優・女優の情報が必要です。APIに必要な機能は揃っているので、データを取得します。 新しくターミナルを開いて以下を実行します。 curl localhost:3000/movies 以下の応答が返ってきます。 [ { "href": "http://localhost:3000/movie/1" }, { "href": "http://localhost:3000/movie/2" }, { "href": "http://localhost:3000/movie/3" }, { "href": "http://localhost:3000/mo

    アプリ開発の流れを変える「GraphQL」はRESTとどう違うのか比較してみた
  • GraphQLはRESTの置き換えではない|こんぴゅ

    GraphQLは最近注目されているWeb APIのための問い合わせ言語だ。 現在主流のRESTfulなAPIはURLとmethodでリソースを表現するわけだが、GraphQLは単一エンドポイント(ex: "POST /graphql")だけ存在し、欲しいリソースをHTTP POSTのbodyに明示的に記載してリクエストする。 ↑JSON APIGraphQLの形式でコールする(引用: how to graphql ) 徐々に実装例が増えてきており、2016年にはGithubAPIの実装を全面的にGraphQLに移行させたのが注目された。 色々調べていくと、GraphQLは単にRESTの代替ではなく、開発・運用フローを一新させうるほど豊かな思想・機能を含む事が分かって来たので現状の整理をしてみたい。 APIリクエストを束ねて効率化RESTではURLがひとつのリソースを表すため、複数のリソ

    GraphQLはRESTの置き換えではない|こんぴゅ
  • yohei-y:weblog: REST 入門(その4) HTTP GET -- その絶大な効果

    » REST 入門 目次 前回は、リソースの特徴について解説しました。 しかし、なぜリソースが重要なのかはまだわからないと思います。 今回はその一部を紹介します。 まず、おさらいしましょう。 僕たちは以下のリソースを例に使っています。 東京の天気予報 2005年8月24日のスケジュール 新花巻駅の写真 Dijkstra 著 "Go To Statement Considered Harmful" 僕の最近のブックマーク そして、それぞれのリソースの識別子(URI)は以下のようになります。 http://weather.yahoo.co.jp/weather/jp/13/4410.html https://example.com/schedule/20050824 http://www.flickr.com/photos/60043209@N00/6337155/ http://www.ac

  • yohei-y:weblog: REST 入門

    語の REST のリソース集を以前作ったのだが、 日語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は

  • Web API初心者と学ぶGraphQL - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DMM.com Advent Calendar 2018 20日目の記事です。 DMM GAMES プラットフォーム開発部 PFシステム部所属の@SiragumoHuinです。 ゲーム自体を作るゲームエンジニアではなく、https://games.dmm.comの各画面やソーシャルアプリケーションプロバイダー(SAP)さんが使うAPIを提供しているWebグループに所属してるサーバサイドエンジニアです。 (記事を書いた当時)日で24歳になりましたが、Webグループでは一番の若造です(新卒2年目) tl;dr; GraphQL自体はフレ

    Web API初心者と学ぶGraphQL - Qiita
  • yohei-y:weblog: REST ってやっぱり難しいかも。

    前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。

  • 今さら聞けない REST とリソース指向 - Mirai Translate TECH BLOG

    概要 こんにちは。プラットフォーム開発部でリードエンジニアをしているchanceです。 私たちのチームでは現在、開発部内向けの API 設計ガイドラインを整備しようとしています。 API 設計において、REST は基中の基です。ガイドラインとしてまとめるからには適当なことは書けませんので、改めて REST の原則から確認しました。新しい技術を追いかけるのはもちろん重要ですが、こういった基技術をしっかりと理解することも同じように重要です。 この記事では、調べた内容のシェアとして、REST の誕生から原則、リソース指向アーキテクチャの概要や特性などを解説します。文字文字しくなってしまいましたが、ご容赦ください。 概要 REST の誕生 REST の原則 原則はいくつあるのか 書籍「RESTful Web Services」 ROA(リソース指向アーキテクチャ)について ROA(リソース

    今さら聞けない REST とリソース指向 - Mirai Translate TECH BLOG
  • 《REST思想》と《リソース指向》と《Webページ》に関する(主にRailsの)話 - Qiita

    これはいわゆるWeb APIについて、ということかなと推測しました。RESTというのはAPIのプロトコルのことだと思われている傾向がありますが、そういうわけではありません。Web全体についてのもので、APIについてもWebアプリについても適用されるものです。 実はRESTでは「統一インターフェイス」の制約からメソッドについて規定されていますが、URLの形については特に規定されません(もちろんAddressabilityの面で重要であることは言うまでもありません)。なので実は/books,/books/1でなくてもいいのですが、これを規約(CoC)でズバッときれいに決めてしまったのがRailsのすごいところの1つです。 の追加や削除を行う場合は、情報をJSON形式でPOSTリクエストのボディとして送ります。application/x-www-form-urlencoded形式で送ることは

    《REST思想》と《リソース指向》と《Webページ》に関する(主にRailsの)話 - Qiita
  • REST理論をわかりやすく。 - Qiita

    ◯ リソースを一意に識別 RESTな考え方では、すべてのリソースはURIで表されるユニークなアドレスを持つ。 ◯ ハイパーメディア(リンクのこと)を仕様 今では結構当たり前。パソコンのOSに保存された設定情報に依存せずにリソースにリクエストすること。つまり、どのパソコンでも同じレスポンスが返ってくるリンクをHTMLとかXMLに含める。 ※ クッキーとセッションを用いたアプリケーションはRESTではない。 クッキーとセッションの仕組み RESTはあくまで、固有のHTTPメッセージ(リクエスト/レスポンス)に対して、固有の表現を表示する。つまり、クライアント側はサーバーからのレスポンスをただ一意に読みこめば良い。逆にサーバー側もただ、クライアント側のリクエストを一意に返せば良い。しかし、クッキーとセッションの仕組みは、クライアント側(ブラウザ)にアクセスするためのクッキーを一時的に保存させてあ

    REST理論をわかりやすく。 - Qiita
  • Row Data Gateway

    Row Data Gateway An object that acts as a gateway to a single record in a data source. There is one instance per row. Embedding database access code in in-memory objects can leave you with a few disadvantages. For a start, if your in-memory objects have business logic of their own, adding the database manipulation code increases complexity. Testing is awkward too since, if your in-memory objects a

    Row Data Gateway
  • Table Data Gateway

    Table Data Gateway An object that acts as a gateway to a database table. One instance handles all the rows in the table. Mixing SQL in application logic can cause several problems. Many developers aren't comfortable with SQL, and many who are comfortable may not write it well. Database administrators need to be able to find SQL easily so they can figure out how to tune and evolve the database. A T

    Table Data Gateway
  • クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)

    すでに何人かの人がクリーンアーキテクチャなんてないよ、って話はしていてイマサラだと思うんですが。 あえてブログの記事に残そうかなと思って書いてみます。 最近、改めてクリーンアーキテクチャを読んだり、原文を読んだり、 ここ数ヶ月ツイート色々な人のを観測したり社内で話したりしていて 考えがまとまってきたので、自分の言葉で整理してみたくなった。 「へー、クリーンアーキテクチャっていうソフトウェアアーキテクチャがあるんだー」という微妙な誤解?をちょっとでも減らす一助になればという感じです。あと、の読み進め方のヒントにもなるかも 先に結論 クリーンアーキテクチャというのはアンクルボブの書いた。 ソフトウェアアーキテクチャのことではない。 the クリーンアーキテクチャというブログ記事はただのソフトウェアアーキテクチャの例(そしての一部分)だが、独り歩きしている クリーンアーキテクチャというソ

    クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)
  • AWS CLIでの多要素認証を簡単にできるWindowsバッチを作ってみた - Qiita

    はじめに 弊社ではAWSアカウントを利用する際にまず多要素認証(MFA)が設定されることが必須条件であり、MFAなしでは、ごく一部のAPIを除きほとんどの操作(コンソール画面とCLI両方を含む)を実行できないようにするためのIAMポリシーが各IAMユーザーにアタッチされます。となると、操作を行う前にまずMFA認証を通す必要があり、コンソール画面でのMFA認証はそこまで不便ではないが、CLIでの手順が少々手間が掛かります。ざっくり言うと: STS:GetSessionToken APIで一時認証情報を取得 取得した一時認証情報を環境変数に入れる(Linuxの場合は export 、Windowsの場合は set) せいぜい1分程度の手順ではありますが、こんなルーチンワークを少しでも減らしたいのがエンジニアという生き物です。なので今回この手順を5秒に短縮できるツールを作ってみました。(開発環境

    AWS CLIでの多要素認証を簡単にできるWindowsバッチを作ってみた - Qiita
  • 0063 号 巻頭言

    DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ

  • 数年間継続している「作業メモ」の話

    メモを残す習慣 以前、@gorou_178さんが「1日1ファイル、「調べたこと」「やったこと」を日報として残す」という記事を公開していた。 この記事の中に以下のようなくだりがある。 そこでふと思い出したのが元同僚のメモの取り方。 毎日1ファイル作成して、そのファイルにその日にやったこと(事細かくやった作業、実行したコマンドなども)をメモしていた。メモは年単位で残っておりとても驚いたことを覚えている。 この、「元同僚」というのはきっと私のことである。 私はメモを取ることが結構と好きな方で、メモを残すことがわりと習慣化している。 例を挙げると、普段からこういったことをやっている。 Google Keepに「Podcastに出演してほしいゲスト候補」、「勉強会・カンファレンスの登壇履歴」、「来月購入予定の日用品・雑貨」、「自宅周辺の行ったことないラーメン屋」、「読みたい・気になったマンガ」とい

    数年間継続している「作業メモ」の話
  • 地方公共団体基幹業務システムはアプリケーション分離の夢を見るか?|共闘プラットフォームマガジン

    記事は総務省・デジタル庁が進める地方公共団体の基幹業務システムの統一・標準化(総務省では「自治体情報システムの標準化・共通化」と記載している)におけるシステムの実装方式の1つである共同利用方式:アプリケーション分離について記載します。 なお「地方公共団体の基幹業務システムの統一・標準化」「ガバメントクラウド」「共同利用方式」そのものの説明は割愛します。Google is your friend. アプリケーション分離とはデジタル庁は共同利用の実現方法として3つの分離モデル(アカウント分離/ネットワーク分離/アプリケーション分離)を示しています。AWSを例にすると以下のようになります。 アカウント分離:自治体ごとにAWSアカウントを別のものにし、それぞれに業務システムを構築する方式。監視、運用管理用のサーバーは共用アカウント上に構築する。 ネットワーク分離:1つのアカウント内の別VPCに自

    地方公共団体基幹業務システムはアプリケーション分離の夢を見るか?|共闘プラットフォームマガジン
  • 祖母が就寝するとDBインサートができなくなる - Qiita

    世の中には、一見関係なさそうな物理現象がITシステムに不可思議な影響を及ぼすことがあります 例えば,500マイル以上離れた場所にメールが送れないという話だったり 中国人のAさんがお茶を入れると会社のネットが繋がらなくなる という話があります。 私の場合は、祖母が就寝するとDBインサートが失敗する、という状況でした 実家の見守りシステム 問題が起きているのは、離れた実家にいる一人暮らしの祖母の状態を見守るために作成した自作のシステムです。 気温や湿度、CO2濃度、明るさ、部屋のドアの開閉、冷蔵庫の開閉の状況をモニタリングできるようにしています。 Raspberry Piに各種センサが接続され、定期的にInfluxDBに送信し、Grafanaという可視化ツールでいつでも見られるようにしています。 これらの情報を見ることで、祖母の家の部屋の温度が適切か、活動しているか、部屋にいるかなどが分かりま

    祖母が就寝するとDBインサートができなくなる - Qiita
  • シェアード・ナッシング・アーキテクチャ - Wikipedia

    シェアード・ナッシング・アーキテクチャ(英語: shared nothing architecture、SN)とは、分散コンピューティングにおいて、各ノード(コンピュータ)がネットワークを除いてリソースを共有しておらず、それぞれが独立しており、自律的であり、システムにおいて単一競合箇所が無い物を指す。 シェアード・ナッシング・モデルは通常は、大規模な状態(state)データを中央に集中的に格納するシステムと対比されるが、これはデータベースやアプリケーションサーバなど、その他の単一競合箇所のいずれについても適用される。 例えばDBMSの場合は、Oracle Databaseはシェアード・ディスク・モデル(DISK共有モデル)であり、DB2の分散系におけるPE、EEE、DPFなどはシェアード・ナッシング・モデルである。 シェアード・ナッシング・モデルは現在では、Webのシステムにおいて頻繁に議

    knj2918
    knj2918 2024/01/07
    “多数の独立したウェブノードと単一の共有データベース((クラスタ化されていてもいなくても)を持つウェブアプリケーションを、シェアード・ナッシング・モデルと呼ぶべきかについては議論の余地がある。”
  • AWS認定全冠するまでのおすすめの順番

    「JAWS-UG東京リブート企画!ランチタイムLT会」での発表資料です https://jawsug.connpass.com/event/289824/

    AWS認定全冠するまでのおすすめの順番
  • データベース レプリケーションの分類(物理 or 論理) | コーソルDatabaseエンジニアのBlog

    Oracle ACE Proの渡部です。 データベースのレプリケーション技術は、物理レプリケーションと論理レプリケーションに大別されます。 物理レプリケーションと論理レプリケーション データベースのレプリケーション技術は、物理レプリケーションと論理レプリケーションに大別されます。 いずれも「差分」のみを同期しますが、伝搬時に「物理的な差分」を用いるか、「論理的な差分」を用いるか、が異なります。 物理レプリケーションは、データベース全体に対する物理的な変更であるところの、 (厳密にはフィジカルロギングでの)トランザクションログを伝搬することで、 複数のデータベースを同期します。レプリケーション元のデータベース(プライマリDB)と レプリケーション先のデータベース(スタンバイDB)の物理的な構造が同じになります。 すなわち、プライマリDBとスタンバイDBは(注目している時点においては)同一とな