Slide 1
Slide 1 text
Python Social Auth の Twitter OAuth API
マイグレーションプロジェクトとその教訓
2023.10.27@PyCon APAC 2023
Slide 2
Slide 2 text
Takanori Koroki (興梠敬典)
@rocky_manobi
https://github.com/rockymanobi
https://lapras.com/public/rocky_manobi
CTO@LAPRAS株式会社
2009年からSWEをしていて、エンプラ/Webサービス等々色々作ってました
Slide 3
Slide 3 text
Python Social Auth の Twitter OAuth API
マイグレーションプロジェクトとその教訓
2023.10.27@PyCon APAC 2023
Slide 4
Slide 4 text
はじめに
本セッションでは、
実際に行った「Python Social Auth の Twitter OAuth API マイグレーション対応」を題材に、
その背景や対応内容、結果、感想、学びなどなどについて共有してまいります。
- OAuth APIのマイグレーションを行う際に注意すべきポイント
- 依存しているサービスやOSSの変更対処の考え方の一例
などをご提供できれば良いなと考えプロポーザルを出しました。
しかしながら....
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
ネタ枠としての期待にも答えなければならないのか
Slide 8
Slide 8 text
はじめます
Slide 9
Slide 9 text
Python Social Auth の Twitter OAuth API
マイグレーションプロジェクトとその教訓
◆ 前提知識の共有
ソーシャルログインや、今回の対応の背景情報について軽く触れつつ、
本セッションで題材にするシステム/サービスについてご紹介します。
◆ 実録マイグレーションプロジェクト
無料API廃止アナウンス及びその後の動きに対するLAPRASでの対応について、
システム的な内容を含めてご紹介します。
◆ 結果と振り返り
対応プロジェクトの結果や各局面における判断について振り返り、
今回得た学びを共有します。
◆ まとめなど
Slide 10
Slide 10 text
前提知識の共有
Slide 11
Slide 11 text
前提知識の共有
-
ソーシャルログインについて
Slide 12
Slide 12 text
ソーシャルログイン
Slide 13
Slide 13 text
ソーシャルログイン
会員登録やログインの手間の軽減
- 情報入力を簡略化することができる
- ログインに必要な情報を増やさずに済む※
SNS情報の取得とサービスへの活用
Slide 14
Slide 14 text
- Firebase Authentication
- Auth0
- okta
- Stytch
- AWS Cognito
ソーシャルログイン - 実装の選択肢
IDaaS等のサービスを利用
OAuthプロトコルを直接利用
https://github.com/joestump/python-oauth2
https://github.com/pennersr/django-allauth
https://github.com/python-social-auth
◆ django-allauth
◆ python-social-auth
◆ python-oauth2
例 : 以下のようなライブラリが利用可能 例 : 以下のようなサービスが利用可能
Slide 15
Slide 15 text
- Firebase Authentication
- Auth0
- okta
- Stytch
- AWS Cognito
ソーシャルログイン - 実装の選択肢
IDaaS等のサービスを利用
OAuthプロトコルを直接利用
https://github.com/joestump/python-oauth2
https://github.com/pennersr/django-allauth
https://github.com/python-social-auth
◆ django-allauth
◆ python-social-auth
◆ python-oauth2
例 : 以下のようなライブラリが利用可能 例 : 以下のようなサービスが利用可能
今日のお話は
python-social-auth にフォーカス
システム的な課題については他のライブラリでも同じよ
うな課題が発生しそうではあります。
(内部を軽く見た感想なので要出典です)
今回は触れませんが、
最近は直接利用よりもIDaaSを積極的に利用する流れが
強い印象です(私も同意です)
Slide 16
Slide 16 text
ソーシャルログイン
https://speakerdeck.com/yktakaha4/python-social-authdexue-bu-oauth2-dot-0ren-ke-kodohuroniokeruyi-chang-xi-henodui-chu
@yktakaha4 さんの PyCon JP 2022 のセッション発表資料を読むと、
ソーシャルログインやOAuth2.0の認可フローについての理解が深まります。
あわせて読みた
い
Slide 17
Slide 17 text
前提知識の共有
-
Twitter API騒動
Slide 18
Slide 18 text
Twitter API 騒動
2023.02.02
「1週間後の2月9日にAPIの無料アクセス廃止する
よ」 EnterPriseなのに止まった！
2月9日になったのにアナウンスがない??
API v1.1死んだ？
API使えなくなったのでサービス終了します
ログインできなくなりました
落ちた！！
2023.07.24
「Xになったよ」
2023.08.22
「API v1.1も続々廃止していく
よ」
なんか復活した?
API制限でツイート見られない？
2023.01.xx
「昔からあるルールをちゃんと守っていないアプリはAPIアクセスをブロックする
よ」
100$/月 !??
対応完了しました
Slide 19
Slide 19 text
前提知識の共有
-
題材となるシステムの紹介
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
データ収集
ポートフォリオ
データ構築
ビジュアライズ
Slide 23
Slide 23 text
Userサポートのための
Twitter監視のためのツ
イート取得APIコール
データ収集
ポートフォリオ
データ構築
ビジュアライズ
データ取得のための
APIコール
ユーザ認証のための
APIコール(主にOAuth)
Crawler
こちらが今日のメインです
話題にはでてきます
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
サポートしているログイン方式
Slide 26
Slide 26 text
本編 - マイグレーション対応
Slide 27
Slide 27 text
2023.02.02 ~ 2023.03.30
無料API廃止宣言
Slide 28
Slide 28 text
https://twitter.com/XDevelopers/status/1621026986784337922?s=20
Slide 29
Slide 29 text
そのときのわたし
気分転換タスクを片付けていい気分だった
出社日をお祝いしてくれるSlackBotの新verを作っていた
Slide 30
Slide 30 text
影響調査
2023.02.02時点では料金や必要な手順などの情報は一切不明であったため、
Twitter APIが一切使用できなくなることを想定して一次調査を実施した。
Crawler への影響
画面に表示するTwitterアカウントページへのリンク、
フォロワー数等の情報が取得できなくなる
=> 最悪許容するしかない
ログイン・新規登録 への影響
Twitterによるログイン・新規登録ができなくなる
=> 最悪許容するしかない
=> ログイン手段がTwitterのみであるユーザはサービスにログインする手段を失う可能性があり、こ
の事象は許容できない が、事後でもユーザの操作のみで救済できるルートが確率されている = メール
アドレスによるログインを追加できる(※) ことを確認できたため、ケアができていると判断
※サービス登録時、SNSによる認証であってもメールアドレスを入力する仕様があり、
このメールアドレスを指定してパスワードリセット操作を実行すると以後メールアドレスとパスワードでログインが可能
Slide 31
Slide 31 text
影響調査 - 事業数字周り
新規獲得への影響 => 軽微
注力ターゲット(当時) のうち、
Twitter広告経由かつTwitter連携で獲得できているユーザは全体の1%
MAU / DAU => 軽微(+)
当月のアクティブユーザのうち、
Twitterが唯一のログイン手段であるユーザの割合は0.3%。
※ただし、普段遣いでTwitterを用いているユーザがその他の手段を取ることが面倒になり... というケ
ースは考えられる
※サービス登録時、SNSによる認証であってもメールアドレスを入力する仕様があり、
このメールアドレスを指定してパスワードリセット操作を実行すると以後メールアドレスとパスワードでログインが可能
Slide 32
Slide 32 text
影響調査
APIアクセスをCloseされたとしても
致命傷には至らないことは分かったので、
続報を待つことに
Slide 33
Slide 33 text
その後
正式な続報が 3月30日 に展開されますが...
Slide 34
Slide 34 text
おまけ！
おまけ - Xデーとされた 2月9日
https://twitter.com/XDevelopers/status/1623467615539859456
https://twitter.com/XDevelopers/status/1623467618400374784
https://twitter.com/XDevelopers/status/1623467619725774848
追加情報は展開されるも、
細切れなので具体的な対処には踏み切れない
Slide 35
Slide 35 text
おまけ！
おまけ - 対応延期の報
https://twitter.com/XDevelopers/status/1625234161010343941
https://twitter.com/XDevelopers/status/1626732269174943745
これまで発信した方針はまだ活きている
けれど段階的に進めていくよ...てきな。
Slide 36
Slide 36 text
https://www.itmedia.co.jp/news/articles/2303/13/news159.html
おまけ - 各所の反応や情報発信
https://twitter.com/maximehugodupre/status/1625237066115084311?s=20&t=9midKkco2YTM2gvVhmlC4A
2/14
Slide 37
Slide 37 text
2023.03.30 - 新しい料金体系と移行スケジュールの発表
https://twitter.com/TwitterD
ev/status/1641222782594
990080?s=20
Slide 38
Slide 38 text
現在はPROプランが存在するが、
この時点ではアナウンスもされていない
Slide 39
Slide 39 text
Crawler
- API v2.0 を利用するように変更する
- rate limit を上回る場合はplanを変更する
(こちらもややこしい経緯がありますが今回は割愛します)
ログイン・新規登録
- 対応しない
- 厳密に言うとここについては自信を持てる状態ではなかった。
しかしながら、一時的なダウンは許容できるという評価と、仮に v1.1廃止に伴
う影響があるとしても局所対応が可能であると判断。
加えて、これまでの経緯からアナウンス通り対応したとしても影響無しで対処
しきれるとは考えられなかったため、事実が確定する事後対応のスタンスをと
ることにした。
- 料金体系が変更される(無料 or 100$ or Enterprise)
- API v1.1 が廃止される (これは誤解。最後に触れます)
- OAuthAPI v1.0a は引き続き利用できる(廃止の報に含まれていない)
解釈
対応
方針
Slide 40
Slide 40 text
おまけ - 2023.04.04 に起きた2つのできごと
https://twitter.com/koni/status/1643047128745512960
Enterprise APIを利用しているサービス含め、
APIが予告なく凍結される騒動も
https://social-dog.net/ja/
Slide 41
Slide 41 text
おまけ - 2023.04.04 に起きた2つのできごと
柴犬をシンボルとする暗号資産「ドージコイン」が30%急騰したらしいです
https://twitter.com/koni/status/1643047128745512960
Enterprise APIを利用しているサービス含め、
APIが予告なく凍結される騒動も
https://social-dog.net/ja/
メイン画面左上のアイコンが柴犬に変更される
心中お察しします
Slide 42
Slide 42 text
2023.04.27
強制Suspended
突如Twitterログインができなくなる
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
緊急対処 : メッセージ表示による通知 / ログインボタンの非表示化など
Slide 45
Slide 45 text
無傷での対応は不可避
最速でのTwitterログイン機能を復旧する道をとるならば
Crawlerやサポート用のアプリを消去すれば良いが...
強制的なプラン移⾏によって、無料プランの「1アカウントに紐付けられるアプリ
数 =1個」が適⽤され、溢れた分が全てsuspendされた。
suspendされる多少はランダムのようだった。
OAuth v1.0aは廃⽌されてはいなかった(ここは想定通りではあった)
dev⽤, staging⽤は消せるが、その他のAppは本番動作している。
異なるアカウントで新しくAppを作成すると OAuth v1.0a、API v1.1 は使えない。
API v2.0移⾏対応は完了していない。
原因 - APIの廃止ではなくアプリの数制限に抵触した
Slide 46
Slide 46 text
消したとして...まともに動くのか？
APIが中途半端に動く状態である可能性も否定できない
我々のシステムはその状態を想定できているだろうか....
(ものすごく検証しづらい)
仮に無事復旧ができたとして、
今後のイレギュラーにも付き合い続けられるのか...？
(この対応中に更にサプライズが起きて状況が悪化する等あれば、機能のサポートをそのままクローズさせることも考えていました)
対応方針
最速でのTwitterログイン機能を復旧する道は取らない。
Twitterに関連する機能をクローズしたまま、利用APIを全て最新のものに入れ替える等、
安全性・確実性がもっとも高いと考えられる方法をとる。
APIはv2.0に上げる。OAuth API も2.0に上げる。
ただし、事業数字であるDAUや新規登録数に悪影響が見られた場合は方針を転換する。
結論
Slide 47
Slide 47 text
https://developer.twitter.com/en/docs/twitter-api
当時のアナウンス 現在のWebページの表記
おまけ - 言い訳のスライド
今振り返ればアナウンスはあったと言えるが...
Slide 48
Slide 48 text
2023.04.27 ~ 2023.06.05
システム的対処
Slide 49
Slide 49 text
A. python-social-auth を Twitter OAuth API v2.0 に対応させる
B. アプリ側のマイグレーション課題の解決
C. QA / リリース
システム的対処
python-social-auth を題材にお話しますが、
おそらく同じようなところが問題になりそうな気がします
Slide 50
Slide 50 text
システム的対処
-
python-social-auth を
Twitter OAuth API v2.0 に対応させる
Slide 51
Slide 51 text
python-social-auth の構造
social-core
social-app-django
python-social-auth のコアロジック
ソーシャルログインに関する共通的な機能やインターフェイスを提供
認証プロバイダ毎の固有実装(backendと呼称されている)
いくつかのリポジトリ/パッケージに分かれている
social-core をDjango に組み込むための各種機能を提供
- Model / View / Middleware / etc,
Slide 52
Slide 52 text
使い方は social-docs というリポジトリに
https://github.com/python-social-auth/social-docs
python-social-auth の構造
social-core には各種OAuthプロバイダに対応するclassが定義されている
settings.py にて利用するプロバイダを指定
Slide 53
Slide 53 text
OAuth2.0用の backendが無かったので
これを実装
python-social-auth を Twitter OAuth API v2.0 に対応させる
ここの実装についての詳細は割愛します。
[参考] https://github.com/python-social-auth/social-core/pull/791
Slide 54
Slide 54 text
- 先々social-coreに破壊的変更が発生した場合に、リポジトリ内部においているコードは取り残され
てしまう / 誰かが別の実装の TwitterOAuth2対応を行った場合ややこしいことになる
- リポジトリに用意されたテストのヘルパー等を利用したテストを実行できる
- contributionフローにのっとりつつ、メンテナのレビューを通ることで意識できていないリスクをあ
る程度減らすことができる
- 後述する、アプリ側のOAuthAPIのマイグレーション対応が開発負荷としては比重が大きく、こちら
が早く終了しても対応完了は早くならない
- mergeされない、リリースされない場合はそれがわかってからでもforkしたものを参照する/リポジ
トリ内部でbackendを実装するという手段を取ることができる
手元のリポジトリ内部にオリジナルのバックエンドとして実装する選択肢はとらず、
あくまで本家に取り込んでもらうルートをベストシナリオとして対応した。
python-social-auth を Twitter OAuth API v2.0 に対応させる
ここの実装についての詳細は割愛します。
[参考] https://github.com/python-social-auth/social-core/pull/791
OAuth2.0用の backendが無かったので
これを実装
Slide 55
Slide 55 text
- 先々social-coreに破壊的変更が発生した場合に、リポジトリ内部においているコードは取り残され
てしまう
- リポジトリに用意されたテストのヘルパー等を利用したテストを実行できる
- contributionフローにのっとりつつ、メンテナのレビューを通ることで意識できていないリスクをあ
る程度減らすことができる
- 後述する、アプリ側のOAuthAPIのマイグレーション対応が開発負荷としては比重が大きく、こちら
が早く終了しても対応完了は早くならない
- mergeされない、リリースされない場合はそれがわかってからでもforkしたものを参照する/リポジ
トリ内部でbackendを実装するという手段を取ることができる
手元のリポジトリ内部にオリジナルのバックエンドとして実装する選択肢はとらず、
あくまで本家に取り込んでもらうルートをベストシナリオとして対応した。
python-social-auth を Twitter OAuth API v2.0 に対応させる
ここの実装についての詳細は割愛します。
[参考] https://github.com/python-social-auth/social-core/pull/791
OAuth2.0用の backendが無かったので
これを実装
CTOならそれくらいやりなよ - 一緒にやるからさ
という @yktakaha4氏からの温かいお声掛けもあり...
Slide 56
Slide 56 text
social-auth-app-django social-auth-core
LAPRAS
アプリへの取り込み
LAPRASからは「social-auth-app-django」を経由して利用している。
- [ ] masterマージ
- [ ] リリース
- ✅ masterマージ
- [ ] リリース
- [ ] 依存バージョン更新
Slide 57
Slide 57 text
social-auth-app-django social-auth-core
LAPRAS
アプリへの取り込み
LAPRASからは「social-auth-app-django」を経由して利用している。
- [ ] masterマージ
- [ ] リリース
- ✅ masterマージ
- [ ] リリース
- [ ] 依存バージョン更新
PR作成から2weeksでマージしてもらえた(ありがたい)、
なかなかリリースはしてもらえなかった(しかたない)
(直近は1回超/月はリリースされていたのに...)
Slide 58
Slide 58 text
social-auth-app-django social-auth-core
LAPRAS
アプリへの取り込み
「social-auth-core」を手元でビルドしてLAPRASのコードにtar.gzを配置しつつ、
pyproject.tomlを以下のように記述して取り込む (poetry利用)
手元でビルドして取り込み
※本家のmasterには入っているので今後のアップデートがTwitterOAuth2のコードを無視
して進む危険性はないので一旦はよしとした。
Slide 59
Slide 59 text
未だリリースされていない。メンテナ名のり出る必要があるのかもしれない
Slide 60
Slide 60 text
システム的対処
-
アプリ側のマイグレーション課題の解決
Slide 61
Slide 61 text
課題 1
以前に Twitter OAuth v1.1 で登録/ログインしていたユーザが、
Twitter OAuth v2.0 の認可フローを通ってログインを試みたとき、
別人として扱われ、新規登録フローにすすんでしまう
Slide 62
Slide 62 text
python-social-auth では
OAuth認可フローを通過した後の各処理が細切れに実装されている。
=> pipeline functionと呼称
python-social-auth の構造
詳しくはコチラに
https://zenn.dev/rocky_manobi/articles/438cd4f01166af
pipeline function は
定義された実行順序の通りに実行される
各 pipeline functionが戻した値は次に実行される関数に
引数として渡されていく
Slide 63
Slide 63 text
Appのログインセッションが活きていない場合
- UserSocialAuthというモデル(テーブルを) provider と uid をキーにして検索し、
既に存在しているかどうかを判定
- 存在する場合は「既存ユーザのログイン」と判定
存在しない場合は「新規ユーザの登録」と判定
セッションが活きている場合
- UserSocialAuthというモデル(テーブルを) provider と uid をキーにして検索し、
現在ログインしているユーザと一致しているか否かを調べる
- 一致していない場合は「既に他のユーザと紐づいている」エラーとする
原因と解決策
Slide 64
Slide 64 text
Appのログインセッションが活きていない場合
- UserSocialAuthというモデル(テーブルを) provider と uuid をキーにして検索し、
既に存在しているかどうかを判定
- 存在する場合は「既存ユーザのログイン」と判定
存在しない場合は「新規ユーザの登録」と判定
セッションが活きている場合
- UserSocialAuthというモデル(テーブルを) provider と uuid をキーにして検索し、
現在ログインしているユーザと一致しているか否かを調べる
- 一致していない場合は「既に他のユーザと紐づいている」エラーとする
Twitter OAuth API v1.0a の場合の provider は “twitter”
Twitter OAuth API v2.0 の場合の provider は “twitter-oauth2”
検索キーとなる値が異なるため、
常に新規作成ユーザ と扱われてしまっていた
原因と解決策
Slide 65
Slide 65 text
Providerが”twitter-oauth2”である場合には、
provider = twitter であるデータを探して判定する pipeline fnctionを作成
Slide 66
Slide 66 text
Providerが”twitter-oauth2”である場合には、
provider = twitter であるデータを探して判定する pipeline fnctionを作成
is_new などのpipeline functionに渡される引数については
こちらを参照ください。
https://zenn.dev/rocky_manobi/scraps/dd78bdd777c42f
Slide 67
Slide 67 text
詳しくはコチラに
https://zenn.dev/rocky_manobi/articles/438cd4f01166af
原因と解決策
‘social_core.pipeline.social_auth.social_user’ の後段で実行してくれるよう、
settings.pyに実行順序を定義する
※Twitter OAuth 1.1a をサポートし続ける場合はこの逆「twitter -> twitter-oauth2」の考慮も必要
Slide 68
Slide 68 text
課題 2
こういうやつ....
SNSサービス と OAuth Provider は別のもの。
名前がたまたま同じだからといって同じように扱うと痛い目を見るという典型。
provider名 => SNS名 の読み替えを行う機構を作って対処。
(サービスの性質上利用箇所が多岐にわたっており...)
どのようなライブラリ / サービスを利用していても、このような箇所がないかどうか
はチェックしたほうが良さそうです。
Slide 69
Slide 69 text
システム的対処
-
QA / リリース
Slide 70
Slide 70 text
Featureフラグを用いて、 TwitterOAuth2対応のコードがデプロイされているが
UI上は利用されない状態を作れるように実装しつつ...
QA / リリースの工夫
既存の動作を壊していないことを確認するためのQAを集中して実施
Featureフラグ = OFF の状態で2週間 本番稼働を監視
デプロイ
リリース(Featureフラグ
ON)
追加した Twitter OAuth API v2.0 周りの挙動をQA (staging)
Slide 71
Slide 71 text
結果！
⭕ 移行後システムトラブルはなし(今のところ)
⭕ 機能を閉じていた間の事業数字(新規獲得/DAU,MAU)への悪化も認められず
(他の要因で説明がつく状態)
MAU昨対比
新規獲得
Slide 72
Slide 72 text
おまけ - 鳥とTwitterの痕跡はまだ...
Slide 73
Slide 73 text
感想戦
Slide 74
Slide 74 text
Twitterログイン機能の早期復旧を目指さない選択肢は正解だったのか？
感想戦 - 1
2023.08.22
「API v1.1も続々廃止していく
よ」
選ばなかった世界線の評価は難しいところではあるけれど、正解と考えている。
結果としてトラブル無く対応を完了できたことや、
対応完了後にアナウンスされた API v1.1 を廃止するというアナウンスに反応しなくて済み、
普段の開発を継続できている。
このさきOAuth API v1.1a が廃止される日が来たとしても対応済みとして構えることができる。
やってわすれる。大事。
Slide 75
Slide 75 text
廃止アナウンスに対する構えは隙だらけだった
最悪を想定して調査/見積もりを行うことはできていた。
本当に最悪が起こるとしてやるべきことを考えていない楽観思考があった。
Twitter関連機能をフラグ操作1つでクローズできるような仕組みを構築する程度
の対応は行われてしかるべきだった。
(要因は色々考えられますが飲み会とかでお話しましょう)
感想戦 - 2
Twitterのアナウンスが信用できない / 何が起こるかわからない と言っておきながら、
「ここは影響がなさそう」という楽観材料については信じてしまう心の弱さが強く出ていた？
機能としての重要度がそこまで高くないという背景と、結果論的には問題がないとは言えることと、
当時のことは記憶をたどることしかできないので、このあたりは次にこのような状況があったときに自
問できるようにしておこうとおもう。
Slide 76
Slide 76 text
感想戦 - 3
そもそもTwitter API についての理解が圧倒的に足りていなかった
今回の対応には少なくとも以下の単語について、
意味合い、役割、関係を理解した上で望む必要があったはず。
Essencial, Standard, Premium, Elevated, basic, pro, free, enterprise, API v1, API v1.1, API v2
OAuth API v1.0a , OAuth API v2.0
これらを理解した上で改めてアナウンスを追いかけると、
我々は途中で直面したトラブルの原因を多く見誤っていたことが分かった。
そしておそらく我々と同じく多くの人が同じような誤解をしていたと考えられる。
例えば …
少なくともX(Twitter)は 2023.08.22 まで、
API v1.1 を廃止するというアナウンスはしていない(名指しした特定のAPIを除いて)。
にもかかわらず ….. つづきは口頭で！
Slide 77
Slide 77 text
感想戦 - 3
そもそもTwitter API についての理解が圧倒的に足りていなかった
今回の対応には少なくとも以下の単語について、
意味合い、役割、関係を理解した上で望む必要があったはず。
Essencial, Standard, Premium, Elevated, basic, pro, free, enterprise, API v1, API v1.1, API v2
OAuth API v1.0a , OAuth API v2.0
これらを理解した上で改めてアナウンスを追いかけると、
我々は途中で直面したトラブルの原因を多く見誤っていたことが分かった。
そしておそらく我々と同じく多くの人が同じような誤解をしていたと考えられる。
例えば …
少なくともX(Twitter)は 2023.08.22 まで、
API v1.1 を廃止するというアナウンスはしていない(名指しした特定のAPIを除いて)。
にもかかわらず ….. つづきは口頭で！
雰囲気で触るというのはとても危ない
強い気持ちで使っているものを理解している状態を目指そう
Slide 78
Slide 78 text
おわりに
一連の流れを
改めて調べてみての感想
Slide 79
Slide 79 text
複雑な料金体系や新旧複数のドキュメントの不整合による混乱は
確かに問題の種ではあるけれども...
それは試行錯誤を重ねてきた証であり、
WebAPIを用いたものづくりが当たり前になる前の時代から続くその試行錯誤は
現存するAPIの運用や料金設計のベストプラクティスやノウハウに多少なりとも
還元されているのは間違いないし、結果としてWeb APIを用いたマッシュアップ
のカノ生を切り開くことにも大きく貢献していたのだとおもう。
今回の急激な変化について思うことがないわけではないけれども、
そこには敬意を払いつつ、もしエコシステム維持の負担が集中してしまってい
たのであれば、継続できるようにするための変化は受け入れる姿勢は持ちたい
なと思いました。
Slide 80
Slide 80 text
Python Social Auth の Twitter OAuth API
マイグレーションプロジェクトとその教訓
2023.10.27@PyCon APAC 2023