ETL: multi-tenant token management for high-volume data pipelines
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Start by reading the SDK's existing OAuth token creation flow and CacheInterface to understand their contracts. Then determine whether token pooling belongs in the core SDK and how expiry should be represented; the issue leaves both decisions open. Done means an agreed design supports per-tenant token reuse and refresh before jobs start.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
In multi-tenant SaaS platforms, each tenant has its own Openapi credentials. Running ETL jobs for hundreds of tenants simultaneously requires generating, caching, and refreshing tokens per-tenant — something the current SDK does not model.
Current workaround
foreach ($tenants as $tenant) {
$oauth = new OauthClient($tenant['username'], $tenant['apikey']);
$token = json_decode($oauth->createToken($scopes), true)['token'];
// Problem: no TTL tracking, no reuse across jobs, no central cache
$client = new Client($token);
runEtlJob($tenant, $client);
}
What would help
A TokenPool or TokenStore abstraction that:
- Caches tokens per-tenant until near expiry
- Refreshes automatically before a job starts
- Plugs into the existing
CacheInterface
$pool = new TokenPool($oauthClient, cache: new RedisCache($redis));
$client = new Client(tokenPool: $pool->forTenant($tenantId));
Open questions
- Is
TokenPoolwithin scope for the core SDK or a separate package? - Should it integrate with the existing
Cache\CacheInterfaceor define its own contract? - How should token expiry be tracked — store the TTL alongside the token?
- Lingua principale
- PHP
- Stelle
- 20
- Fork
- 3
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di openapi/openapi-php-sdk
-
Improve PHPDoc Consistency Across the CodebaseForse di nuovo libera @Seraphim200001 l’ha presa 138 giorni fa e non c’è nessuna pull request aperta. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
openapi/openapi-php-sdk#36 · 3 commenti ·
-
enhancement help wanted
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
openapi/openapi-php-sdk#34 ·
-
good first issue question
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
openapi/openapi-php-sdk#33 · 2 commenti ·
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
openapi/openapi-php-sdk#32 ·
-
help wanted question
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
openapi/openapi-php-sdk#31 ·
Tutte le issue di openapi/openapi-php-sdk
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
fe: spell out "Auto increment" in the table editor, "AI" reads as artificial intelligence todayAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
landsman/adminer-desktop#120 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
-
L: java:gradle L: java:maven L: ruby:bundler T: bug 🐞
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
dependabot/dependabot-core#16547 ·
I maintainer di solito rispondono entro 1 giorno
-
cloning objets from planningAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
glpi-project/glpi#25922 ·
I maintainer di solito rispondono entro 1 giorno