mirror of
https://github.com/TheTaz25/denis.ergin.git
synced 2025-07-06 13:18:49 +00:00
feat(slides): first throw build and deploy
This commit is contained in:
Denis Ergin
parent
750bb56827
commit
63142e27ea
6 changed files with 302 additions and 0 deletions
142
src/components/slides/deployments/build.astro
Normal file
142
src/components/slides/deployments/build.astro
Normal file
|
|
@ -0,0 +1,142 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h2>Wie machen wir den Code Produktionsreif?</h2>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wir haben nun unsere erste App geschrieben. Nun wollen wir die natürlich auch "öffentlich" Verfügbar haben. Das macht ja immerhin das Internet aus...</p>
|
||||||
|
<p>Wir schauen uns nun an, welche Schritte wir unternehmen <b>sollten</b>, um von lokal zu global zu wechseln.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Der erste Schritt besteht darin, den von uns geschrieben Code zu <em>optimieren</em>.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Warum sollte ich meinen Code optimieren?</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Der <em>Rohe</em> Code den wir geschrieben haben ist, wenn wir das auf große Projekte projezieren, ineffizient.</p>
|
||||||
|
<p>Wir können den Code mittels Tools auf verschiedene Arten transformieren und effizienter gestalten.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Optimierungsmöglichkeiten:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Minification</li>
|
||||||
|
<li>Tree-Shaking</li>
|
||||||
|
<li>Bundling</li>
|
||||||
|
<li>Compatibility</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Minification</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Während der <strong>Minification</strong> wird der Code verkleinert. Dabei werden unnötige Whitespaces entfernt, und Variablennamen verkürzt.</p>
|
||||||
|
<p>Variablennamen werden so verkürzt, dass es nur noch kurze Buchstabenfolgen (a, b, c, d, usw...) sind.</p>
|
||||||
|
<p>Verkleinert das finale JavaScript deutlich und reduziert dadurch die Menge der Daten die übertragen werden müssen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Tree-Shaking</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wenn wir externe Bibliotheken und Frameworks verwenden, nutzen wir in den meisten Fällen nicht alle Features des Pakets.</p>
|
||||||
|
<p>Während des Tree-Shaking werden ungenutzte Code-Schnippsel von externen Paketen entfernt, sodass ungenutzter Code erst gar nicht ausgeliefert wird.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Bundling</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Der Übersicht wegen teilen wir unseren Code in mehrere Dateien auf.</p>
|
||||||
|
<p>Beim Bundling sollen diese zusammenhängenden JavaScript-Codeschnippsel möglichst so zusammengefasst werden, dass eine Website nur ein einziges File herunter laden muss.</p>
|
||||||
|
<p>Hier gibt es aber auch eine "Anforderung", dass solche Bundles eine bestimmte Dateigröße nicht überschreiten sollten.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Compatibility</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Das ist eher ein Relikt aus alten Zeiten, als der Support für den Internet Explorer 11 noch "sichergestellt" werden musste.</p>
|
||||||
|
<p>Tools wie Babel stellt sicher, dass moderne Features aus neueren JavaScript-Versionen auch "funktional" in alten Browsern verwendet werden können.</p>
|
||||||
|
<p>Hierzu wurden sogenannte "Polyfills" verwendet. Code der moderne Features "nachmacht", ohne dass sich der Entwickler darum kümmern muss.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Das sind die wichtigsten Dinge, die passieren müssen, damit unser JavaScript-Code auf einer realen Website "ausgrollt" werden können.</p>
|
||||||
|
<p>Jetzt stellt man sich natürlich die Frage, wie man das alles erreichen kann. Dass sind immerhin keine "kleinen" Änderungen die man an seinem Code machen muss.</p>
|
||||||
|
<p>Das gute: Wir müssen eigentlich recht wenig machen. Tools wie Bundler und Co. erledigen die schwere arbeit für uns.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Ein solches Tool verwenden wir bereits: Vite</p>
|
||||||
|
<p>Wir haben unseren vergangenen (Frontend) Projekte mit Vite aufgesetzt. Und Vite macht für uns das alles, was oben beschrieben wurde.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Um unser Frontend für die Produktion optimiert zu bauen, ist auch nur ein einzlnes Kommando notwendig: <code>npm run build</code></p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h2>Ein kurzer Blick: Möglichkeiten um eine Website zu "rendern"</h2>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Das was wir bisher gebaut haben ist eine <strong>Statische Website</strong>. Die Inhalte die Ausgespielt werden sind vollständig und es sind z.B. keine weiteren Requests notwendig, damit die Website funktionieren kann.</p>
|
||||||
|
<p>Auch meine (also diese) Website ist Statisch erzeugt: Alle Inhalte sind zum nach dem Build-Prozess vollständig uns es muss der Content nur noch auf einen Server geladen werden.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Aber was gibt es für Alternativen?</p>
|
||||||
|
<p>Im Allgemeinen gibt es 2 weitere "Möglichkeiten", wie eine Website funktionieren kann</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Single Page Applications</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Single Page Applications sind spezialisierte Websites, die größtenteils auf JavaScript basiertem Rendering aufgebaut sind (Beispiele sind: React, Vue, etc.)</p>
|
||||||
|
<p>Die Website besteht eigentlich nur aus einer kleinen HTML-Datei mit einem Script-Tag. Das Script sorgt dann dafür, dass Inhalte angezeigt werden und Interaktivität hergestellt wird.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Die angezeigten Inhalte sind dann meist dynamischer Natur. Das heißt, die Inhalte werden nachträglich über Requests aus einem Content-Server ausgespielt.</p>
|
||||||
|
<p>Konzepte wie <em>Routing</em> passiert dann auch vollständig im Browser/JavaScript. In einer Art und Weise wie es der Endnutzer nicht mehr mitbekommt.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Server Side Rendering</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Server-Side-Rendering ist eigentlich ein sehr altes Konzept:</p>
|
||||||
|
<p>Das auszuliefernde HTML-Markup wird auf einem Server dynamisch bei der Abfrage generiert.</p>
|
||||||
|
<p>Eines dieser älteren Systeme ist PHP. Moderne Alternativen sind vor allem React (NextJS oder Remix), Vue (Nuxt), Svelte oder eines der vielen anderen Systeme die es mittlerweile gibt.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Auch hier gibt es nochmals 2 "Unter"-Wege: Ein Hybrides Setup oder Klassiches Server-Side-Rendering</p>
|
||||||
|
<p>Im klassischen Server-Side-Rendering wird bei einem Seitenwechsel ein neues HTML angefordert.</p>
|
||||||
|
<p>Im Hybriden Setup (z.B. NUXT), wird der initiale Inhalt auf dem Server vor-generiert. Sobald der Inhalt beim Nutzer im Browser liegt, "übernimmt" JavaScript alle weiteren Seiten (ähnlich zu einer Single-Page-Application)</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Aber wieso das "Hin-und-Her" mit Server-Side-Rendering?</p>
|
||||||
|
<p>Wir (als Webentwickler oder Betreiber eures eigenen Shops) wollen natürlich auffindbar sein. Und das größte "Ding" um gefunden zu werden ist Google.</p>
|
||||||
|
<p>Und Google hat bestimmte Anforderungen um unsere Website besser zu "ranken". In der Webentwicklung spricht man bei diesen Anforderungen von "Search Engine Optimization".</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Im großen und ganzen wollen wir simpel gesprochen unsere Inhalte bereits bei der Ankunft beim Nutzer im HTML-Markup haben und nicht erst nachträglich durch JavaScript generieren.</p>
|
||||||
|
<p>Das Thema Search-Engine-Optimization wird nochmals tiefer in Web-Engineering II (zumindest bei mir behandelt.)</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
97
src/components/slides/deployments/docker.astro
Normal file
97
src/components/slides/deployments/docker.astro
Normal file
|
|
@ -0,0 +1,97 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h2>Docker</h2>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Was ist Docker?</strong></p>
|
||||||
|
<p>
|
||||||
|
Docker ist eine Plattform, mit der Anwendungen in isolierten Containern verpackt, verteilt und ausgeführt werden können. Diese Container enthalten alles, was die Anwendung zum Laufen braucht, wodurch sie unabhängig von der Umgebung funktioniert.
|
||||||
|
</p>
|
||||||
|
<p>-- ChatGPT</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Docker ist zunächst eines: Eine Virtualisierungs-Software. Auf ihr können also im weitesten Sinne komplette Betriebssysteme in Isolation laufen.</p>
|
||||||
|
<p>Jede Applikation eines Anwendungs-System sollte möglichst allein laufen. Abhängigkeiten zu weiteren Applikationen (zum Beispiel Datenbanken), werden in einem isolierten Container ausgeführt.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Da wir nur einen statischen Webserver laufen lassen wollen, ist dies zunächst alles recht einfach.</p>
|
||||||
|
<p>Wir bauen innerhalb eines Docker-Containers unsere Website und stellen die gebaute Website innerhalb eines "sauberen" Containers zur Verfügung.</p>
|
||||||
|
<p>Wir schauen uns den Prozess Schritt für Schritt an.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Eine Simple Konfiguration für Caddy</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wir werden als Beispiel einen Caddy Web-Server verwenden um unsere Website verfügbar zu machen.</p>
|
||||||
|
<p>Die minimale Konfiguration für Caddy umfasst lediglich 3 Zeilen, wer an ein Beispiel mit nginx interessiert ist, findet diese auf meinem GitHub.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<pre class="toml"><code data-trim data-line-numbers is:raw>
|
||||||
|
# Caddyfile
|
||||||
|
:80
|
||||||
|
|
||||||
|
root * /srv
|
||||||
|
file_server
|
||||||
|
</code></pre>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Anweisungen für den Bau eines Docker-Containers</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wir müssen nun Docker eine Bauanleitung geben, wie wir vom Development-Code, zu einer gebauten Version und dann zu einem isolierten Web-Server (Caddy) kommen.</p>
|
||||||
|
<p>Dafür legen wir die Datei "Dockerfile" im root unseres Projektes an.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wir können uns den Prozess in 2 Schritten vorstellen:</p>
|
||||||
|
<ol>
|
||||||
|
<li>Die Website bauen</li>
|
||||||
|
<li>Die gebaute Website in einem Caddy-File-Server ablegen</li>
|
||||||
|
</ol>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<pre class="docker"><code data-trim data-line-numbers>
|
||||||
|
FROM node:20-alpine AS base
|
||||||
|
|
||||||
|
COPY . /app
|
||||||
|
WORKDIR /app
|
||||||
|
|
||||||
|
FROM base AS build
|
||||||
|
RUN npm ci
|
||||||
|
RUN npm run build
|
||||||
|
</code></pre>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<pre class="docker"><code data-trim data-line-numbers>
|
||||||
|
FROM caddy:alpine
|
||||||
|
|
||||||
|
COPY ./dist/ /srv/
|
||||||
|
COPY ./Caddyfile /etc/caddy/Caddyfile
|
||||||
|
</code></pre>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wenn wir das ganze lokal ausprobieren wollen, müssen wir einfach (bei laufender Docker-Engine) folgenden Befehl in der Kommandozeile ausführen:</p>
|
||||||
|
<p><code>docker build . -t my-website</code></p>
|
||||||
|
<p>Das veranlasst Docker zum Bau der Website anhand des angegebenen Dockerfile</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Der gebaute Container ist kann dann lokal mit Docker ausgeführt werden:</p>
|
||||||
|
<p><code>docker run my-website -p 8080:80</code></p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Damit haben wir nun die Möglichkeit, die Website bei Anbietern wie Sevalla, Railway oder Fly zu deployen...</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
29
src/components/slides/deployments/file-server.astro
Normal file
29
src/components/slides/deployments/file-server.astro
Normal file
|
|
@ -0,0 +1,29 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h2>Wie wir unseren Website "hosten"</h2>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wir haben nun unseren optimierten Code bei uns liegen, wie kommt also der Inhalt von dir zu mir?</p>
|
||||||
|
<p>Nun der Code der bei uns liegt, wird nicht dort bleiben. Wir müssen die Website in einem Web-Server ablegen und diesen Server korrekt konfigurieren.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Je nach Anwendungsfall gibt es hierfür verschiedene Optionen.</p>
|
||||||
|
<p>Da wir bis jetzt nur eine statische Website erstellt haben, ist ein einfacher Webserver, der Dateien "ausliefern" kann, vollkommen ausreichend.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mögliche Server-Applikationen für einen statischen Web-Server:</p>
|
||||||
|
<ul>
|
||||||
|
<li>nginx ("Hoher" Konfigurationsaufwand, existiert bereits länger)</li>
|
||||||
|
<li>Caddy (Moderner mit weniger Konfigurationsaufwand)</li>
|
||||||
|
<li>Viele Weitere...</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Unser Ziel ist es, die fertig gebaute Website an einem für den Web-Server geeigneten Ort abzulegen, sodass die Dateien ausgeliefert werden können.</p>
|
||||||
|
<p>Wir werden unsere Arbeit aber nicht direkt auf unserem PC "laufen" lassen. Wir verwenden die Virtualisierungs-Software "Docker" um unsere Applikation lokal zu testen und später im Internet laufen zu lassen.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
13
src/components/slides/deployments/index.astro
Normal file
13
src/components/slides/deployments/index.astro
Normal file
|
|
@ -0,0 +1,13 @@
|
||||||
|
---
|
||||||
|
import Title from "./title.astro";
|
||||||
|
import Build from "./build.astro";
|
||||||
|
import FileServer from "./file-server.astro";
|
||||||
|
import Docker from "./docker.astro";
|
||||||
|
---
|
||||||
|
|
||||||
|
<div class="slides">
|
||||||
|
<Title />
|
||||||
|
<Build />
|
||||||
|
<FileServer />
|
||||||
|
<Docker />
|
||||||
|
</div>
|
||||||
4
src/components/slides/deployments/title.astro
Normal file
4
src/components/slides/deployments/title.astro
Normal file
|
|
@ -0,0 +1,4 @@
|
||||||
|
<section>
|
||||||
|
<h1>Vom Code zu "Production"</h1>
|
||||||
|
<p>Wie wir unsere Website der Öffentlichkeit zugänglich machen.</p>
|
||||||
|
</section>
|
||||||
|
|
@ -0,0 +1,17 @@
|
||||||
|
---
|
||||||
|
import Reveal from "../../../layouts/Reveal.astro";
|
||||||
|
import Slides from "../../../components/slides/deployments/index.astro";
|
||||||
|
---
|
||||||
|
|
||||||
|
<Reveal title="Build and Deploy to Production">
|
||||||
|
<Slides />
|
||||||
|
</Reveal>
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Hosting Files
|
||||||
|
NGINX
|
||||||
|
|
||||||
|
Modern Web
|
||||||
|
Containerization
|
||||||
|
Docker
|
||||||
|
-->
|
||||||
Loading…
Add table
Add a link
Reference in a new issue