Carpe Diem

備忘録

Backstage でGitHub認証を導入する

概要

Backstageに認証機能を導入します。

Backstageでは様々な認証方法を提供していますが、今回はGitHubを使った認証を実装します。

環境

  • backstage v1.21.1

認証

GitHub Authentication Provider | Backstage Software Catalog and Developer Platform

に沿って導入します。

GitHub Appの作成

GitHub認証を導入するためにGitHub Appを作成します。

  • GitHubが会社のOrgに所属していたらログインできる認可機構を設定したい
  • Software CatalogのUserやGroupにGitHubのMembersを利用したい

といったケースであれば、個人でなくOrganizationで作成してください。

続きを読む

2023年買ってよかったものリスト

概要

年の瀬なので2023年に買ってよかったものを挙げてきます。

SESAMEタッチ & オープンセンサー

2021年買ってよかったものリスト - Carpe Diem

でも紹介したスマートロックで

に対応したデバイスがリリースされました。

【New】SESAMEタッチjp.candyhouse.co

開閉検知のセンサーも合わせることで自動ロックも対応しました。

【New】オープンセンサーjp.candyhouse.co

CEOのプレゼンも面白いので応援してるベンチャーです。

www.youtube.com

続きを読む

Backstage をローカルで動かす

概要

前回紹介したBackstageをローカルで使うための説明です。

開発者ポータル Backstage とは - Carpe Diem

環境

  • backstage v1.21.1
  • yarn v1.22.19

Get Started

とりあえず起動してみる

アプリケーション作成

以下のコマンドでアプリケーションを作成できます。
今回はmy-appという名前で作るとします。

$ npx @backstage/create-app@latest
? Enter a name for the app [required] my-app
続きを読む

VSZ, RSS(anonymous, file)の理解を深める

背景

KubernetesでPodがOOM Killされた際には以下のようなログが発生します。

Memory cgroup out of memory: Kill process 9130 (XXXX) score 1592 or sacrifice child
Killed process 9130 (XXXX) total-vm:423008kB, anon-rss:122484kB, file-rss:33792kB, shmem-rss:0kB

その中でtotal-vmanon-rssfile-rssshmem-rssといった単語が出てくるのでそれぞれの違いを説明していきます。

仮想メモリ

仮想メモリはメインメモリ(RAM)の抽象概念で、プロセスとカーネルにほぼ無限(64bitOSだと約16,000PB)のアドレス空間を提供します。

これにより各プロセスとカーネルは競合を気にすることなく専用のアドレス空間を利用できます。

上図のように仮想メモリはメインメモリ(物理メモリ、RAM)やストレージデバイス(ディスク)へマッピングされます。カーネルはできる限りアクティブなデータをメインメモリの方に残そうとします。

続きを読む

開発者ポータル Backstage とは

背景

開発チームが抱えるよくある課題として

  • システムが変化する一方でドキュメントは更新されず腐る
    • メンバーの流入出によって口伝でかろうじて継承された知見も失われる
  • 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される
    • 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する

といったことが良くあります。
解決方法としては以下のように、GitHub&ルールベースで管理するといった例があります。

future-architect.github.io

また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、

  • 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる
    • CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう
  • チームごとにドキュメントの品質・内容・管理方法が異なり、確認のための余計なコミュニケーションコストがかかる

となり、先程のドキュメント管理の課題と相まって生産性を低下させます。

このような状況で、総合的なソリューションとして生み出されたのがSpotifyのBackstageです。

backstage.io

Spotifyでは数百もの独立したマイクロサービスが存在し、それぞれが異なるチームによって管理されていました。
この複雑さを管理するため、Spotify開発プロセスを標準化し、チーム間の共有と協力を促進する内部ツールとしてBackstageを開発しました。

今回はそのBackstageについて説明します。

続きを読む

二重サブミットを防ぐ方法

背景

支払い処理などで問題になりがちな二重サブミット問題(Double Posting Problem)ですが、主に以下のようなケースで発生します。

  • ボタンのダブルクリック
    • ユーザが間違えて2回ボタンを触ってしまう(ときには遅さにイライラして何度もクリック)
    • リクエスタイムアウトで処理に失敗したように見えて、もう一度押してしまう
  • 完了ページでリロードしてしまう
    • Pull-to-Refreshしてしまう
    • 以前開いていたページをフォアグラウンド復帰時にChromeが勝手にリロードしてしまう
  • 戻るボタンで戻って再度ボタンを押す
  • サービス設計におけるリトライ処理が不適切に行われた

今回はその防止方法について説明します。

対応方法

大まかな方針としてはユニークなトークンを発行してそれをチェックする方法です。

サーバサイドで行う場合

サーバサイドでトークンを発行するパターンです。

シーケンス図

シーケンス図はこちらです。

続きを読む

GraphQLのメリット

背景

GraphQLでよく挙がるメリットとして以下があります。

  • RESTful APIと違って都度UIに依存したAPI設計をする必要がない
    • マルチデバイス対応サービスにおいて大きなメリット
  • オーバーフェッチを避けることができる
    • Switchなどデバイス制約が多いクライアントにとっても適したAPIとなる
  • アンダーフェッチによるAPIコールの増大を防げる

一方であまり触れられない大きなメリットとして

  • ビジネスロジックを集約できる
  • クライアントからのクエリによってバックエンド処理を減らせる

という点があります。今回はこれについて説明します。

環境

  • TypeScript 5.2.2
  • Node.js 20.8.10
  • GraphQL 16.8.1
  • Apollo-Server 4.9.5
  • Prisma 5.5.2
続きを読む