# Apps Script deployen als webapp of add-on

Apps Script deployen als webapp of add-on is de stap waarmee je script van een persoonlijk hulpmiddel naar een gedeelde toepassing gaat. Een webapp geeft een URL die mensen of systemen aanroepen; een add-on breidt Sheets, Docs of Gmail uit voor je hele organisatie. In dit artikel leer je het verschil, de instellingen en hoe je veilig versies beheert.

[[TOC]]

## Twee soorten deployments

Er zijn twee hoofdvormen. Een webapp publiceert je script op een URL: bezoekers krijgen een HTML-pagina (via `doGet`) of systemen sturen data (via `doPost`). Een add-on (editor-add-on of Workspace-add-on) integreert je script in de interface van een Google-app, zodat collega's het via een zijpaneel of menu gebruiken. Daarnaast kun je een script publiceren als API-executable of als bibliotheek.

:::info title="Vier implementatietypes"
In het menu Implementeren kies je het type: Webapp, Add-on, API-executable of Bibliotheek. Elk type heeft eigen instellingen en een eigen manifest in `appsscript.json`. De volledige uitleg staat op developers.google.com/apps-script/concepts/deployments.
:::

## Een webapp deployen

Een webapp heeft een `doGet` of `doPost` nodig. Daarna implementeer je hem met de juiste toegangsinstellingen:

```javascript
function doGet() {
  return HtmlService.createHtmlOutput('<h1>Hallo vanuit mijn webapp</h1>');
}
```

:::howto title="Een webapp implementeren"
1. Schrijf een `doGet` die HTML teruggeeft, of een `doPost` voor data.
2. Klik op **Implementeren**, dan **Nieuwe implementatie** en kies het type **Webapp**.
3. Stel **Uitvoeren als** in: jezelf of de gebruiker die de app opent.
4. Stel **Wie heeft toegang** in: alleen jij, je organisatie, iedereen met een Google-account, of iedereen.
5. Klik op **Implementeren** en deel of gebruik de webapp-URL.
:::

## Uitvoeren als: jij of de gebruiker

Een cruciale keuze is wie het script uitvoert. Bij **Uitvoeren als mijzelf** draait het script altijd met jouw rechten, ook als iemand anders het opent. Dat is handig als je wilt dat iedereen bij jouw spreadsheet kan, maar het betekent ook dat acties op jouw naam gebeuren. Bij **Uitvoeren als de gebruiker** draait het met de rechten van de bezoeker, die dan zelf toegang tot de data moet hebben.

:::danger title="Iedereen plus jouw rechten is gevaarlijk"
Zet je een webapp op **Uitvoeren als mijzelf** en **Toegang voor iedereen**, dan kan elke bezoeker acties uitvoeren met jouw rechten en bij jouw data. Dat is een serieus beveiligingsrisico. Beperk de toegang waar mogelijk tot je organisatie, en valideer in code altijd wie de aanroep doet voordat je gevoelige acties uitvoert.
:::

## Versies beheren

Een implementatie wijst naar een specifieke versie van je code. Wijzig je je script, dan verandert de gedeployde webapp niet vanzelf: je moet de implementatie bijwerken naar een nieuwe versie. Zo blijft productie stabiel terwijl je doorontwikkelt. Let op: pas je een bestaande implementatie aan via **Implementaties beheren**, dan houd je dezelfde URL. Maak je telkens een nieuwe implementatie, dan krijg je elke keer een nieuwe URL en blijft de oude actief.

:::tip title="Splits test en productie"
Gebruik een vaste implementatie voor productie en een aparte testimplementatie voor ontwikkeling. De testimplementatie wijst naar **Head** (je laatste code), de productie-implementatie naar een specifieke, geteste versie. Zo test je nieuwe code zonder je gebruikers te raken, en promoot je pas naar productie als het werkt.
:::

## Welk type kies je?

| Type | Wat het is | Kies dit als |
| --- | --- | --- |
| Webapp | Draait op een URL, ideaal voor formulieren, dashboards, webhooks en kleine interne tools | Je een eigen pagina of een endpoint nodig hebt |
| Add-on | Integreert in Sheets, Docs, Slides, Forms of Gmail via een zijpaneel | Je functionaliteit binnen een bestaande Google-app aan een team wilt aanbieden |
| Bibliotheek | Herbruikbare code die je deelt met andere scripts | Meerdere projecten dezelfde functies nodig hebben |

## Een add-on uitrollen in je organisatie

Een add-on publiceer je via de Google Workspace Marketplace SDK. Voor een interne tool kies je bij het publiceren voor **privé** (domeinspecifiek): de listing is dan alleen vindbaar en installeerbaar voor mensen binnen jouw Workspace-organisatie, en Google reviewt de app niet vooraf. Een beheerder kan de add-on vervolgens domeinbreed uitrollen.

:::warn title="Zichtbaarheid ligt vast na publicatie"
De keuze tussen privé en openbaar leg je vast tijdens publicatie en kun je daarna niet meer wijzigen. Bepaal dus vooraf welke zichtbaarheid je add-on nodig heeft voordat je begint.
:::

:::faq
### Waarom zie ik mijn codewijziging niet in de webapp?
Omdat de implementatie naar een eerdere versie wijst. Werk de implementatie bij naar een nieuwe versie via Implementaties beheren. Een testimplementatie die naar Head wijst toont je laatste code wel direct.

### Wat betekent Uitvoeren als mijzelf?
Het script draait met jouw rechten, ongeacht wie het opent. Dat is handig voor gedeelde data, maar wees voorzichtig met de toegangsinstelling: combineer dit niet met toegang voor iedereen zonder eigen validatie in je code.

### Hoe publiceer ik een add-on voor mijn hele organisatie?
Via de Google Workspace Marketplace SDK publiceer je de add-on privé voor je domein. De beheerder kan die daarna uitrollen naar gebruikers in de organisatie.

### Kan ik een implementatie weer intrekken?
Ja. Via Implementaties beheren archiveer of verwijder je een implementatie, waarna de bijbehorende URL niet meer werkt.

### Wat is het verschil tussen Head en een versie?
Head is altijd je laatste, niet-vastgezette code en is bedoeld voor testen. Een versie is een vastgelegde momentopname; daar wijs je je productie-implementatie naar, zodat die niet meebeweegt met elke wijziging.
:::

## Volgende stap

Met deployments deel je je werk breed. Voor webhooks specifiek lees je [[apps-script-webhook|webhooks ontvangen en verwerken]], en voor een professionele ontwikkelworkflow [[apps-script-clasp|clasp gebruiken]].