FirestoreからRDBへの移行を支える技術 - Qiita
ビットキーではこれまでメインのDBとしてFirestoreを使ってきましたが、現在RDBへの移行を進めています。 移行の理由としては、主にビジネス上のドメインが広がり、Firestoreにおける検索性能の弱さがネックになってきたことが挙げられます。 これまで検索性を補完するためにElasticsearchやAlgolia、検索用途のRDBなどを併用してきましたが、メインDBをRDBとすることで基本はサブのDBなしに運用できるようにしていきたいと考えています。 今回はオフィス領域のプロダクトである workhub において移行を進める際に、どのように実装したのかについて紹介します。 方針 今のところ、Pubsub等の非同期は使わずに同期的にRDBへデータを同期しています。 これは書き込み直後の整合性を重視するためです。 移行の単位は基本（一部の仕様整理まで踏み込んだもの以外）はコレクション単
【2023年版】分散GraphQLの動向~Fusionを中心に~ - Qiita
はじめに GraphQLConf 2023が2023/9/19-21で開催されていました。 そこで個人的に特に気になったのがOpen FederationやFusionといったGatewayの仕様周りの話題です。 これら2つは何が異なるのか、Apollo Federationと何が異なるのか、それらを実装したサーバにはどんなものがあるのか、等いくつか気になることがあったので、講演と自身で調べた内容を併せて紹介したいと思います。 ちなみにGraphQLConfはアーカイブをYoutubeで公開しているので興味ある方はぜひ。 想定読者 GraphQL Gatewayの歴史を知りたい方 GraphQL Gatewayについての知見を深めたい方 Open FederationとFusionの違いを知りたい方 GatewayとしてのGraphQLの歴史 元々はFaceBookでは以下のようなモノリシ
AWS AppSync がアツい！ RDS Data API を使って GraphQL API を爆速で作ってみた - Qiita
CREATE TABLE conversations ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE messages ( id UUID PRIMARY KEY, conversation_id INT NOT NULL, sub UUID NOT NULL, body TEXT NOT NULL, created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (conversation_id) REFERENCES conversations(id) ); CREATE TABLE con
Next.js + SupabaseでGraphQLを利用する方法 - Qiita
SupabaseではSQLだけでなく、GraphQLを利用したデータ取得も行うことができます。 今回はGraphQLでデータを取得して、添付画像のような集計アプリを作ってみます。 Supabaseの準備 ①：Supabaseプロジェクトの作成 Supabaseにログイン（登録していないければアカウント登録から）して、 トップページの「New Project」を押します。 すると、下記の様な画面が表示されます。 適当なプロジェクト名とデータベースのパスワードを入れて新しいプロジェクトを作成しましょう。 ※Regionはできれば自分の住んでいる地域の近くがいいです。私は日本にしました。 ②：Supabaseのテーブル作成 今回集計アプリを作成するにあたってユーザ情報のテーブルと売買情報のテーブルを準備します。 まずはユーザ情報のテーブルを作成します。 SupabaseのダッシュボードからTab
Hasuraを使って環境構築してガンガン工数削減 - Qiita
ある機会がありHasuraというものを知りました Prismaチームが開発したPlaygroudは使用した経験があるので、Hasuraとどんな違いがあるのか調べてみたらPlaygroudより使いやすく開発工数をガンガン削減出来るなと感じました！ なので、もしこの記事を読んでHasuraのことを知ってもらえればと幸いです Hasuraについて 簡単に言うとGraphQLサーバーになります Hasuraはテーブルを追跡することでCRUDや集計用Queryなどを自動的に用意してくれる優れものです また、他の自前で用意したGraphQLサーバーとHasuraを統合してリクエストをHasura一つにお任せすることも可能です 単純なCRUDや集計はHasuraに任せて、ビジネスロジックを含むような処理は自前で用意したGraphQLサーバーに任せることで工数の削減に繋げられるかと思います Hasuraに
現状のSwaggerスキーマとシリアライザの改善を行なった話 - Qiita
はじめに Railsで運用されているAPIサーバーのシリアライザとSwaggerスキーマをリファクタリングした話と、そこで当たった問題(余談)の紹介です。 現状の状態 社内のサービスはAPIサーバーとしてRailsを用いて運用されているのですが、長く運用されているため、手動で作成されるSwaggerスキーマとそれに対応したシリアライザが無秩序な状態にあり、新規APIの実装や修正が入るたびに各人の裁量でスキーマおよびシリアライザを使用・作成していて、運用しづらくなっていました。また、ActiveModel::Serializerなどは使っていなく、独自で実装を行なっています。 実際にどのような構成になっていたかの例を大雑把に。 例 例えば、以下のようなモデルがあったとして class Member < ActiveRecord::Migration def change create_tab
CDKのAPIGateway+Lambda構成をOpenAPIの定義から作成する - Qiita
どんな内容か CDKにてAPIGateway+Lambdaの構成を作る際に、RestApiではなくOpenAPI定義からAPIGatewayを作ることができるSpecRestApiを使ってみたという内容になります。 OpenAPIとは OpenAPIとは、RESTful APIを記述するための標準化されたフォーマットのことで、OpenAPI Specification(OAS)やOpenAPI Generatorなど取り巻く技術の総称としても呼ばれています。 もともとswaggerとして有名だったのですが、OASとして標準化されてからはOpenAPIと呼ばれることが多く、swaggerはOpenAPIのツール的な位置付けになっています。 例えば、https://jsonplaceholder.typicode.com/ というRESTfulAPIを公開しているサービスがあるのですが、その中
デフォルトのエンドポイントの有効無効をAWS CFnテンプレートとOpenAPIで指定する - Qiita
AWS CloudFormation と OpenAPI を使用して Amazon API Gateway を構築する時、「デフォルトのエンドポイント」を無効にする方法がわかりづらかったので、ノウハウを残します。 AWS SAM の AWS::Serverless::API リソースには、デフォルトのエンドポイントの有効と無効を切り替える DisableExecuteApiEndpoint プロパティがあります。 しかし、AWS CloudFormation テンプレートで OpenAPI を DefinitionUri 使用して設定している場合（調査中）、DisableExecuteApiEndpoint プロパティが効きません。 従って、AWS の OpenAPI 拡張を使用し、AWS CloudFormation テンプレートではなく、OpenAPI 内に設定を定義する必要があります
OpenAPI × AWS CDK × APIGateway でRest APIを管理する
OpenAPI定義からAPIGatewayをいい感じに作成できたので、伝えたかった記録になっています。 どんな流れで 「OpenAPI ×CDK」 に辿り着いたのか、つらつら書いています。 長い記事になっていますが、本当に伝えたいのは最後のCDKの話だけです！ 時間が勿体ない方は最後の方だけ読んでいただけたらと思います。 【想定している層】 APIGateway そこそこ分かる CDK 聞いたことある OpenAPI(Swagger) 聞いたことない 【私のレベル】 APIGateway 2年くらい使っているけど未だにCorsエラーとかで沼る。 CDK 1ヶ月前くらいから触り始めたけど、既に好き。CloudFormationに戻れない。 OpenAPI 『スキーマ駆動開発』、とかの記事をみて気になっていて、最近初めて実際に触った。 OpenAPIとは？ 「Restful APIの定義を記述
APIGatewayを作成するときにOpenAPIから型情報を読み込み補完がきくようにしたメモ - Qiita
概要 API Gatewayの設定にOpenAPIを連携できないか検討した。 OpenAPIのJSONから型情報を読み込む形で実装してみたメモを残す。 検討 cdk - openapi-definitionを読むと、定義はすべてOpenAPIのほうに書く必要があるもよう。また、OpenAPIは3.1は使えず3.0か2.0を使う必要がある。 すべてのリソースとメソッドは OpenAPI 仕様ファイルの一部として定義する必要があり、CDK を介して追加することはできません。これは、これらのプロパティの重複や潜在的な混乱を防ぐためです。 こちらの記事で「OpenAPI定義にAWS用の設定値を記載するのが嫌だ」と言っているように、OpenAPIとAWSの設定は分けて管理したい。 記事中ではopenapixを使用しているが、1年更新がないのが不安。 型定義をOpenAPIから取り込む方法を考える。
OpenAPIを元にしたPostmanコレクションの作成・更新を自動化する方法 - Qiita
はじめに これは、REST APIの仕様書としてOpenAPI Specification（以下、OAS）を管理していて、そのOASを元にPostmanコレクションを作成・更新したい思っている人向けの記事です。 PostmanはGUIベースのアプリケーションであり、このGUIからOASをインポートして新規のコレクションを作成できます。作成後は、GUIを介してコレクションを直接更新ができます。しかし、この手動でのGUIを通したコレクションの作成・更新だけでなく、自動化したいニーズもあるかと思います。たとえば、GitHubなどのコード管理システムでOASファイルを管理しているシナリオでは、以下のような手順でのコレクションの作成・更新が考えられます： コード管理システム（GitHubなど）で管理しているOASファイルを更新する OASファイルの更新をトリガーにCI/CDワークフロー（GitHub
AWS SDK Rubyでスタブを行う - Qiita
はじめに AWS SDKを使用したコードに対してテストを記述したい場合、AWSのSDKで用意されているClientStubsを使用して、スタブを行うことが可能です。 ドキュメント自体は公式が出しているものがありますが、この例だけではやりたいこと（Aws::S3::Client以外のインスタンスを使うケース）が実現できなかったので、今回調べたことについてまとめました。 環境 Ruby: 2.7.1 aws-sdk: 3.1.0 aws-s3-sdk: 1.114.0 公式ドキュメントから このドキュメントにあるようにAws::ClientStubsというモジュールが、各サービスに対応したClientクラスにincludeされています。 今回はS3を使って、その例を紹介します。 このモジュールに定義されているのはapi_requests, stub_data,stub_responsesの３つ
Dynamo DB ベースのアプリケーションをmotoとfactory_boyを用いてユニットテストする - Qiita
boto3 は AWS SDK の Python パッケージで、Dynamo DB などの AWS のサービスを呼び出すのに使います。 この boto3 には moto という mock パッケージがあります。 moto を使うと、テストを実行するとき Dynamo DB のスタブにテスト用のデータ(fixtures)を 返させることができるので、テーブルが存在していなくてもテストケースを通すことができます。 本稿では、moto を使って Dynamo DB に依存せずにアプリケーションをテストする方法を紹介します。 さらに、factory_boy を使って fixtures の組み立てを共通化する方法も紹介します。 factory_boy は fixtures の組み立てを担う Factory クラスを備えたパッケージです。 なお、本稿ではアプリケーションとして Flaskベースの AP
mysql の CHECKSUM TABLE が 自動テストのDBロールバックする時に便利だった - Qiita
はじめに 去年は、言語バージョンアップにおけるE2Eテストの考え方とアプローチ方法についてを書きました。 今回は、「DBの差分とロールバック」 に関して書きたいと思います。 DB Diff を実際に使ってみた結果 前回の記事では、「DB Diff」というツールを使うことで、比較とロールバックを自動で行うことができると書いていました。 ★E2Eで検証するデータ種類によって比較方法 新規登録で同じデータが登録される。 → 「どのテーブルに変更が加わったのか？」は DBデータファイルの更新日時等から自動取得させる。 → 登録されたDBデータの差分の比較。( DB Diff ) → 比較後にテスト実行前の状態に戻す( DB Diff ) とある問題が発生し、本格的な導入を断念することにしました。 レコードが多いテーブルの比較を行う場合に時間がかかり、テスト実行後のデータロールバックに時間がかかりす
moto によって requests が意図せずモック化されてしまう問題を回避する - Qiita
moto は、AWS SDK の mocking パッケージです。 moto を用いたユニットテストについては以前 エントリを書きました。 このなかで触れましたが、requests パッケージが意図せずモック化されてしまう問題があります。 この問題の回避策について自分なりのアプローチをまとめておきます 問題としては、moto でスタブをアクティブにすると その後の requests パッケージによるリクエストがすべてモック化されてしまうというものです: これにより、elasticsearch-py など requests に依存したパッケージにおいてHTTPリクエストのさいにエラーが起きることがあります。 回避策 回避策としては、moto の responses_mock にパススルーする URL を登録します:
S3などのデータストアへのアクセス機能をモックとすることでデータストアなしでユニットテストする手法( Java, Mockito ) - Qiita
S3などのデータストアへのアクセス機能をモックとすることでデータストアなしでユニットテストする手法( Java, Mockito )S3unittestMockitoaws-sdkMock 概要 データストアにアクセスすることなくテストを可能とするポイントを紹介します。 データストア( 今回はS3 )にアクセスするオブジェクトを、外部からテスト対象クラスに注入可能としておく テスト時は、データストアにアクセスしないモックを注入する 動作確認可能なソースコードは loftkun/spring-boot-s3-mock-example にあります。 テスト対象クラス テスト対象のクラスです。S3にアクセスするclientを外部から注入できるようにしています。 ( この例ではコンストラクタで受け取っています。 ) このようにデータストアにアクセスするオブジェクトを、外部からテスト対象クラスに注入
サービステストをLambda+unittest用ライブラリで実装してみる - Qiita
AWS LambdaとServerless Advent Calendar 2020 3日目の記事です。 あるサービスのテスト(外部サービスとの結合テスト)を、Lambda(python)+unittestで実装してみます。 やること 「特定の条件を満たすメールを受信した場合はBacklogに課題を起票する」というサービスをテストするエンジンをLambda+unittestで構築します。 unittestライブラリをunittestよりも上のレイヤーの試験に使います。案外使い心地がいいです。 テスト対象サービス 以下の条件を満たすメールを受信した場合に、Backlogに課題を起票します メールタイトルに特定の文字列を含む 送信元が許可された特定のメールアドレス テストエンジン Lambda(python)にunittestライブラリでテストシナリオを記述し実行 各テストケースは、概ね以下の
pythonでS3をモック化できるStubberを使って単体テスト - Qiita
記事について pythonでS3をモック化する際に、以前はpython標準のMockを使っていたけど、boto3に標準のStubberという便利なモジュールが用意されているので、使用してみた。 なお、コードは、実際に動かしたものを公開用に修正したもので、動作確認はしておりません。ご了承ください。 環境 python３系 boto3 テストコードを書いてみる S3からオブジェクトをGETする 対象コード import boto3 func_get(): s3 = boto3.resource('s3') bucket = 'bucket' key = '/key/object.json' obj = s3.Object(bucket, key) res = obj.get() return res from botocore.stub import Stubber from botocore
simulatorを使ったCloudFunctionsのunit testを安定化・爆速化させる - Qiita
こんにちは。virapture株式会社のもぐめっとです。 みんなで集合写真をとったのですが、何故か僕だけぶれてました。何歳になっても落ち着かないみたいです。 今日もfirebase大好きっ子が、firebase大好きっ子向けにfirebaseの情報を提供していこうと思います。 これはFirebase Advent Calendar 202123日目の記事です。 概要 本日はcloud functionsでunit testを書く際の方法として、Cloud Functionsのemulatorを使わないという選択肢とその利点と留意点について紹介します。 目標 cloud functionsのunit testを爆速にして荒ぶるCIを安定させます。 ただし、あくまで今回紹介するのは方法の一つです。 後述するデメリットはあるので必要に応じて取捨選択をしてください。 なぜCloud Functio
Snowflake x Terraformに自動テストを導入した話 - Qiita
はじめに こんにちは。ARISEでデータ基盤構築業務を主に行う「データアーキテクト」というキャリアトラックに所属しているエンジニアの田畑です。先日当社のテックブログの記事でも触れましたが、現在私はSnowflakeでの大規模データ基盤構築に携わっています。 そのプロジェクトにおいて、データ基盤のインフラ面における品質担保の負担軽減を図るべく、自動テストを導入しました。今回はその経緯や実装概要、今後の展望を共有したいと思います。 前提 SnowflakeはPRD, STG, DEVの3面構成(アカウントレベルで分離) Snowflakeのオブジェクトは基本Terraformで管理 TerraformコードのリポジトリはGitHubで管理 リポジトリはGit-flowで開発 各環境に対応するブランチに対してPR作成をするとterraform plan, マージをするとterraform app
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
