1.7 KiB
1.7 KiB
Rivet Sample Validation and Observed Drift
Validated sources:
zoom/rivet-javascript-samplezoom/isv-rivet-starterzoom/Rivet-Server-Samplezoom/rivet-javascript
Lifecycle Patterns Confirmed
- Module clients are instantiated with auth + receiver options.
- Handlers are registered before or near startup.
client.start()bootstraps receiver/server.- Multi-module samples use unique ports per module.
/zoom/eventsendpoint suffix is required for webhook callbacks.
Architecture Patterns Confirmed
- Rivet acts as an orchestration layer:
- Typed endpoint wrappers for API operations.
- Webhook consumer methods for events.
- OAuth helper behavior embedded in client lifecycle.
Useful Additions Incorporated into Skill
- Multi-module port segregation and webhook endpoint mapping.
- Distinct auth patterns by module.
- Sample-derived operational gotchas for ngrok and OAuth install.
Contradictions and Drift Notes
- Some docs/samples reference older Team Chat doc paths (
team-chat-apps) while current docs may use updated routing. - Sample env variable naming is inconsistent across repos (
StS_*,WEBHOOK_SECRET_TOKEN, per-module keys). This skill standardizes names inenvironment-variables.md. - Some sample README commands imply one port while module receivers may actually use
base+1or per-module ports. - User OAuth behavior depends on receiver choice;
AwsLambdaReceiverlimitations must be handled explicitly.
Recommendations
- Keep a local compatibility table:
rivet_versionxmodules_usedxauth_flowsxreceiver_type. - Treat sample repos as patterns, not strict source of truth.
- Re-check TypeDoc and changelog before each release.