SSPI는 모형이 없어요.

26315 단어 APIsssapiidea
며칠 전에 SSSAPI기사[1]를 봤는데 재미있어서 스크랩하면서 시도해 봤어요.
위의 스크랩이 좀 길어서 이 문장에서 나는 특징이 있는 부분을 고를 것이다.
또'무모델'이라는 단어는 기세로만 쓰이고 이런 기술 용어는 없다(없지?).이 점이 차분하고 시원시원한 마음으로 방송됐으면 좋겠습니다.
추기: SSSAPI 운영자로부터 보완을 받아 알 수 없는 부분에 반영했습니다.

SSPI에는 추가 역할 영역이 필요하지 않습니다(spreadsheets.*)


물론 로그인 연결 등이 필요하지만 이러한 서비스에서는 기본적으로 "Google 스프레드시트의 모든 스프레드시트에 대한 참조, 편집, 제작, 삭제"등이 필요하지 않습니다.
Google ドライブへのアクセス許可を求めるスクリーンショットに✖印をつけている状態 그림 1-1의 모든 스프레드시트에 대한 권한을 요청하지 않음
그렇다면 파일에 대한 접근은 어떻게 되는가?'SSSAPI의 시스템 계정과 전자 표 공유'를 통해 해결된다(그림1-2).
スプレッドシートの共有設定画面でSSSAPI のシステムアカウントを追加しているスクリーンショット 그림1-2 공유 설정에 SSSAPI 시스템 계정 추가
각 스프레드시트 설정도 번거롭지만 폴더를 공유할 수도 있습니다.모든 스프레드시트에 대해 일괄적으로 허용되는 것보다 부분적으로 설정하고 해제할 수 있어 안심이 된다.

SSPI는 전체 상태입니다.


"Google 스프레드시트 API화"문서를 보았을 때, 데이터가 요청될 때마다 스프레드시트 (무상태) 를 읽는 서버 피드백 기능 (그림 2-1) 을 상상했다.
graph LR
myapp[[MyApp]] -->|fetch| sssapi[[SSSAPI]]
sssapi -->|fetch| sheet[(SpreadSheet)]

図 2-1 サーバーレスファンクション的なフロー

実際の挙動としては API を(手動または自動更新で)ビルドすると「その時点のスプレッドシートを読み込み API のステートにする」という構成でした(図 2-2、図 2-3)[2]

SSSAPI のコンソールで API の情報を表示しているスクリーンショット図 2-2 コンソールから「Update」ボタンで API をビルド

sequenceDiagram
  participant MyApp
  participant SSSAPI
  participant SpreadSheet
  note right of SSSAPI: Update API
  SSSAPI ->> SpreadSheet: fetch
  SpreadSheet ->> SSSAPI: [{"id":1, "item": "data1"}]
  note right of MyApp: Call API
  MyApp ->> SSSAPI: fetch
  SSSAPI ->> MyApp: [{"id":1, "item": "data1"}]
  MyApp ->> SSSAPI: fetch
  SSSAPI ->> MyApp: [{"id":1, "item": "data1"}]
  note right of SSSAPI: Update API
  SSSAPI ->> SpreadSheet: fetch
  SpreadSheet ->> SSSAPI: [{"id":1, "item": "DATA2"}]
  note right of MyApp: Call API
  MyApp ->> SSSAPI: fetch
  SSSAPI ->> MyApp: [{"id":1, "item": "DATA2"}]

図 2-3 ステートの遷移状態(手動)

自動更新にする場合はコンソールから API Option を変更します(図 2-4)。これでスプレッドシートを更新すると SSSAPI 側に通知が届きビルドされるようになります(図 2-5)。

なお、スプレッドシートを連続して更新すると API ビルド開始まで待つことがありますが、これは Google Drive API の変更検知機能の仕様によるそうです(改善も検討されているそうです)。

SSSAPI のコンソールで API の自動更新を ON にしているスクリーンショット図 2-4 設定により自動更新も可能

sequenceDiagram
  participant MyApp
  participant SSSAPI
  participant SpreadSheet
  note left of SpreadSheet: Edit Sheet
  SpreadSheet ->> SSSAPI: nofity
  SSSAPI ->> SpreadSheet: fetch
  SpreadSheet ->> SSSAPI: [{"id":1, "item": "data3"}]
  note right of MyApp: Call API
  MyApp ->> SSSAPI: fetch
  SSSAPI ->> MyApp: [{"id":1, "item": "data3"}]
  MyApp ->> SSSAPI: fetch
  SSSAPI ->> MyApp: [{"id":1, "item": "data3"}]
  note left of SpreadSheet: Edit Sheet
  SpreadSheet ->> SSSAPI: nofity
  SSSAPI ->> SpreadSheet: fetch
  SpreadSheet ->> SSSAPI: [{"id":1, "item": "DATA4"}]
  note right of MyApp: Call API
  MyApp ->> SSSAPI: fetch
  SSSAPI ->> MyApp: [{"id":1, "item": "DATA4"}]

図 2-5 ステートの遷移状態(自動)

この構成はデータ要求時に毎回スプレッドシートを読みにいく場合と比べてパフォーマンスや耐障害性では有利だと予想できます。また、現状ではスプレッドシート更新後に他サービスの処理を起動させにくいのですが、Webhbook 機能によるビルド状態の通知や GitHub Actions などとの連携も予定されているそうです。

そして、API を任意のタイミングでビルドできるのは「完了タイミングが読めない複数の更新を 1 つのレスポンスにしたい(いわゆるファンイン的なフロー)」の場合などに使い勝手が良いと思われます[3]

複数の担当者が入力するフォーマットですべての項目が入力されているスプレッドシートのスクリーンショット図 2-6 複数の担当者が毎日入力するシート

[
  {
    "担当者": "田中",
    "入力時刻": "2022-01-13 10:00",
    "状況": "異常無し"
  },
  {
    "担当者": "佐藤",
    "入力時刻": "2022-01-13 11:00",
    "状況": "設備 A にノイズ"
  },
  {
    "担当者": "林",
    "入力時刻": "2022-01-13 15:00",
    "状況": "異常無し"
  }
]
▲ 그림 2-7 API 응답
スプレッドシートに未入力の項目があるスクリーンショット 그림 2-8에서 새로 입력을 시작합니다(입력 도중에 API가 업데이트를 기다리고 있음).
[
  {
    "担当者": "田中",
    "入力時刻": "2022-01-13 10:00",
    "状況": "異常無し"
  },
  {
    "担当者": "佐藤",
    "入力時刻": "2022-01-13 11:00",
    "状況": "設備 A にノイズ"
  },
  {
    "担当者": "林",
    "入力時刻": "2022-01-13 15:00",
    "状況": "異常無し"
  }
]
▲ 그림 2-9 API 응답 전날 상태 유지
スプレッドシートの全ての項目が入力されているスクリーンショット 그림 2-10 입력 완료, API 업데이트
[
  {
    "担当者": "田中",
    "入力時刻": "2022-01-14 10:30",
    "状況": "異常無し"
  },
  {
    "担当者": "佐藤",
    "入力時刻": "2022-01-14 13:00",
    "状況": "異常無し"
  },
  {
    "担当者": "林",
    "入力時刻": "2022-01-14 11:00",
    "状況": "異常無し"
  }
]
▲ 그림 2-11 API 응답 전환
또한 Build Log에는 이전 상태(API의 응답)가 있으므로 히스토리를 확인할 수 있습니다(그림 2-12, 그림 2-13).
API에도 쿼리 매개 변수를 통해 기록을 지정하는 획득 기능이 추가돼 이를 실현하면'위에서 매일 입력한 워크시트(그림 2-8)의 역사'등에 적용할 수 있다고 한다.
Build Log で複数の項目が表示されているスクリーンショット 그림2-12에 구축된 로그를 확인할 수 있습니다
Build Log から以前の API のステートを表示しているスクリーンショット 디스플레이 그림 2-13 상태

SSPI는 모형이 없어요.


다양한 Headless CMS를 시도할 때에는 모든 서비스가 모델을 먼저 정의해야 합니다.
부호 없는 도구로도 정의할 수 있지만'모델을 정의하는 데 난이도가 높다'는 이유로 처음에는 난이도를 높이는 주요 원인이라고 생각했다.
또'관리화면 구성은 어떻게든 모형의 정의에 끌린다'는 부분이 많았고,'편집용 관리화면을 제작하는 관리화면이 있었으면 좋겠다'[4]고 덧붙였다.
이런 가운데 SSPI 활용 사례의 캡처(그림 3-1)를 봤을 때'의도를 한눈에 파악할 수 있다'는 설득력이 있어 약간의 충격을 받았다.
スプレッドシートでコンテンツを入力する記事のスクリーンショット 참조 그림 3-1 "가짜 철과 SSSAPI를 사용하여 알림 및 업데이트 정보를 신속하게 작성"
이 캡처는'SSSAPI 데이터를 먼저 입력하고 모델은 데이터에 따라 만들어진다[5]'로 이해할 수 있다.또'화면 관리가 힘들면 스프레드시트를 사용한다'는 과감한 장점도 느껴진다.
이렇게 쓰면'주먹구구구(평탄한) 포석만 할 수 있다'는 평가를 받을 수 있지만, 실제로 해보면 관리 화면 구조에 구애받지 않고 데이터를 유연하게 입력할 수 있다.
우선SSSAPI에서 1개의 기록에 구조화된 데이터 (수조 등 포함)(그림3-2, 그림3-3)을 입력할 수 있다.
スプレッドシートに構造化されたフィールドを入力しているスクリーンショット 그림 3-2 구조화된 필드
[
  {
    "category": "フルーツ",
    "item": [
      {
        "code": "F001",
        "name": "りんご"
      },
      {
        "code": "F002",
        "name": "みかん"
      },
      {
        "code": "F003",
        "name": "バナナ"
      }
    ]
  },
  {
    "category": "ドリンク",
    "item": [
      {
        "code": "D001",
        "name": "コーヒー"
      },
      {
        "code": "D003",
        "name": "紅茶"
      }
    ]
  }
]
▲ 그림 3-3 API 응답
필드(셀)에 표현식이나 함수 등을 지정하여 결과를 일반 값으로 사용할 수도 있습니다.다음은 계산 결과 정렬의 예이다(그림3-4, 그림3-5).
フィールドに計算式が設定されている状態のスプレッドシートが表示されているスクリーンショット 그림 3-4 금액 필드에 계산 결과가 설정되어 있음
[
  {
    "品名コード": "E230",
    "個数": 3,
    "単価": 130,
    "金額": 390
  },
  {
    "品名コード": "A089",
    "個数": 5,
    "単価": 90,
    "金額": 450
  },
  {
    "品名コード": "S001",
    "個数": 10,
    "単価": 80,
    "金額": 800
  },
  {
    "品名コード": "R001",
    "個数": 6,
    "単価": 230,
    "金額": 1380
  }
]
▲ 그림 3-5 금액 필드에서 정렬된 응답
그리고 스프레드시트가 API로 바로 바뀌면'수동 음반교환'[6]도 가능하다.
スプレッドシートの行が選択されているスクリーンショット 그림 3-6 이동 전 기록
選択された行を移動した後のスクリーンショット 그림 3-7 이동을 기록한 후
[
  {
    "品名コード": "A089",
    "個数": 5,
    "単価": 90,
    "金額": 450
  },
  {
    "品名コード": "S001",
    "個数": 10,
    "単価": 80,
    "金額": 800
  },
  {
    "品名コード": "E230",
    "個数": 3,
    "単価": 130,
    "金額": 390
  },
  {
    "品名コード": "R001",
    "個数": 6,
    "単価": 230,
    "金額": 1380
  }
]
▲ 그림 3-8 API 응답

끝말


해봤어요SSSAPI.
소감에는 우선'간편하고 쉽게', 그 외에는'방문허가 지침'과'API 구축 전까지 컨디션 유지'등 예상 밖(예상 이상)의 부분이 있어 심오함을 느끼게 한다.
모델에 있어 어느 정도 규모라면 모델을 사전에 명확하게 정의하는 것이 필요하고 무대와 일정 등을 관리하는 화면도 필요하다.
그럼에도 불구하고 전자 표로 기능을 대체함으로써 많은 사람들이 직관적으로 데이터 입력을 할 수 있다는 것이 SSSAPI의 큰 특징이라고 할 수 있다.
게다가 이번에 특징적인 부분앱시트와의 컬래버레이션도 해봤고요.을 기술했으니 이 부분도 기사로 쓰길 바란다.
각주
https://zenn.dev/kira_puka/articles/f9496a6a847799 ↩︎
이 구성을 알았을 때 애저의Durable Functions가 떠올랐다.↩︎
API 구문을 시작하려는 Webhook 식입니다.↩︎
그럼 AppSheet과 같은 부호 없는 도구를 사용해야 한다는 거야.↩︎
이 근처는 카드형 데이터베이스와 전자 표의 차이인 것 같다.↩︎
음반 일람화면에서 새롭게 배열할 수 있는 헤드리스 CMS는 의외로 적었고시도 중 마이크로CMOS만 있었다.다른 것은 여러 모델에 대응하는 참고 관계로 삼아야 한다.
참조: Use Reference Fields to Manually Order Content With Contentful and Gatsby↩︎

좋은 웹페이지 즐겨찾기