Sanity CMS -opas: Näin julkaisemme sisältöä 10 kielellä

Sanity CMS -opas: Näin julkaisemme sisältöä 10 kielellä

Olemme julkaissut yli 400 sisältöpalaa 4 verkkosivustolla ja 10 kielellä Sanity CMS:n kautta. Tässä on tiivistelmä oppimistamme kokemuksista, skeemien suunnittelusta automatisoituun monikieliseen julkaisemiseen.

Sanity CMS on headless-sisältöalusta, joka rakentuu strukturoidun sisällön, reaaliaikaisen Content Laken ja muokattavan React-pohjaisen editorin, Sanity Studion, ympärille. Se käyttää GROQ:ta kyselyihin, Portable Textiä rikkaaseen sisältöön ja schema-as-code -lähestymistapaa sisällön mallintamiseen. Tämä opas kattaa asennuksen, skeemien suunnittelun, GROQ:n, Portable Textin, monikielisen arkkitehtuurin ja hinnoittelun.

Mikä on Sanity CMS?

Sanity on strukturoitu sisältöalusta, jota Sanity.io:n tiimi kutsuu ”sisällön käyttöjärjestelmäksi”. Toisin kuin perinteiset CMS-järjestelmät, jotka tallentavat HTML-lohkot tietokantaan, Sanity tallentaa jokaisen sisältöpalaan strukturoituna JSON-muodossa hallinnoidussa taustajärjestelmässä nimeltä Content Lake. Voit kysyä sitä GROQ:lla tai GraphQLilla ja renderöidä sisällön missä tahansa frontendissä: Next.js, React Native, Svelte, mobiilisovellus, CLI-työkalu – mikä vain.

Sitä käyttävät yritykset kattavat koko skaalan. Nike, Figma, Puma ja Cloudflare käyttävät Sanityä enterprise-tasolla. Startupit käyttävät sitä, koska ilmainen taso on aidosti käyttökelpoinen (lisää hinnoittelusta myöhemmin). Me käytämme sitä, mikään muu ei antanut meille tarvittavaa joustavuutta täysin automatisoidun 10 kielen julkaisuputken rakentamiseen.

Content Laken arkkitehtuuri

Content Lake on Sanityn hallinnoima taustajärjestelmä. Ajattele sitä isännöitynä dokumenttivarastona, joka synkronoituu reaaliajassa kaikkien yhdistettyjen asiakkaiden kesken. Kun editori muuttaa kappaletta Sanity Studiossa, toinen editori näkee muutoksen välittömästi – ei tallennuspainiketta, ei yhdistämisristiriitoja, ei tietokantamigraatioita.

Kulissien takana dokumentit tallennetaan strukturoituna JSONina tyypitetyillä kentillä. Jokainen muutos seurataan transaktiologin kautta, joten saat täydellisen versionhistorian oletusarvoisesti. Reaaliaikainen synkronointi käyttää listener-pohjaista arkkitehtuuria (kuvattu Sanityn GitHub-arkkitehtuuridokumenteissa), joka pushaa muutokset kaikille tilaajille RxJS-observablen kautta.

Mikä tekee tästä erilaisen verrattuna esimerkiksi PostgreSQL-tietokantaan REST API:n kanssa? Content Lake käsittelee sisällön mallinnuksen, pääsynvalvonnan, CDN-välimuistituksen, kuvamuunnokset ja reaaliaikaisen yhteistyön yhtenä hallinnoituna palveluna. Et aja migraatioita. Et hallinnoi replikoita. Määrittelet vain skeemat ja kysyt sisältöä.

Sanity Studio: Muokattava editorisi

Sanity Studio on avoimen lähdekoodin React-sovellus, joka toimii muokkausliittymänäsi. Se ei ole isännöity ylläpitopaneeli, vaan React-sovellus, joka sijaitsee koodipohjassasi. Voit mukauttaa sen jokaista aspektia: mukautettuja syötekomponentteja, ehdollisia kenttiä, dokumenttitoimintoja, rakennerakentajan malleja ja lisäosia.

Reaaliaikainen yhteistyö on sisäänrakennettu. Useat editorit voivat työskennellä samassa dokumentissa samanaikaisesti läsnäoloindikaattoreiden ja live-päivitysten kanssa. Jos olet käyttänyt Google Docsia, kokemus on samanlainen: näet muiden kursorit ja muutokset reaaliajassa.

Me julkaisemme Studiomme komennolla npx sanity deploy, joka isännöi sen Sanityn CDN:ssä omalla aliverkkotunnuksella. Voit myös isännöidä sitä itse, koska se on vain React-sovellus. Sijoitimme Sanityn korkealle headless CMS -vertailussamme pitkälti Studion joustavuuden ansiosta.

Kuinka asentaa Sanity-projekti

Asentaaksesi Sanity CMS:n, asenna CLI komennolla npm create sanity@latest, valitse projektimalli, määritä skeemitiedostosi ja suorita npx sanity dev käynnistääksesi Studion paikallisesti. Koko prosessi vie alle 5 minuuttia.

Esivaatimukset ja asennus

Tarvitset Node.js 18+ ja npm:n (tai pnpm:n). Siinä kaikki. Suorita init-komento:

npm create sanity@latest

# You'll be prompted for:
# - Login method (Google, GitHub, email)
# - Project name
# - Dataset name (default: "production")
# - Project template (blog, ecommerce, clean)
# - TypeScript? (recommended: yes)

CLI luo projektirungon, jossa on kaikki tarvittava. Tässä miltä projektirakenne näyttää:

Projektirakenteen selitys

my-sanity-project/
├── schemas/              # Your content schemas (this is where you'll spend time)
│   ├── index.ts          # Schema registry -- imports and exports all types
│   ├── post.ts           # Document type definitions
│   └── blockContent.ts   # Rich text / Portable Text config
├── sanity.config.ts      # Main config -- plugins, Studio structure, dataset
├── sanity.cli.ts         # CLI config -- project ID, dataset
├── package.json
└── tsconfig.json

Tiedosto sanity.config.ts on entry pointisi. Tässä on minimaalinen versio:

// sanity.config.ts
import { defineConfig } from 'sanity'
import { structureTool } from 'sanity/structure'
import { visionTool } from '@sanity/vision'
import { schemaTypes } from './schemas'

export default defineConfig({
  name: 'default',
  title: 'My Blog',
  projectId: 'your-project-id',
  dataset: 'production',
  plugins: [structureTool(), visionTool()],
  schema: { types: schemaTypes },
})

visionTool()-lisäosa antaa sinulle GROQ-leikkikentän Studion sisällä – käytät sitä jatkuvasti kehityksen aikana.

Studion julkaiseminen

Käynnistä paikallisesti komennolla npx sanity dev (ajaa osoitteessa localhost:3333). Kun olet valmis jakamaan sen editoreille, julkaise se Sanityn CDN:ään:

npx sanity deploy
# Prompts for a hostname, e.g., "my-blog"
# Deploys to https://my-blog.sanity.studio

Pro-vinkki: suorita npx sanity@latest schema deploy jokaisen skeemimuutoksen jälkeen. Tämä lataa skeemasi Sanityn APIin, mikä mahdollistaa ominaisuudet kuten GraphQL API:n ja skeemitietoisen työkalutuen (mukaan lukien MCP-palvelin, jota käsittelemme myöhemmin).

Skeemien suunnittelu Sanity CMS:ssä

Sanityn skeemat määritellään JavaScript- tai TypeScript-objekteina koodipohjassasi. Jokainen skeema määrittää dokumenttityypin kentillä, validointisäännöillä ja mukautetuilla syötekomponenteilla. Muutokset skeemeihin ovat välittömiä, tietokantamigraatioita ei tarvita. Tämä on ”schema-as-code” -lähestymistapa, ja se oli se tekijä, joka vakuutti meidät Sanitystä Contentfulin sijaan.

Kenttätyypit ja validointi

Sanityssa on runsas valikoima kenttätyyppejä. Tässä ovat ne, joita käytämme eniten:

Jokainen kenttä tukee validointia validation-callbackin kautta. Voit pakottaa vaaditut kentät, min/max-arvot, regex-mallit ja mukautetut säännöt:

defineField({
  name: 'seoDescription',
  title: 'Meta Description',
  type: 'string',
  validation: (Rule) =>
    Rule.required()
      .min(145)
      .max(160)
      .warning('Meta description should be 145-160 characters'),
})

Mukautetut lohkotyypit (Tuotantoesimerkkimme)

Tässä kohtaa Sanity muuttuu mielenkiintoiseksi, ja missä 0 kuudesta kilpailevasta oppaasta näyttää mitään koodia. Tuotantoskeemassamme määrittelemme viisi mukautettua lohkotyyppiä body-arrayn sisälle: block (standarditeksti), table, codeBlock, chartBlock ja inlineImage.

Tässä on codeBlock-määritelmämme:

// schemas/objects/codeBlock.ts
import { defineType } from 'sanity'

export const codeBlock = defineType({
  name: 'codeBlock',
  title: 'Code Block',
  type: 'object',
  fields: [
    {
      name: 'language',
      title: 'Language',
      type: 'string',
      options: {
        list: [
          { title: 'JavaScript', value: 'javascript' },
          { title: 'TypeScript', value: 'typescript' },
          { title: 'Python', value: 'python' },
          { title: 'Bash', value: 'bash' },
          { title: 'JSON', value: 'json' },
          { title: 'GROQ', value: 'groq' },
        ],
      },
    },
    {
      name: 'code',
      title: 'Code',
      type: 'text',
    },
  ],
})

Ja näin body-kenttä viittaa kaikkiin mukautettuihin tyyppeihimme yhdessä:

// schemas/fields/body.ts
defineField({
  name: 'body',
  title: 'Body',
  type: 'array',
  of: [
    { type: 'block' },         // Standard Portable Text (paragraphs, headings, lists)
    { type: 'table' },         // @sanity/table plugin
    { type: 'codeBlock' },     // Our custom code block
    { type: 'chartBlock' },    // Data visualization (bar, line, pie)
    { type: 'inlineImage' },   // Images with alt text and captions
  ],
})

Tämä antaa editoreillemme rikkaan sisältötyökalupakin pitäen samalla jokaisen elementin tyypitettynä ja kyseltävissä. chartBlock ei ole vain läpinäkymätön HTML-upotus, vaan strukturoitua dataa, jossa on chartType, title, dataPoints ja dataLabels -kentät. Sillä on väliä, kun yrität renderöidä samaa sisältöä webissä, sähköpostissa ja mobiilissa.

Skeemien organisoinnin best practiset

Pidä skeemat modulaarisina. Jaomme ne tiedostoihin tyypeittäin: schemas/documents/post.ts, schemas/objects/codeBlock.ts, schemas/objects/chartBlock.ts. Tuo ne kaikki tiedostossa schemas/index.ts:

// schemas/index.ts
import { post } from './documents/post'
import { codeBlock } from './objects/codeBlock'
import { chartBlock } from './objects/chartBlock'
import { inlineImage } from './objects/inlineImage'

export const schemaTypes = [post, codeBlock, chartBlock, inlineImage]

Keskeinen oivallus, jonka saimme työskennellessämme strukturoidun sisällön kanssa: skeemasi ON sisältömallisi. Jos ajattelet sitä kontekstisuunnitteluna sisältötiimillesi, teet parempia suunnittelupäätöksiä. Jokaisen lisäämäsi kentän tulisi palvella jotakin tarkoitusta, joko editoreita, renderöintiä tai kyselyitä varten.

GROQ: Sanityn kyselykieli

GROQ (Graph-Relational Object Queries) on Sanityn avoimen lähdekoodin kyselykieli JSON-dokumenttien suodattamiseen, liittämiseen ja projisoimiseen. Perussyntaksi on *[suodatin]{projektio}, valitse kaikki suodatinta vastaavat dokumentit ja muotoile tuloste. Se on tiiviimpi kuin GraphQL Sanity-specificeissä kyselyissä ja kokemuksemme mukaan nopeampi oppia.

Peruskyselyt: Suodata ja projektoi

Yksinkertaisin kysely hakee kaikki tietyn tyyppiset dokumentit:

// Fetch all posts -- just title and slug
*[_type == "post"]{
  title,
  "slug": slug.current
}

// Filter by language, expand author reference
*[_type == "post" && language == "en"]{
  title,
  "slug": slug.current,
  "authorName": author->name,
  "authorImage": author->image,
  "categoryTitle": category->title,
  publishedAt
}

Operaattori -> seuraa viitteitä. author->name tarkoittaa ”seuraa author-viitettä ja palauta name-kenttä”. Ei erillisiä kyselyjä, ei N+1-ongelmia, ei JOINeja – kaikki yhdessä lausekkeessa.

Liitokset, järjestys ja sivutus

Blogiemme etusivuja varten tarvitsemme järjestetyt, sivutetut artikkelit laajennetuilla viitteillä:

// Paginated posts with full metadata
*[_type == "post" && language == "en"] | order(publishedAt desc) [0...10] {
  title,
  "slug": slug.current,
  excerpt,
  publishedAt,
  readTime,
  "author": author->{name, image},
  "category": category->{title, "slug": slug.current},
  "coverImage": coverImage{
    "src": asset->url,
    alt
  }
}

[0...10] antaa ensimmäiset 10 tulosta (0-indeksöity, eksklusiivinen loppu). | order(publishedAt desc) lajittelee uusimmat ensin. Projektio muotoilee tulosteen sisältämään täsmälleen sen, mitä frontendisi tarvitsee, ei mitään ylimääräistä.

Voit testata kaikkia näitä kyselyitä interaktiivisesti käyttämällä Vision-lisäosaa Sanity Studion sisällä. Se on korvaamaton kehityksen aikana. Lisää malleja löydät GROQ-huijarilistasta.

GROQ vs GraphQL

Sanity tukee sekä GROQ:ta että GraphQLia. Milloin kannattaa käyttää kumpaa?

GROQ on Sanityn natiivi kieli. Se käsittelee liitokset, projektiot ja lasketut kentät yhdessä kyselymerkkijonossa. Se on se, mille Content Lake on optimoitu.

GraphQL on saatavilla, kun olet julkaissut skeemasi (npx sanity@latest schema deploy). Käytä sitä, kun tarvitset standardoituja työkaluja, esimerkiksi jos frontendisi käyttää jo Apollo Clientia tai jos tiimisi tuntee GraphQL:n mutta ei GROQ:ta.

Käytämme yksinomaan GROQ:ta. Se on ilmaisevampi Sanity-datalle, ja Vision-lisäosa tekee kyselyiden debuggaamisesta triviaalia.

Portable Text: Rikas sisältö oikein tehtynä

Portable Text on Sanityn spesifikaatio strukturoidulle rikkaalle tekstille. Sisällön tallentamisen HTML-merkkijonoina sijaan se tallentaa tyypitettyjen lohkojen arrayn – kappaleet, otsikot, kuvat, koodinpätkät, taulukot – kukin JSON-objektina. Tämä tekee sisällöstä renderöitävän missä tahansa frameworkissa, alustalla tai muodossa.

Datrakenne

Tässä miltä kappale ja koodilohko näyttävät Portable Text JSONina:

[
  {
    "_type": "block",
    "_key": "a1b2c3",
    "style": "normal",
    "markDefs": [],
    "children": [
      {
        "_type": "span",
        "_key": "d4e5f6",
        "text": "Here's an example of our pipeline config:",
        "marks": []
      }
    ]
  },
  {
    "_type": "codeBlock",
    "_key": "g7h8i9",
    "language": "typescript",
    "code": "export default defineConfig({ ... })"
  }
]

Jokaisella lohkolla on _type ja _key. Standardit tekstilohkot käyttävät "block"-tyyppiä children-spaneilla (jotka tukevat merkkejä kuten lihavoitu, kursiivi ja linkit). Mukautetut lohkot, kuten codeBlock, chartBlock, table ja inlineImage, käyttävät omaa _type-arvoaan ja kantavat strukturoituja kenttiä.

Miksi tämä on tärkeää? Koska HTML on renderöintimuoto, ei tallennusmuoto. Jos tallennat <h2>Otsikko</h2><p>Jotain <strong>tekstiä</strong></p> tietokantaasi, olet lukkiutunut web-renderöintiin. Et voi puhtaasti extractoida sitä mobiilisovellusta, uutiskirjettä, PDF:ää tai tekoälyagentin kontekstiikkunaa varten. Portable Text erottaa sisällön esitystavasta. Portable Text -spesifikaatio on avointa lähdekoodia, se ei ole Sanity-lock-in.

Mukautetut lohkot tuotannossa

Putkemme muuntaa Markdownin Portable Textiksi Python-skriptillä (scripts/md_to_portable_text.py). Muunnin käsittelee standardilohkot plus neljä mukautettua tyyppiämme:

• table, käyttää @sanity/table-lisäosan skeemaa. Rivit ja solut tallennettuina strukturoituna datana.
• codeBlock, kieli ja koodi erillisinä kenttinä, mahdollistaen syntaksikorostuksen renderöinnissä.
• chartBlock, kaavion tyyppi, otsikko, akselin nimikkeet, sarjojen nimet ja datapisteet strukturoituna JSONina. Frontend renderöi nämä Chart.js:llä.
• inlineImage, alt-teksti, lähde ja valinnainen kuvateksti erillisinä kenttinä.

Tämä rakenne tarkoittaa, että voimme kysyä kaikkia koodiesimerkkejä blogistamme (*[body[]._type == "codeBlock"]), löytää artikkeleita, joissa on kaavioita, tai extractoida kaikki kuvat, joista puuttuu alt-teksti, kaikki GROQ:n kautta.

Portable Textin renderöinti

Frontendissä käytä @portabletext/react (tai Svelte/Vue-vastaavuuksia). Rekisteröi mukautetut komponentit kullekin lohkotyypille:

import { PortableText } from '@portabletext/react'

const components = {
  types: {
    codeBlock: ({ value }) => (
      <pre className={`language-${value.language}`}>
        <code>{value.code}</code>
      </pre>
    ),
    chartBlock: ({ value }) => <Chart data={value} />,
    inlineImage: ({ value }) => (
      <figure>
        <img src={value.src} alt={value.alt} />
        {value.caption && <figcaption>{value.caption}</figcaption>}
      </figure>
    ),
  },
}

// In your component:
<PortableText value={post.body} components={components} />

Siinä on koko renderöintiputki. PortableText-komponentti käsittelee standardilohkot (kappaleet, otsikot, listat, merkit) automaattisesti. Määrittelet mukautetut komponentit vain omille tyypeillesi.

Monikielinen sisältö Sanity CMS:n kanssa

Sanity tukee monikielistä sisältöä dokumenttitason lokalisoinnilla (erilliset dokumentit per kieli, linkitetty kanonisen viitteen kautta) tai kenttätason lokalisoinnilla (käännetyt kentät yhden dokumentin sisällä). Dokumenttitaso toimii paremmin SEO:hun ja laajamittaiseen julkaisemiseen, sitä käytämme 10 kielen putkessamme.

Dokumenttitason vs. kenttätason lokalisointi

Valitsimme dokumenttitason lokalisoinnin, koska jokainen käännös saa oman sluginsa, oman URL:nsa ja oman metadatansa. Artikkeli Supabase vs Firebase turkinkielinen versio saa slugiksi supabase-firebase-karsilastirma, aitoa turkkia, ei URL-parametrihakkerointia.

10 kielen putkiarkkitehtuurimme

Näin automatisoitu putkemme toimii: kirjoitamme artikkelin englanniksi, käännämme sen 9 muulle kielelle (saksa, ranska, hollanti, espanja, turkki, italia, ruotsi, norja, arabia). Jokainen käännös käy läpi Markdown-muunnoksen, Portable Text -generoinnin ja Sanity API -julkaisun.

Arkkitehtuuri näyttää tältä:

1. Kirjoitus, Englanninkielinen Markdown YAML-frontmatterilla
2. Käännös, AI-käännös 9 kielelle (varmistettu täydellisyyden ja diakriittisten merkkien osalta)
3. Muunnos, Python-skripti muuntaa jokaisen .md-tiedoston Portable Text JSONiksi
4. Julkaisu, API-kutsut Sanityyn: luo dokumentti, lataa kuvat, patchaa viitteet

Jokaisella dokumentilla on language-kenttä ja canonicalPost-viite, joka osoittaa alkuperäiseen englanninkieliseen versioon. Tässä on GROQ-kysely artikkelin ja kaikkien sen käännösten hakemiseen:

// Fetch a post and all its translations
*[_type == "post" && slug.current == "sanity-cms-guide" && language == "en"][0]{
  title,
  language,
  "translations": *[
    _type == "post" &&
    canonicalPost._ref == ^._id
  ]{
    title,
    language,
    "slug": slug.current
  }
}

Skeemipuoli on suoraviivainen, language-kenttä enumilla tuetuista kielistä:

defineField({
  name: 'language',
  title: 'Language',
  type: 'string',
  options: {
    list: [
      { title: 'English', value: 'en' },
      { title: 'German', value: 'de' },
      { title: 'French', value: 'fr' },
      { title: 'Dutch', value: 'nl' },
      { title: 'Spanish', value: 'es' },
      { title: 'Turkish', value: 'tr' },
      { title: 'Italian', value: 'it' },
      { title: 'Swedish', value: 'sv' },
      { title: 'Norwegian', value: 'no' },
      { title: 'Arabic', value: 'ar' },
    ],
  },
  validation: (Rule) => Rule.required(),
})

Yksi sudenkuoppa, jonka opimme kantapään kautta: julkaise englanninkielinen dokumentti ensin, sitten patchaa canonicalPost-viitteet käännöksissä käyttämällä julkaistua dokumentti-ID:tä, ei drafts.-etuliitettä. Sanity käsittelee luonnos- ja julkaistuja dokumentteja sisäisesti erillisinä entiteetteinä.

Lisätietoja siitä, miten tämä putki liittyy Model Context Protocoliin, löytyy seuraavasta osiosta.

Sanityn tekoälyominaisuudet: MCP, Canvas ja Agent Context

Sanity positionoituu tekoälyaikakauden sisältökäyttöjärjestelmäksi. Keskeisiä tekoälyominaisuuksia ovat MCP-palvelin tekoälyagenteille sisällön lukemiseen ja kirjoittamiseen, Canvas tekoälyavusteiseen muokkaukseen Studiossa ja Agent Context tuotantotason tekoälyagenteille strukturoidun sisällön kyselyyn skeemitietoisuudella.

MCP-palvelimen integraatio

Sanity MCP -palvelin antaa tekoälyagenteille – Claude Code, Cursor, Windsurf ja muut – mahdollisuuden olla vuorovaikutuksessa Sanity-työtilasi kanssa ohjelmallisesti. Agentit voivat lukea skeemejä, suorittaa GROQ-kyselyjä, luoda dokumentteja ja hallita sisältöä ilman mukautettuja API-wrappereita.

Käytämme Sanity MCP -palvelinta päivittäin sisältöputkessamme. Tekoälyagenttimme kysyvät skeemaa ymmärtääkseen dokumenttirakenteen, hakevat olemassa olevia postauksia löytääkseen sisäisen linkitysmahdollisuuksia ja julkaisevat uusia dokumentteja. MCP-protokolla antaa agenteille skeemitietoisuuden – ne tietävät, mitä kenttiä on olemassa, mitä tyyppejä ne odottavat ja mitä validointisääntöjä sovelletaan. Jos rakennat tekoälyagentteja liiketoiminnan workflowihin, tämä on tehokas malli.

Agent Context tuotantotason tekoälylle

Agent Context on erillinen ominaisuus tuotantotason tekoälyintegraatioita varten. Toisin kuin MCP-palvelin (joka on suunniteltu kehittäjätyökaluille), Agent Context tarjoaa read-only, rajatun pääsyn tekoälyagenteille, jotka tarvitsevat kysellä sisältöäsi runtime-aikana – ajattele chatbotteja, suositusmoottoreita tai sisällön personointijärjestelmiä.

Ero on merkittävä: MCP on build-time ja editoriaalisten workflowjen varalle (skeemitietoiset kehitystyökalut), kun taas Agent Context on runtime-sisältöaccessia varten asianmukaisella autentikoinnilla ja rate limitingillä.

Sanityn strukturoitu sisältö antaa sille todellisen edun tässä. WordPress-sivusto tallentaa sisällön HTML-blobeina, tekoälyagentin on parsittava HTML ymmärtääkseen sisällön. Sanity tallentaa tyypitetyt JSON-dokumentit määritellyillä skeemeilla. Agentti voi kysyä *[_type == "product" && category == "electronics"]{name, price, features} ja saada takaisin puhdasta, strukturoitua dataa. Ei scrapingia, ei parsimista, ei arvailua.

Miten käytämme Sanityä Techsyllä

Tämä ei ole hypoteettinen osio. Pyöritämme Sanity CMS:ää 4 tuotantosivustolla, julkaisemme 10 kielellä automatisoidulla putkella, jonka rakensimme viime vuoden aikana. Tässä on arkkitehtuuri.

Sisältöputkiarkkitehtuurimme

Putki kulkee tutkimuksesta julkaistuun postaukseen kaikilla 10 kielellä:

1. Tutkimus, avainsana-analyysi, kilpailijoiden aukkojen tunnistaminen, SERP-mallit
2. Brief, strukturoitu kirjoitusspesifikaatio osio-ohjeineen, sanamäärineen, sisäisine linkkeineen
3. Kirjoitus, tuota englanninkielinen Markdown YAML-frontmatterilla
4. Muunnos, Python-skripti muuntaa Markdownin Portable Text JSONiksi 5 mukautetulla lohkotyypillämme
5. Julkaisu, API-kutsut Sanityyn: createOrReplace dokumentti, lataa kuvat Sanity CDN:ään, patchaa kirjoittaja/kategoria-viitteet
6. Käännös, AI-käännös 9 kielelle, varmistettu täydellisyyden osalta
7. Julkaise käännökset, sama muunnos/julkaisu-flow per kieli, canonicalPost-viite patchattuna englanninkieliseen alkuperäiseen

Mukautettu skeema tukee block, table, codeBlock, chartBlock ja inlineImage -tyyppejä, kaikki määriteltyinä tuotanto-Sanity-skeemaobjekteina validointisääntöineen. Niiden tekoälytyökalujen joukossa startupeille, joita olemme testanneet, tämä Sanity-pohjainen putki on ollut luotettavin strukturoidulle sisällölle skaalattuna.

Oppitunnit 400+ julkaistusta palasta

Muutama asia, jotka olisimme halunneet jonkun kertovan meille:

Viitteiden patchausjärjestys on tärkeä. Sanityn viitteet eivät voi osoittaa dokumentteihin, joita ei ole vielä olemassa. Julkaise englanninkielinen postaus ensin, luo sitten käännökset canonicalPost-viitteellä, joka osoittaa englanninkielisen dokumentin julkaistuun ID:hen. Rikoimme tämän useita kertoja alussa.

Skeemien julkaisu on workspace-kohtaista. Jos ajat useita Sanity-projekteja (me ajamme 4), sinun on julkaistava skeemit kuhunkin erikseen: npx sanity@latest schema deploy per projektikonfiguraatio.

Ilmainen taso on todellinen. Ajaimme kaksi neljästä sivustostamme ilmaisella planilla kuukausia. 20 käyttäjää, 500 000 API-pyyntöä/kuukausi, 100 000 CDN-pyyntöä – se riittää oikeaan tuotantosivustoon, ei vain leikkiprojektiin.

Portable Text -muunnos on pullonkaula. Markdownista Portable Textiin muuntaminen ei ole triviaalia. Sisäkkäiset listat, taulukot blockquotejen sisällä, koodilohkot erikoismerkkeineen – edge caseja kaikkialla. Olemme iteroineet muunninskriptiämme kuukausia.

Tarvitsetko apua Sanityn asentamisessa projektiisi? Olemme rakentaneet monikielisiä sisältöputkia 4 tuotantosivustolle. Pyydä ilmainen konsultointi

Sanity CMS:n hinnoittelun erittely

Sanity tarjoaa kolme plania: Free (20 käyttäjää, 500 000 API-pyyntöä/kuukausi), Growth (15 $/käyttäjä/kuukausi edistyneillä rooleilla ja ajoitetuilla luonnoksilla) ja Enterprise (räätälöity hinta SLA:lla ja compliance-ominaisuuksilla). Ilmainen taso on anteliain headless CMS -markkinoilla.

Ilmaisella tasolla ajamme kaksi sivustoamme rajoja rikkomatta. Growth-plan hintaan 15 $/käyttäjä/kuukausi lisäsi roolipohjaisen pääsyn (tärkeää, kun meillä oli ei-teknisiä editoreita) ja ajoitetun julkaisun. Katsojat ovat ilmaisia Growth-planiissa, mikä on mukava lisä – ettei sinua rangaista sidosryhmien lukuoikeuksien antamisesta.

Miten tämä vertautuu kilpailijoihin?

Sanityn 20 käyttäjän ilmainen taso on poikkeuksellinen. Contentful rajoittaa sinut 1 käyttäjään ilmaisella tasolla ja hyppää 300 $/kuukausi Team-planissa. Jos olet startup tai pieni tiimi, Sanityn ilmainen plani antaa sinun ajaa todellisia tuotantokuormia kuluttamatta mitään.

Sanity tarjoaa myös startup-ohjelman, joka antaa kvalifioituville startupeille vuoden ilmaisen Growth-accessin. Kannattaa hakea, jos kvalifioidut.

Usein kysytyt kysymykset

Mikä on Sanity CMS ja miten se toimii?

Sanity CMS on headless-sisältöalusta, joka tallentaa strukturoidut JSON-dokumentit hallinnoituun taustajärjestelmään nimeltä Content Lake. Muokkaat sisältöä Sanity Studion kautta (muokattava React-sovellus), kysyt sitä GROQ:lla tai GraphQLilla ja renderöit sen missä tahansa frontend-frameworkissa. Sisältö synkronoituu reaaliajassa kaikkien yhdistettyjen asiakkaiden kesken.

Onko Sanity CMS ilmainen?

Kyllä. Sanityn ilmainen taso sisältää 20 käyttäjää, 500 000 API-pyyntöä kuukaudessa ja 100 000 CDN-pyyntöä – anteliain ilmainen plani headless CMS -alustojen joukossa. Growth-plan maksaa 15 $ käyttäjältä kuukaudessa ja lisää roolipohjaisen pääsyn, ajoitetun julkaisun ja korkeammat rajat. Enterprise-hinnoittelu on räätälöity.

Mikä on ero Sanityn ja Contentfulin välillä?

Sanity käyttää schema-as-code -lähestymistapaa (skeemat ovat koodipohjassasi), GROQ:ta kyselyihin ja täysin muokattavaa avoimen lähdekoodin Studiota. Contentful käyttää GUI-pohjaista sisällön mallinnusta, GraphQLia ja isännöityä editoria, jossa on vähemmän mukautusmahdollisuuksia. Sanityn ilmainen taso sisältää 20 käyttäjää verrattuna Contentfulin 1:een. Contentfulilla on suurempi lisäosamarkkinapaikka.

Onko Sanity CMS hyvä aloittelijoille?

Sanity Studio on intuitiivinen sisällön editoreille, muokkauskokemus ei vaadi teknistä osaamista. Skeemien asettaminen vaatii kuitenkin JavaScript- tai TypeScript-taitoja. Sanity tarjoaa erinomaista dokumentaatiota, projektimalleja ja aktiivista tukea tarjoavan community Slackin. Aloita komennolla npm create sanity@latest ja blogimallilla.

Voinko isännöidä Sanityä itse?

Sanity Studio on täysin itse isännöitävissä, koska se on avoimen lähdekoodin React-sovellus. Voit julkaista sen Verceliin, Netlifyyn tai mihin tahansa staattiseen hosting-palveluntarjoajaan. Content Lake -taustajärjestelmä on hallinnoitu palvelu, datakerrokselle ei ole itse isännöinti vaihtoehtoa. Tämä on kompromissi: saat nolla infrastruktuurin hallintaa, mutta ei on-premises-datakontrollia.

Minkä tyyppistä tietokantaa Sanity käyttää?

Sanityn Content Lake ei ole perinteinen SQL- tai NoSQL-tietokanta. Se on hallinnoitu dokumenttivarasto, joka tallentaa sisällön strukturoituna JSONina GROQ-kyselykerroksen päällä. Et ole vuorovaikutuksessa underlying-tietokannan kanssa suoraan, vaan Sanityn APIen kautta. Dokumenteilla on täysi versionhistoria ja reaaliaikainen synkronointi sisäänrakennettuna.

Onko Sanity CMS avointa lähdekoodia?

Sanity Studio on avointa lähdekoodia MIT-lisenssin alla – voit forkata sen, mukauttaa sitä ja isännöidä sitä itse. Content Lake -taustajärjestelmä on proprietaarinen SaaS. GROQ-kyselykielen spesifikaatio on myös avointa lähdekoodia, julkaistu GitHubissa. Portable Text -spesifikaatio on niin ikään avointa lähdekoodia, ylläpidetty osoitteessa portabletext.org.

Mikä on Portable Text Sanityssä?

Portable Text on Sanityn spesifikaatio strukturoidulle rikkaalle tekstille. Sisällön tallentamisen HTML-merkkijonoina sijaan se edustaa kappaleita, otsikoita, kuvia ja mukautettuja lohkoja tyypitettyinä JSON-objekteina arrayssä. Tämä tekee sisällöstä siirrettävän frameworkien ja alustojen välillä. Voit määritellä mukautettuja lohkotyyppejä, kuten koodinpätkiä, kaavioita ja taulukoita omilla strukturoiduilla kentillään.

Mikä on GROQ ja miten se eroaa GraphQLista?

GROQ (Graph-Relational Object Queries) on Sanityn natiivi kyselykieli. Sen syntaksi, *[suodatin]{projektio}, on tiiviimpi kuin GraphQL Sanity-datassa, ja siinä on sisäänrakennettu tuki liitoksille ->-operaattorin kautta ja lasketuille kentille. GraphQL on myös saatavilla tiimeille, jotka suosivat standardoituja työkaluja tai käyttävät jo Apollo Clientia.

Miten Sanity käsittelee monikielistä sisältöä?

Sanity tukee dokumenttitason lokalisointia (erilliset dokumentit per kieli, linkitetty kanonisilla viitteillä) ja kenttätason lokalisointia (käännetyt kentät yhden dokumentin sisällä). Dokumenttitaso on parempi SEO:hun, koska jokainen käännös saa oman URL:nsa ja metadatansa. Käytämme dokumenttitason lokalisointia julkaistaksemme 10 kielellä automatisoiduilla käännös- ja julkaisuputkilla.