Vérifier la Compatibilité
Analysez le projet de l'utilisateur pour déterminer s'il est compatible avec l'API publique de Runway.
Pourquoi C'est Important
L'API publique de Runway nécessite une invocation côté serveur. La clé API ne doit jamais être exposée dans le code côté client. Les projets purement frontend (HTML/JS statique, SPAs côté client sans backend) ne peuvent pas appeler l'API de manière sécurisée.
Étapes d'Analyse
Étape 1 : Identifier le Type de Projet
Cherchez ces fichiers à la racine du projet pour déterminer la pile technologique :
| Fichier | Indique |
|---|---|
package.json |
Projet Node.js |
requirements.txt, pyproject.toml, Pipfile, setup.py |
Projet Python |
go.mod |
Projet Go |
Cargo.toml |
Projet Rust |
pom.xml, build.gradle |
Projet Java/Kotlin |
Gemfile |
Projet Ruby |
composer.json |
Projet PHP |
Si aucun de ces fichiers n'existe, marquez le projet comme inconnu et demandez à l'utilisateur quel langage/runtime il utilise.
Étape 2 : Vérifier la Capacité Côté Serveur
Cherchez les indicateurs d'un serveur/backend :
Projets Node.js — vérifiez les dépendances de package.json pour :
express,fastify,koa,hapi,nest,hono→ framework serveur HTTPnext→ Next.js (a des routes API — compatible)nuxt→ Nuxt.js (a des routes serveur — compatible)remix→ Remix (a des loaders/actions — compatible)@sveltejs/kit→ SvelteKit (a des routes serveur — compatible)astro→ Astro (a des endpoints API si SSR activé)
Projets Python — vérifiez :
flask,django,fastapi,starlette,tornado,aiohttp,sanic→ framework serveur webstreamlit,gradio→ peuvent faire des appels côté serveur
Signaux d'alerte (frontend uniquement) :
package.jsonavec seulementreact,vue,svelte,angularet AUCUN framework serveurvite.config.tsouwebpack.config.jssans configuration serveur/SSR- Générateurs de site statique sans routes serveur (ex. Gatsby simple, Eleventy simple)
index.htmlcomme seul point d'entrée avec balises<script>inline
Étape 3 : Vérifier les Installations Existantes du SDK Runway
Cherchez les installations existantes du SDK Runway :
Node.js :
- Vérifiez
package.jsonpour@runwayml/sdk - Cherchez
import RunwayMLourequire('@runwayml/sdk')dans les fichiers source
Python :
- Vérifiez
requirements.txt/pyproject.tomlpourrunwayml - Cherchez
from runwayml import RunwayMLouimport runwaymldans les fichiers source
Étape 4 : Vérifier la Version du Runtime
Node.js : Doit être version 18 ou supérieure (node --version)
Python : Doit être version 3.8 ou supérieure (python3 --version)
Étape 5 : Vérifier le Support des Variables d'Environnement
Cherchez un fichier .env, .env.example, .env.local, ou une configuration dotenv :
- Node.js :
dotenvdans les dépendances, ou support natif des variables d'environnement du framework (Next.js, etc.) - Python :
python-dotenvdans les dépendances, ou support natif du framework
Format du Rapport
Après l'analyse, fournissez un rapport clair :
## Rapport de Compatibilité API Runway
**Type de projet :** [Node.js / Python / etc.]
**Capable côté serveur :** [Oui / Non / Partiel]
**Version du runtime :** [version] — [Compatible / Nécessite une mise à jour]
**SDK Runway installé :** [Oui / Non]
**Support des variables d'environnement :** [Oui / Non / Configuration nécessaire]
### Verdict : [COMPATIBLE / NÉCESSITE DES MODIFICATIONS / INCOMPATIBLE]
[Si COMPATIBLE]
Votre projet est prêt pour l'intégration de l'API Runway. Procédez à la configuration de la clé API.
[Si NÉCESSITE DES MODIFICATIONS]
Votre projet a besoin des modifications suivantes :
1. [Lister les modifications spécifiques nécessaires]
[Si INCOMPATIBLE]
Votre projet est frontend uniquement et ne peut pas appeler l'API Runway de manière sécurisée. Options :
1. **Ajouter un backend** — Ajoutez un serveur Express/FastAPI ou utilisez un framework avec routes serveur (Next.js, SvelteKit, etc.)
2. **Utiliser une fonction serverless** — Ajoutez des routes API via Vercel Functions, AWS Lambda, Cloudflare Workers, etc.
3. **Créer un backend séparé** — Créez un proxy API léger que votre frontend appelle
Remarques Importantes
- Ne suggérez jamais d'intégrer la clé API dans le code côté client. C'est un risque de sécurité.
- Si le projet utilise Next.js, Remix, SvelteKit, Nuxt, ou Astro avec SSR, il EST compatible — les gestionnaires de routes côté serveur peuvent appeler l'API.
- Les plateformes serverless (Vercel, Netlify, AWS Lambda, Cloudflare Workers) sont compatibles.
- Les apps Docker/conteneurisées sont compatibles si elles exécutent un processus serveur.
Après la Vérification de Compatibilité
Si le projet est compatible, suggérez à l'utilisateur de procéder avec +rw-setup-api-key pour configurer ses identifiants API.