Background jobs and workers
“Worker” in Sylva can mean three related things. This page disambiguates them so you land in the right repository when debugging.
1. LoopBack Worker model (Identity Manager / api-models)
Section titled “1. LoopBack Worker model (Identity Manager / api-models)”The API exposes a Worker resource with remote methods only (no standard model CRUD). Examples from the public contract (see API reference):
POST /Worker/processWebhookAnalyticsPOST /Worker/scheduled-cleanupPOST /Worker/cleanupExpiredTokensPOST /Worker/cleanupOrphanProjects
Implementation lives in api-models under worker/ (methods, hooks) and is loaded by Identity Manager like any other model. These endpoints are invoked by schedulers, webhooks, or internal HTTP calls—often from GCP (Cloud Scheduler → HTTP, Pub/Sub push, etc.).
When you add a new HTTP-triggered maintenance or analytics job that belongs with the LoopBack app, this is the usual place.
2. Google Cloud tasks in the main backend
Section titled “2. Google Cloud tasks in the main backend”Identity Manager dependencies include @google-cloud/tasks, @google-cloud/pubsub, and related libraries. Many Project and SystemUser flows enqueue work (invitations, analytics, debounced actions) rather than doing everything inline. Those code paths are still inside api-models / Identity Manager server code; look for Cloud Tasks and Pub/Sub usage in model methods.
3. sylva-worker repository (standalone packages)
Section titled “3. sylva-worker repository (standalone packages)”The sylva-worker repo holds separate Node (and other) packages that are deployed as their own processes or functions. Examples present in the workspace (names are illustrative—check each package.json):
| Package / area | Likely purpose |
|---|---|
| pdf-maker | PDF generation (e.g. pdfmake + GCS) |
| pdf-printer | Related PDF pipeline |
| component-parser | Parses content/component data; uses MongoDB, GCS |
| image-resizer | Image processing |
| algolia-indexer | Search indexing |
| bigquery-loader | Analytics / data warehouse loads |
| e2e-tests | Worker-related integration tests |
| selenium-cluster | Kubernetes/Helm for Selenium |
| visa_form | Python tooling (isolated use case) |
These services typically:
- Use service account JSON (e.g.
gcloud.service.key*.jsonpatterns in repo—never commit real keys; use secrets in deployment). - Talk to GCS, MongoDB, or other GCP APIs in the same project as Sylva.
Operational notes (e.g. clearing Pub/Sub backlog) may appear in the repo README snippets.
Choosing where to implement a new job
Section titled “Choosing where to implement a new job”| Criterion | Prefer |
|---|---|
| Tight coupling to LoopBack models, transactions, ACL | api-models Worker or model method + Task queue |
| Heavy dependency isolation, different runtime, or reuse across services | sylva-worker package + deploy separately |
User-visible API contract must stay under /api | LoopBack remote method |
Related documentation
Section titled “Related documentation”- API reference —
Workerpaths - Backend API and api-models — model layout
- System architecture — diagram