type
status
date
slug
summary
tags
category
icon
password
 

理論

GraphQL API と REST API の違いについて、あなたの理解を整理します。

1. GraphQL API

  • 目的: アプリケーションとバックエンド間のデータやり取りを効率的に行うためのAPIです。
  • 特徴:
    • クエリベース: クライアントは必要なデータを正確に指定できる。例えば、特定のフィールド(例: ユーザー名やメールアドレス)のみを取得できる。
    • 1つのエンドポイントで複数のリソースにアクセスできる。RESTのように複数のURLを使う必要がない。
    • 効率的なデータ取得: クライアントが欲しいデータのみを取得できるため、不要なデータの転送が少なく、ネットワーク負荷が軽減される。

2. REST API

  • 目的: エンドユーザーとアプリケーション間、またはアプリケーションの異なるサービス間でデータやり取りを行うAPIです。
  • 特徴:
    • リソース指向: 各リソース(例: ユーザー、商品)に対して個別のエンドポイント(URL)を設け、HTTPメソッド(GET, POST, PUT, DELETE)で操作を行う。
    • 冗長なデータ転送: クライアントが取得するデータは、通常、固定の形式でレスポンスとして返され、クライアントが必要でないデータまで含まれる場合が多い。
    • 複数のエンドポイント: 各リソースごとにURLが分かれているため、異なるリソースの取得に対して複数のリクエストを送る必要がある場合も。

まとめ:

  • GraphQL APIは主にアプリケーションとバックエンド間で、クライアントが必要なデータを自由に指定し取得するために使われます。
  • REST APIは、エンドユーザーとアプリケーション、またはアプリケーション間で、リソースに対する操作をHTTPメソッドを通じて行うためのものです。
このように、GraphQLはデータの取得や操作において、より柔軟で効率的なやり取りを提供するのに対して、RESTはリソースベースのアーキテクチャを用いています。
 
SQSロングポーリングとは、Amazon SQS (Simple Queue Service) のキューにメッセージが来るまで、ずっと待ってくれる機能です。
通常、SQSは「ポーリング」という方法でメッセージをチェックします。ショートポーリングは、メッセージがない場合にすぐに「何もないよ!」と返事が返ってきます。しかし、ロングポーリングでは、メッセージが来るまで、最大20秒間待ってくれます。そのため、無駄なチェックが減って効率が良く、リソースやコストの節約にもなります。

例を使った説明:

例えば、レストランで注文を受け付けるシステムを考えましょう。注文が来るたびに料理を作るとします。
  • ショートポーリング:シェフは「注文あるかな?」と1秒ごとにチェックして、もし注文がなければ「まだない」と言って休憩します。
  • ロングポーリング:シェフは「注文来るまで待つよ!」と決めて、注文が来るまでずっと待っています。注文が来たら、すぐに料理を始めます。
ロングポーリングを使うことで、シェフ(システム)は無駄に待機して無駄な労力を使わず、効率よく仕事を進められます。
 
DLQとは 注文失敗の保持には、より明確に Dead Letter Queue (DLQ) を使うべきで、SQSロングポーリングを使用して失敗した注文を保持するという方法は直感的ではなく、混乱を招く可能性があります。
AWS AppSyncは、フルマネージドなサービスで、GraphQL APIを作成、管理、運用するためのツールです。GraphQLは、アプリケーションとサーバー間でデータをやり取りするためのクエリ言語で、クライアントが必要なデータだけを取得できるように設計されています。

AWS AppSyncの主な特徴:

  1. リアルタイムデータ更新
      • AWS AppSyncは、リアルタイムのデータ更新機能を提供します。これにより、アプリケーションがサーバーからの変更を即座に受け取って更新することができます。例えば、チャットアプリやライブデータストリーミングなど、リアルタイムでの情報交換が必要なアプリケーションに最適です。
  1. データソースの統合
      • AWS AppSyncは、Amazon DynamoDBAmazon ElasticsearchAWS LambdaAmazon RDS など、さまざまなバックエンドデータソースに接続することができます。これにより、異なるデータストアからデータを集約し、シームレスにクエリを実行することができます。
  1. オフライン機能
      • AWS AppSyncは、モバイルやウェブアプリケーションのオフライン機能をサポートしており、ネットワーク接続が失われても、データの変更や同期が可能です。ネットワークが復旧すると、ローカルで行われた変更を自動的にサーバーと同期します。
  1. セキュリティと認証
      • Amazon CognitoIAMを使って、ユーザー認証とアクセス制御を簡単に設定できます。これにより、特定のユーザーにのみアクセスを許可したり、データのセキュリティを強化できます。

例:

例えば、ECサイトで商品を表示するアプリケーションがあるとしましょう。GraphQLを使うと、クライアントは「価格だけ」「レビューだけ」「在庫数だけ」など、必要な情報だけをリクエストできます。AppSyncを使うと、これらのデータを異なるデータソース(例えばDynamoDBに保存された商品情報)から効率的に取得し、またリアルタイムで価格更新や在庫変動を即座に反映することができます。
AWS AppSyncを使うことで、データの取得が効率的になり、アプリケーションのパフォーマンスとスケーラビリティが向上します。

実践

一問道場

問題 #271

トピック 1
ある企業が、小売注文用のWebアプリケーションを再設計したいと考えています。このアプリケーションは現在、ロードバランサーで負荷分散されたAmazon EC2インスタンスのフリートを使用して、以下の役割を果たしています:
  • Webホスティング
  • データベースAPIサービス
  • ビジネスロジック
企業は、疎結合でスケーラブルなアーキテクチャを構築し、失敗した注文を保持する仕組みを提供しつつ、運用コストを最小限に抑える必要があります。
どのソリューションがこれらの要件を満たすでしょうか?

A.
  • Amazon S3 をWebホスティングに使用
  • Amazon API Gateway をデータベースAPIサービスに使用
  • Amazon Simple Queue Service(Amazon SQS)を注文キューとして使用
  • Amazon Elastic Container Service(Amazon ECS)をビジネスロジックに使用し、失敗した注文の保持にAmazon SQSのロングポーリングを活用
B.
  • AWS Elastic Beanstalk をWebホスティングに使用
  • Amazon API Gateway をデータベースAPIサービスに使用
  • Amazon MQ を注文キューとして使用
  • AWS Step Functions をビジネスロジックに使用し、失敗した注文の保持にAmazon S3 Glacier Deep Archive を活用
C.
  • Amazon S3 をWebホスティングに使用
  • AWS AppSync をデータベースAPIサービスに使用
  • Amazon Simple Queue Service(Amazon SQS)を注文キューとして使用
  • AWS Lambda をビジネスロジックに使用し、失敗した注文の保持にAmazon SQSのデッドレタキューを活用
D.
  • Amazon Lightsail をWebホスティングに使用
  • AWS AppSync をデータベースAPIサービスに使用
  • Amazon Simple Email Service(Amazon SES)を注文キューとして使用
  • Amazon Elastic Kubernetes Service(Amazon EKS)をビジネスロジックに使用し、失敗した注文の保持にAmazon OpenSearch Service を活用

解説

この問題では、ウェブアプリケーションのアーキテクチャをスケーラブルかつデカップルし、注文の失敗を保持しつつ運用コストを最小限に抑える方法を求めています。正解はCです。
Cの選択肢は以下の理由で適切です:
  • Amazon S3をウェブホスティングに使用し、静的なウェブサイトを効率的に提供できます。
  • AWS AppSyncはGraphQL APIを利用して、データベースAPIサービスを効率的に提供します。
  • Amazon SQSを使って注文をキューイングし、非同期処理を可能にします。
  • AWS Lambdaはサーバーレスでビジネスロジックを処理し、失敗した注文を保持するためのSQS dead-letter queueを活用できます。
他の選択肢は、要件に対して適切でない技術スタックや構成を含んでいるため、選択肢Cが最もコスト効率が良く、要求を満たす解決策です。
相关文章
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
EKSでのWordPressデプロイ:KCNA-JP試験対策 (Kubernetes実践編)
Lazy loaded image
初心者向け!コンテナ化WordPressサイト構築ガイド(超詳細版)
Lazy loaded image
EFSを活用!AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
Lazy loaded image
528-AWS SAP AWS 「理論・実践・一問道場」Migration Evaluator
Lazy loaded image
272-AWS SAP AWS 「理論・実践・一問道場」Amazon Aurora Global Database270-AWS SAP AWS 「理論・実践・一問道場」AWS Control Tower
Loading...
みなみ
みなみ
一个普通的干饭人🍚
最新发布
02-生成AIパスポート試験対策:第2章「生成AI」
2025-2-1
01-生成AIパスポート試験対策:第1章「人口知能」
2025-2-1
究極のAWS認定 AI 実践者 AIF-C01 - 学習メモ
2025-1-27
不要再傻傻的直接买NISA啦
2025-1-27
Kubernetes、仮想マシンとコンテナの概念を超簡単に解説!
2025-1-24
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
2025-1-22
公告
🎉欢迎访问我的博客🎉
- 感谢您的支持 --
本站点于2024/09/01建立
👏主要分享IT相关主题👏
系统管理:
Redhat…
容器和编排:
Kubernetes、Openshift…
云计算:
AWS、IBM…
AI入门
以及技术笔记和考证经验
定期更新,欢迎互动。
感谢访问!
快速浏览相关标签