Mitä tämä artikkeli kattaa

Jos toimitat whitelabel-sovelluksia — tai edes vain yhtä sovellusta, jolla on useita kauppamerkintöjä — olet todennäköisesti törmännyt kuvakaappausongelmaan. Apple haluaa kuvakaappauksia jokaiselle laitteen koolle. Google Play haluaa oman sarjansa. Tuki kolmelle kielelle on kolminkertaistanut työmääräsi. Kerro nyt se ylläpitämiesi brändiversioiden määrällä.

Edellinen artikkeli selitti, miksi Screenshots Live on olemassa. Tämä on käytännöllinen jatko: miten render API on suunniteltu, mitä se odottaa ja miten se kytketään build-putkeesi, jotta kuvakaappauksista lakkaa olemasta manuaalinen tehtävä.

Miten renderointiputki on suunniteltu

Renderointijärjestelmä ei ole synkroninen send-request-get-image-päätepiste. Se on työpohjainen putki, mikä on tärkeää, kun renderoit kymmeniä tai satoja kuvakaappauksia eräajona.

Lähetät renderointipyynnön mallin ID:llä ja valinnaisilla YAML-ohituksilla (teksti, kuvakaappaukset, laitekehykset — kaikki, mikä on merkitty vaihdettavaksi).
Validointi — järjestelmä tarkistaa, että mallisi on olemassa, olet sen omistaja ja jokainen ohitettava kenttä on sallittu.
Jonottaminen — työ menee Redis-tukemaan BullMQ-jonoon. API-kutsusi palaa välittömästi jobId:llä ja tilalla Pending.
Renderointi — Rust-pohjainen worker ottaa työn, hakee mallin ja kuvat (LRU-välimuistilla toistuviin renderointeihin), lataa fontit, renderoi kankaan Skialla ja tuottaa tuloksen.
Pakkaaminen — renderoidut kuvat pakataan ZIP:ksi ja ladataan objektisäilöön.
Lataaminen — kyselyt tilapäätepistettä. Kun se on Completed, osut latauspisteeseen ennalta allekirjoitetulle URL:lle (voimassa 1 tunti).

Asynkroninen suunnittelu on tarkoituksellinen. Kun sinun on renderoitava 50 mallia julkaisua varten, ammut ne kaikki irti ja sitten keräät tulokset. Ei estämistä, ei aikakatkaisuja.

Todennus

Tarvitset Pro-tilin päästäksesi render API:hin. Luo API-avain kojelaudaltasi — se näyttää sa_live_...:lta. Jokainen pyyntö käyttää sitä Bearer-tokeni:

Authorization: Bearer sa_live_your_key_here

Mallit: Miten ne on rakennettu

Kaikki pyörii mallien ympärillä. Malli on kangas, jonka rakennat visuaalisessa editorissa — sijoitat tekstilohkoja, laitekehyksiä, kuvia ja asetat taustoja. Jokainen elementti kankaalla on kohde ainutlaatuisella UUID:llä.

Automaation kannalta kriittinen käsite on vaihdettavat kentät. Ei jokainen jokaisen kohteen ominaisuus ole ohitettavissa API:n kautta. Järjestelmänvalvoja konfiguroi, mitä kenttiä voidaan vaihtaa — tekstisisältö, kirjasinperhe, kirjasinkoko, värit, kuvakaappaus-URL:t, laitekehyksen ID:t jne. Tämä on tarkoituksellinen rajoitus: se estää API-kuluttajia vahingossa rikkomasta asettelua muuttamalla asentoja tai kokoja, jotka suunnittelija lukitsi.

Ajattele sitä sopimuksena suunnittelijasi ja putkisi välillä: suunnittelija omistaa asettelun, putki omistaa sisällön.

YAML-ohitusjärjestelmä

Tämä on API:n ydin. Sen sijaan, että renderoisit mallin tarkalleen sellaisena kuin se on tallennettu, POST-at YAML:n, joka ohittaa tietyt kentät tietyissä kohteissa.

Vaihe 1: Hae YAML-runko

curl -H "Authorization: Bearer sa_live_your_key_here" \
  https://api.screenshots.live/templates/YOUR_TEMPLATE_ID/yaml

Vaihe 2: Lähetä renderointi

curl -X POST https://api.screenshots.live/render/api \
  -H "Authorization: Bearer sa_live_your_key_here" \
  -H "Content-Type: text/yaml" \
  -d 'templateId: "550e8400-e29b-41d4-a716-446655440000"
items:
  - itemId: "7c9e6679-7425-40de-944b-e07fc1f90ae7"
    type: Text
    text: "Seuraa toimituksiasi"
    color: "#1A73E8"'

Vaihe 3: Pollaa tilaa

curl -H "Authorization: Bearer sa_live_your_key_here" \
  https://api.screenshots.live/render/api/JOB_ID

Tila etenee Pending → Active → Completed (tai Failed). Useimmille malleille renderointi kestää muutaman sekunnin.

Vaihe 4: Lataa

curl -H "Authorization: Bearer sa_live_your_key_here" \
  https://api.screenshots.live/render/JOB_ID/download

Palauttaa ennalta allekirjoitetun URL:n. Lataus on ZIP, joka sisältää renderoidut kuvasi.

Kuvakaappausten suora lataus

Sinun ei tarvitse isännöidä kuvakaappauksiasi jossain vain URL:n välittämiseksi. Päätepiste /render/api/with-pictures hyväksyy moniosaiset lataukset. Voit liittää enintään 200 tiedostoa, jokainen enintään 10 Mt. Tämä tekee API:sta käytännöllisen CI/CD:lle — putkesi kaappaa kuvakaappaukset ja lähetät ne suoraan renderointiin ilman välivarastointia.

Laitekehysten vaihtaminen

Laitekehykset ovat mockup-peittokuvia — iPhone 16 Pro, Pixel 9, iPad Air, Galaxy S24. Ne on esiladattu tilillesi ja niihin viitataan UUID:llä. Sama malli voidaan renderoida eri laitekehyksillä ohittamalla frameId. Näin käsittelet App Store vs Google Play -jaon. Sama malliasettelu, sama kuvakaappaus, eri kehys.

Nopeusrajoitukset ja kiintiöt

Render API: 5 pyyntöä per 60 sekuntia
Tilan pollaus: 60 pyyntöä per 60 sekuntia
Päivittäiset renderoinnit: 100 päivässä Pro-tasolla
Kuvien lataukset: enintään 200 tiedostoa per pyyntö, 10 Mt kukin

YAML-validointi

YAML-jäsennin on tarkoituksellisesti tiukka: ei ankkureita, ei aliaksia, ei mukautettuja tageja, enintään 1 Mt. Jos jokin on pielessä, virheviesti kertoo tarkalleen mitä — väärä kentän nimi, ei-vaihdettava kenttä, virheellinen UUID-muoto, URL, joka osoittaa yksityiseen IP-alueeseen. Se on suunniteltu epäonnistumaan nopeasti ja selvästi, mikä on tärkeää, kun debuggaat CI-putkea klo 23.