How ComputeSphere maps these: static site, web service, background worker, cron job

The four types, one line each

• Static site: files only once built. Built from a Git repository and served from ComputeSphere's edge (servers close to your visitors that hand out files), with no spherelet running.
• Web service: anything that answers HTTP requests, such as a server-rendered app or an API. It gets a public HTTPS URL.
• Background worker: slow work kept away from requests, such as sending emails or resizing uploads. It runs all the time and has no URL.
• Cron job: work at set times, such as a nightly report. It runs, then exits.

A spherelet is one running copy of a service, as in lesson 1.2.1; Path 5 covers them in depth.

From shape to services

• Static site shape: one static site.
• Server-rendered app: one web service.
• Single-page app and an API: a static site for the app's built files, and a web service for the API, which the app calls at its public URL.

Some teams serve a single-page app's files from the API's web service instead. That's one fewer service, but a spherelet serves every file, not the edge.

Whichever shape you pick, slow work and scheduled work don't belong inside a request. They become services of their own, beside the web service: a background worker for work handed off from a request, a cron job for work that runs on a clock.

One product, four parts

A shop at example.com might have:

• marketing pages at example.com: a static site;
• the store at shop.example.com, which renders pages from the database: a web service;
• order confirmation emails, sent after checkout: a background worker;
• a sales summary every morning at 6: a cron job.

The database isn't on the list, because it isn't a service type. On ComputeSphere it's a SphereDB database in the same environment, or one hosted elsewhere, and your services connect to it.

Ports, health checks and schedules are in lesson 5.2.2, Service types, when you come to deploy.