Deduce

Flask: Backend Services in Python

Sebastian Wette — Mon, 03 Jan 2022 12:30:00 GMT

Inhalt

Einführung
Setup
Eine grundlegende Flask-Applikation
Datenbankanbindung und Serialisierung
Grundlegende CRUD Endpunkte
Weiterführendes Material

Einführung

Flask ist ein Python Web-Framework und gehört mit Django zu den beiden bekanntesten solcher Frameworks. Mit Flask ist es möglich ganze Webseiten zu erstellen, da das Framework z.B. auch mit einer Templating-Engine (JinJa2) daherkommt. In diesem Artikel soll es allerdings nur um die Verwendung von Flask im Backend gehen. Hierzu bietet das Framework viele Funktionlitäten um eine vollwertige REST (Representational State Transfer) API (Application Programming Interface) zu entwickeln.

Das schöne an Flask ist, dass es erstmal ohne viele, häufig unbenutzte, Extras läuft und von sehr vielen Entwicklern immer wieder als äußerst "lightweight" bezeichnet wird. Dies wird im Vergleich sehr deutlich wenn man sich mal mit Django außeinandersetzt. Trotzdem bietet Flask auch viel Extra-Funktionalität, die durch verschiedenste Module hinzugefügt werden kann. Eines dieser extra Packages ist "SQLAlchemy" welches ich auch in den folgenden Beispielen verwenden werde um eine Datenbank einzubinden. Was wäre ein Backend schon ohne Datenbank. Ein weiteres interessantes Package, welches auch in den Beispielen wichtig wird, ist "Marshmallow". Es wird verwendet um Objekte in Python-Datentypen zu konvertieren, und andersherum. Man spricht hier auch von "Serialisierung". Häufig sieht man Marshmallow im Verwendung zusammen mit SQLAlchemy.

Ich sollte noch erwähnen, dass ich in dieser Arbeit nicht auf einige "fortgeschrittene" Features einer Backend REST API, wie z.B. ein User-Login System, eingehen werde, sondern mich auf die Kerninhalte einer simplen REST API beschränke. Am Ende des Artikels werde ich aber einige Quellen verlinken, die noch tiefer in die Materie tauchen und beispielsweise auch auf Module eingehen, die solche Login Systeme bereits abdecken.

Setup

Um mit Flask zu arbeiten bietet es sich, wie bei eigentlich jedem Python Projekt, an eine virtuelle Umgebung aufzusetzen, um so einen Überblick über die Abhängigkeiten des Projektes zu behalten. Voraussetzung hierfür ist der Package Installer for Python (kurz PIP). Für virtuelle Umgebungen verwende ich das Paket "virtualenv", aber es gibt natürlich noch andere Optionen. Installiert wird das Paket mit folgendem Befehl:

pip3 install virtualenv

Als nächstes muss man eine neue Umgebung erstellen:

python3 -m venv /

Nun wird automatisch ein Ordner für die neue Umgebung erstellt, in dem einige Scripts abgespeichert sind und in dem später auch alle Abhängigkeiten gespeichert werden. Jetzt muss man die Umgebung noch aktivieren, um sie zu nutzen. Das geschieht unter Linux/Mac mittels:

source /bin/activate

Unter Windows sieht das ganze so aus:

\Scripts\activate

Jetzt ist die Umgebung aktiv und es können Pakete installiert werden. Es folgen alle Pakete die für die Beispiele installiert werden müssen:

pip3 install flask flask-sqlalchemy flask-marshmallow marshmallow-sqlalchemy

Mit PIP ist es möglich eine Liste aller in einer Umgebung installierten Paktete zu erzeugen:

pip3 freeze

Dieser Befehl erzeugt die Datei "requirements.txt" So kann man später aus dieser Liste heraus alle bennötigten Komponenten installieren:

pip3 install -r requirements.txt

Um API Endpunkte zu testen kann man später entweder seinen Browser nutzen, oder man greift auf ein Tool wie z.B. Postman zurück. Das ist aber natürlich jedem selbst überlassen.

Eine grundlegende Flask-Applikation

Eine REST API wird (meistens) in mehrere Endpunkte gegliedert. Jeder Endpunkt liefert oder empfängt gewisse Ressourcen. Dies geschieht in der Regel im JSON Format. Wie bereits erwähnt braucht es nicht viel um eine sehr simple Flask Applikation zum laufen zu bringen, da man sehr intuitiv Endpunkte definieren kann.

Fangen wir aber noch schlanker an. Im folgenden Beispiel wird eine Flask Applikation, ohne jegliche Funktionalität, gebaut und über einen Developement-Server gestartet. Dazu muss erwähnt werden, dass dieser Server nicht für Produktionszwecke geeignet ist. Hier sollte man auf eine andere Lösung, wie beispielsweise das Hosting via UWSGI, zurückgreifen. Nun aber zum Beispiel:

from flask import Flask

#App initialisieren
app = Flask(__name__)

#Developement-Server starten
if __name__ == "__main__":
    app.run(debug=True)

Wenn diese Datei nun mit Python ausgeführt wird, startet der Server und die Anwendung ist unter "localhost:5000/" erreichbar.

Eine einfache Route erzeugt man wie folgt:

from flask import Flask, jsonify

#App initialisieren
app = Flask(__name__)

#Routen
@app.route("/", methods=['GET'])
def home():
    return jsonify({'message':'hello'})
    
#Developement-Server starten
if __name__ == "__main__":
    app.run(debug=True)

Was genau passiert hier? Es wird eine Route mit der dazugehörigen Funktionalität definiert. Dafür erstellt man mit einem Flask-eigenen Decorator die Route und legt die HTTP Methoden fest, welche auf diese Route anwendbar sind. Unterhalb dieses Decorators definiert man dann die dazugehörige Funktionalität in einer Funktion. Ein solche Funktion liefert immer einen String. In diesem Fall, und im Falle der meisten REST API's, wird in diesem String aber JSON zurückgegeben. In Python kann man JSON sehr einfach mit einem Dictionary darstellen, welches dann mit der Funktion "jsonify()" geparsed wird.

Ruft man nach Ausführen der Datei nun den Localhost am Port 5000 auf, egal ob im Browser, oder mit Postman, wird man {'message' : 'hello'} im JSON Format dargestellt sehen können.

Allein mit dieser Funktionalität lässt sich schon viel anstellen, vor allem da man in Python sehr einfach mit Dictionaries arbeiten kann. Aber natürlich wollen wir noch ein wenig tiefer in die Materie eintauchen. Daher komme ich jetzt zur Datenbankanbindung und Serialisierung.

Datenbankanbindung und Serialisierung

Um eine Datenbank an eine Flask-Applikation anzubinden eignet sich SQL-Alchemy, da es hier ein extra Paket zur Verwendung mit Flask gibt. SQL-Alchemy implementiert einen sogenannten ORM (Object-Relational-Mapper), welcher eine weitere Abstraktionsebenene zwischen der Applikation und der Datenbank (SQL) darstellt. Man kann diesen ORM wie ein gewöhnliches Objekt, ganz nach allen Regeln des OOP, verwenden und seine Datenbank ohne SQL Queries verwalten. Man verwendet hierfür die Methoden und Attribute des ORM. Diese extra Abstraktionsebene ermöglicht es uns als Endnutzern, unseren Code zur Datenbankinteraktion zu schreiben OHNE uns vorher auf eine bestimmte Datenbank festlegen zu müssen, da SQL-Alchemy's Interface mit den meisten gängigen SQL Datenbanken zurechtkommt. In den weiteren Beispielen verwende ich beispielsweise SQLite, was sich super zum schnellen, lokalen Testen und Entwickeln eignet. Um in Produktion zu gehen kann man dann aber ohne Probleme auf eine MySQL, oder MariaDB Datenbank umsteigen.

Die Daten aus der Datenbank kann man nun als Klasse darstellen lassen, möchte sie aber vielleicht auch als einfache Datentypen ausgeben können. Hierfür verwenden wir Marshmallow um die Daten zu Serialisieren. Dafür erstellt man ein festes Schema, nach welchem Marshmallow dann automatisch umformen kann.

Es folgt ein größeres Beispiel, an welchem gleich die Prinzipien von SQLAlchemy und Marshmallow erklärt werden:

from flask import Flask, jsonify
from flask_sqlalchemy import SQLAlchemy
from flask_marshmallow import Marshmallow
import os

#App initialisieren
app = Flask(__name__)
basedir = os.path.abspath(os.path.dirname(__file__))

#Datenbank Setup
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///' + os.path.join(basedir, 'db.sqlite')
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False

#Datenbank initialisieren
db = SQLAlchemy(app)

#Marshmallow initialisieren
ma = Marshmallow(app)

#Modell für eine Task-Ressource
class Task(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(100), unique=True)
    description = db.Column(db.String(200))
    
    def __init__(self, name, description):
        self.name = name
        self.description = description
        
#Task Schema
class TaskSchema(ma.Schema):
    class Meta:
        fields = ('id','name','description')

#Schema initialisieren        
task_schema = ProductSchema(strict=True)
tasks_schema = ProductSchema(many=True, strict=True)

#Developement-Server starten
if __name__ == "__main__":
    app.run(debug=True)

Zu Beginn müssen einige Konfigurationen für die Datenbank vorgenommen werden. Am wichtigsten ist hier die "DATABASE_URI". Diese URI ist quasi der Pfad zur Datenbank. Je nach verwendeter Datenbank muss diese URI natürlich angepasst werden, um z.B. auch Nutzerdaten mit zu übergeben. Desweiteren müssen sowohl SQLAlchemy als auch Marshmallow initialisiert werden.

Nun bennötigt der ORM ein Modell der Daten, welche in der Datenbank abgebildet werden. In unserem Fall ist das die Ressource "Task". Ein Task besteht aus einer ID, welche auch der Primary-Key ist, dem Namen und einer kurzen Beschreibung. Außerdem braucht das Modell noch einen Konstruktor, in dem diese Werte dem "Objekt" zugewiesen werden. Man beachte, dass die ID hier nicht zugewiesen wird, da sie von SQLAlchemy automatisch verwaltet wird. In unserem Fall werden nur einfache Datentypen für die Spalten der Datenbank verwendet, aber natürlich sind beispielsweise auch Relationships mit SQLAlchemy abbildbar. Mehr dazu findet sich in der offiziellen Dokumentation.

Zuletzt muss Marshmallow noch informiert werden, wie das Schema für die Serialisierung auszusehen hat. Den Großteil übernimmt es bei so simplen Modellen von alleine, aber in einer Subklasse "Meta" müssen alle Felder angegeben werden, welche bei der Konvertierung berücksichtigt werden sollen. Dieses Schema muss jetzt nurnoch initialisiert werden. Hierbei ist darauf zu achten, das Schema für die Ressource einmal für die Rückgabe eines einzelnen Objektes, als auch für die Rückgabe mehrerer Objekte auf einmal zu initialisieren.

Bei größeren Projekten bietet es sich außerdem an, diese verschiedenen Konfigurationen und Modelle in verschiedenen Dateien zu schreiben.

Falls die Datenbank nicht schon bereit steht lässt sie sich sehr einfach mit Hilfe von SQLAlchemy generieren, sodass alle beschriebenen Modelle als einzelne Tabellen erzeugt werden und einsatzbereit sind. Dazu öffnet man ein neues Terminal und startet eine neue Python Shell. Nun folgt als erstes ein Import der Datenbank aus der geschriebenen Datei (die Datei heißt hier app.py):

from app import db

Jetzt kann die Datenbank mit einem einfachen Befehl erzeugt werden:

db.create_all()

Damit werden alle Modelle, die in der Datei beschrieben sind erzeugt und im Falle von SQLite sollte in der aktuellen Directory nun die Datei "db.sqlite" angelegt worden sein.

Grundlegende CRUD Endpunkte

Da das Setup der Datenbank erfolgt ist können die ersten Endpunkte erstellt werden. Die folgenden Beispiele sind der Übersicht halber vom Rest des Codes getrennt, müssen für eine funktionstüchtige API aber natürlich zum Code "Grundgerüst" hinzugefügt werden. Wo und wie man eine Route definiert wurde bereits dargestellt.

In den folgenden Beispielen schauen wir die volle Funktionalität einer klassischen API nach "CRUD" (Create, Read, Update, Delete), anhand des Beispiels der Task-Ressource an. So können am Ende neue Tasks erstellt, aber auch gelesen, geupdated und gelöscht werden.

Beginnen wir mit CREATE:

# CREATE Task
@app.route('/task', methods=['POST'])
def add_task():
  name = request.json['name']
  description = request.json['description']

  new_task = Product(name, description)

  db.session.add(new_task)
  db.session.commit()

  return product_schema.jsonify(new_task)

Ein CREATE Endpunkt funktioniert natürlich als POST Methode, da neue Daten zum Server "geposted" werden.
Alles was nun getan werden muss, ist die bennötigten Daten aus diesem POST-Request zu lesen. Dafür verwendet man das Attribut "request" und liest aus diesen, wie aus einem Dictionary. Als nächstes erzeugt man ein Objekt, welches man anschließend zur Datenbank hinzufügt. Das Hinzufügen funktioniert in zwei Schritten. Als erstes wird das Objekt der aktuellen Session hinzugefügt, und dann wird diese Session zur Datenbank commited. Der Rückgabewert dieses Endpunktes sollen die einzelnen Attribute der Daten im JSON Format sein. Dafür verwendet man das Marshmallow-Schema, welches man direkt in JSON umwandeln kann. Dieser Endpunkt wäre so nun einsatzbereit und kann mit Hilfe von Postman getestet werden.

Als nächstes folgen zwei Endpunkte für die READ/GET Funktionalität:

# GET (alle Tasks)
@app.route('/task', methods=['GET'])
def get_tasks():
  all_tasks = Task.query.all()
  result = tasks_schema.dump(all_tasks)
  return jsonify(result.data)
  
# GET (einzelner Task)
@app.route('/task/', methods=['GET'])
def get_task(id):
  task = Task.query.get(id)
  return task_schema.jsonify(task)

Natürlich werden diese Endpunkte durch GET-Requests angesprochen. Wenn alle Tasks auf einmal abgefragt werden sollen geht das ziemlich schnell, da man der Datenbank nur den Befehl geben muss um alle Tasks zurückzugeben. Für solche Queries hat der ORM von SQLAlchemy sehr intuitive Methoden. Anschließend werden diese Daten nach dem Schema umgeformt und im JSON Format zurückgeliefert.
Für einen einzelnen Task muss man nun noch einen Query-Parameter übergeben. Im Beispiel wird anhand der ID eines Tasks gesucht. Dafür wird der Methode das ID Parameter mitgegeben, welches aus der URL gelesen wird. Innerhalb des Decorators kann man mit den Zeichen "< >" deutlich machen, dass es sich um Parameter handelt.

Kommen wir zur UPDATE Funktionalität:

# UPDATE
@app.route('/task/', methods=['PUT'])
def update_task(id):
  task = Task.query.get(id)

  name = request.json['name']
  description = request.json['description']
  
  task.name = name
  task.description = description

  db.session.commit()

  return product_schema.jsonify(task)

Die Methode eines solchen Enpunkt ist PUT. Prinzipiell verbindet man hier GET und POST ein wenig. Zuerst holen wir und den Task der geupdatet werden soll und lesen dann die neuen Daten aus dem Request. Mit diesen neuen Daten verändert man dann das aus der Datenbank geladene Objekt und committed diese Veränderungen dann wieder. Zum Schluss gibt man dann das Schema des veränderten Tasks zurück.

Als letztes schauen wir uns DELETE an:

# DELETE
@app.route('/task/', methods=['DELETE'])
def delete_task(id):
  task = Task.query.get(id)
  db.session.delete(task)
  db.session.commit()

  return product_schema.jsonify(task)

Hierfür verwendet man die DELETE-Methode. Auch bei diesem Endpunkt muss erst einmal der gewünschte Task geladen werden. Dieser kann dann sehr simpel gelöscht und die Änderungen an der Datenbank committed werden.

Weiterführendes Material

Jetzt ist der Punkt erreicht, an dem die sehr simple CRUD REST API voll funktionsfähig ist. Natürlich gibt es aber noch weitere Themen um noch tiefer in das Thema einzutauchen. Daher hier einige Links:

Ich hoffe ich konnte einigen Lesern mit diesem kurzen Artikel weiterhelfen. Vielen Dank für's Lesen!

Einführung in Angular

Sebastian Wette — Mon, 13 Dec 2021 11:00:00 GMT

Inhalt

Einführung
CLI und Setup
Ordnerstruktur
Komponenten
Attribute und Interpolation
Inputs
Outputs und Events
Modelle
Directives
Services
Observables
Subjects und Subscriptions
HTTP Client
Forms
Routing
Weiterführendes Material

Einführung

Angular ist ein Frontend-Framework für Single-Page Applications und basiert grundsätzlich auf TypeScript. Angular läuft Clientseitig, aber wird meist mit einem Backend (z.B. einer REST API) verknüpft um so, effiziente und nutzerfreundliche Web-Apps zu bauen. Angular 13.2.0 ist die neuste Version des Nachfolgers von AngularJS.

Mit Angular lassen sich dynamische Apps und User-Interfaces relativ simpel erstellen, aber trotzdem bietet Angular viele advanced Features, wie einen eingebauten HTTP-Client, RxJS (asynchronous), oder einen eigenen Router.
Die Sprache der Wahl ist TypeScript, wobei die Verwendung der TypeScript-eigenen Features optional ist und auch reines JavaScript verwendet werden kann. Auch wenn Angular dem Entwickler viel Arbeit abnimmt, muss man dennoch viel lernen, da Angular ein großes und umfangreiches Framework bleibt.

Wie die meisten großen Frontend-Frameworks (vgl. Vue oder React) basiert Angular auf Komponenten. Komponenten sind Teile der UI, die in ein Template (HTML), die Logik (TypeScript) und die Styles (CSS) aufgeteilt werden. Sie sind wiederverwendbar und werden mit eigens deklarierten XML-Tags in die HTML Templates eingebunden. Mehr dazu im Abschnitt "Komponenten".

Um einen möglichst angenehmen Einstieg in Angular zu haben ist es vorteilhaft, wenn man schon grundlegende JavaScript (oder sogar TypeScript) Kenntnisse vorweisen kann, allerdings möchte ich hier nichts voraussetzen. Ich würde behaupten, wenn man schon einmal mit einer "C ähnlichen" Sprache gearbeitet hat, sollte man keine Probleme mit den angeführten Code-Beispielen haben.

CLI und Setup

Angular kommt mit seinem eigenen CLI (Command-Line-Interface) daher. Dieses wird genutzt um neue Projekte anzulegen, aber auch Komponenten und Services zu erzeugen und einen lokalen Dev-Server zu starten (der nicht für die Produktion verwendet werden sollte). Vorraussetzung hierfür ist, dass Node auf dem System installiert ist, da npm (der Node-Package-Manager) verwendet wird um Angular zu installieren.

npm install -g @angular/cli

Mithilfe der CLI lässt sich nun sehr simpel ein neues Projekt erstellen.

ng new -my-app --no-strict

Die Option "--no-strict" ist optional und beschreibt nur, ob die TypeScript Dateien "strenger" kompiliert werden (also die Typangaben strenger durchgesetzt werden). Nun kann man noch wählen ob man Angular-Routing direkt aktivieren möchte und welche Sprache man für die Syles verwenden möchte (CSS, SCSS ...).

Um den Dev-Server zu starten verwendet man folgenden Command:

ng serve

Nun wird die Angular-App via localhost:4200 bereitgestellt.

Ordnerstruktur

Nach dem Erstellen der ersten App kann die Anzahl der generierten Dateien erst einmal einschüchtern sein. Angular erstellt neben den Source-Files z.B auch Dateien zum tracken der npm-Abhängigkeiten in der "package.json" Datei, Angular-spezifische Konfigurationen in der "angular.json" Datei und Type-Script Konfigurationen in der "tsconfig.json".

Der interessantest Ordner ist allerdings der "src" Ordner. Im Ordner "/src/app" werden alle Komponenten und Services, und somit der gesamte Kern der App, Platz finden. Innerhalb des "src" Ordners existiert eine "index.html" Datei, welche der Ausgangspunkt der Angular-App ist. In dieser Datei wird, mit dem Tag , die Root-Komponente der Angular App eingebunden, und von hier aus schachteln sich nun alle Komponenten, die man in der App einbringt. Natürlich kann man innerhalb dieser Datei auch einige Metadaten (z.B. den Titel) verändern.

Die "main.ts" Datei ist der Einstiegspunkt in Angular für die App. Hier wird z.B. das "AppModule" geladen. Man kann sich dieses "Module" aber wie eine Art Hub für die App vorstellen. Es ist der Zentrale Punkt der App, in den man weitere Module von Angular einbinden kann, um diese dann in seinem Code zu verwenden. Die Datei befindet sich im Order "/src/app", und in ihr wird vorerst nur der Kern von Angular geladen, aber später können weitere Module und auch Services importiert werden.

Desweiteren fallen bestimmt die vielen Dateien mit ".component" im Namen auf, welche mit den verschiedensten Dateiendungen enden (.css, .html, und .ts). Mit diesen Dateien wird eine Komponente beschrieben. Die Konvention für die Namensgebung lautet hier ".component.". Wirklich viel muss man hier nicht beachten, da das CLI diese Dateien beim Erstellen neuer Komponenten automatisch nach diesem Schema benennt. Diese verschiedenen Dateien machen jetzt eine Komponente aus, welche in Logik, Template, und Styles aufgeteilt wird. Es existiert auch eine ".spec.ts" Datei welche für Tests eine Rolle spielt, aber diese soll an dieser Stelle erst einmal vernachlässigt werden.

Komponenten

Wie in der Einführung bereits beschrieben ist Angular komponentenbasiert. Eine Komponente ist ein in sich geschlossener Teil der UI, allerdings können Komponenten natürlich auch verschachtelt werden und sind vollkommen wiederverwendbar. Eine Komponente besteht aus einem Template (HTML), der Logik (TypeScript) und den optionalen Styles (z.B. CSS oder SCSS). Die Syntax einer Komponente sieht wie folgt aus:

import { Component } from '@angular/core';

@Component({
    selector: 'app-list',
    templateUrl: './list.component.html',
    providers:  [listService]
})

export class ListComponent implements OnInit{
    /* ... */

Begonnen wird mit einem Decorator, in welchem wichtige Rahmenbedingungen für die Komponente festgelegt werden wie z.B. der Selektor, also der Tag, mit dem die Komponente später im HTML Code verwendert werden kann. Auch der Pfad zum HTML-Template der Komponente wird hier festgelegt und das wäre auch genauso mit den Styles. Man muss erwähnen, dass Template und Styles auch optional inline direkt im Decorator definiert werden können. Davon ist aus Gründen der modularität aber eher abzuraten. Unter dem Keyword Providers werden die Services, welche verwendet werden aufgeführt. Dazu später mehr.

Auf den Decorator folgt eine relativ normale Klassendefinition. Innerhalb dieser Klasse werden die Methoden und Attribute der Komponente definiert.

Eine neue Komponente kann entweder "per Hand" erzeugt werden oder man verwendet das CLI:

 ng generate component

Angular kümmert sich hier direkt darum, dass die neue Komponente direkt in der "app.module.ts" Datei eingetragen wird und alle nötigen Imports stattfinden. Optional kann ein Pfad zur Komponente (ausgehend vom Ordner "src") angegeben werden, unter welchem die Komponente zu finden sein soll. Alle Unterordner zu diesem Pfad werden falls nötig automatisch erstellt. So lassen sich Komponenten logisch verschachteln und steigern so die Übersichtlichkeit.

In dieser neu erstellten Komponente kann man nun das Template, die Styles, als auch die Logik definieren. Werfen wir einmal einen Blick auf die "app-root" Komponente:

import { Component, OnInit } from '@angular/core';

@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls:['./app.component.css']
})

export class AppComponent implements OnInit{
    title:string = 'angular-app';
    
    ngOnInit(): void{
    }
}

Hier wird zusätzlich zum Template-File auch die CSS-Datei für die Styles angegeben. Durch den angegebenen Selektor kann die Root-Komponente nun in der "index.html" mit genau diesem Tag verwendet werden.

Die Methode "ngOnInit()" ist eine sogenannte Lifecycle-Methode. Im Fall von "ngOnInit()" wird diese Methode also dann ausgeführt, wenn die Komponente initiiert wird. Eine weitere Lifecycle-Methode wäre "ngOnDestroy()".

Attribute und Interpolation

Im oben gezeigten Code der "app-root" Komponente ist der "title" ein Attribut dieser Klasse bzw. dieser Komponente. Eine sehr wichtige Funktionalität von Angular ist es nun, dieses Attribut dynamisch in das HTML-Template einzubinden, um so auch Variablen aus der Logik im Browser anzeigen zu können. Das ganze wird möglich durch "String-Interpolation".

Der HTML-Code zum Anzeigen des "title" Attributes sieht so aus:

 {{title}}

Durch zwei Paar geschweifte Klammern "{{}}" wird deutlich gemacht, dass hier eine TypeScript Expression, welche am Ende einen String liefern muss, ausgeführt wird. Im Browser wird jetzt natürlich nicht "{{title}}" angezeigt sondern der Wert des "title" Attributes in der Komponente, also in diesem Fall "angular-app". Prinzipiell kann jede Art von TypeScript Expression zwischen die beiden geschweiften Klammerpaare geschrieben werden.

Inputs

Bisher können wir Daten aus den Komponenten im Browser anzeigen lassen. Allerdings ist es auch sehr wichtig Daten in eine Komponente übergeben zu können. Hierfür sind Inputs zu verwenden. Sehen wir uns als Beispiel eine Button-Komponente an, in die man eine Frabe und einen Text quasi wie zwei Parameter übergeben kann:

Das ganze nennt man "Databinding" ("[]" = Input) oder genauer "Propertybinding". Doch ganz so einfach ist es natürlich nicht. Wir müssen der Komponente noch sagen, dass sie diese "Parameter" überhaupt entgegennimmt und wie diese dann verwendet werden. Wie die Werte verwendet werden kommt natürlich auf den Anwendungsfall an. In diesem Abschnitt gehe ich nur auf die Integration solcher Inputs in der Komponente ein. Der Code hierzu sieht wie folgt aus:

import { Component, OnInit, Input } from '@angular/core';

@Component({
    selector: 'app-button',
    templateUrl: './button.component.html',
    styleUrls:['./button.component.css']
})

export class ButtonComponent implements OnInit{
    @Input text: string;
    @Input color: string;
    
    constructor(){}
    
    ngOnInit(): void{
    }
}

Nun können die übergebenen Daten in der Komponente verwendet werden.

Outputs und Events

Wenn es Inputs gibt muss es natürlich auch Outputs geben. Die einfachste Form eines Outputs ist ein Event im DOM. Angular bietet eine sehr einfache Möglichkeit auf Standard-Events zu reagieren:

Auch hier spricht man von "Databinding", allerdings geht es hier in die andere Richtung ("()" = Output) man spricht eher von "Eventbinding". Innerhalb der Klammern wird das Event beschrieben, auf welches reagiert werden soll, in diesem Fall ein einfacher Klick. Natürlich könnte der Methode hier auch etwas übergeben werden. Darauf folgt die Methode der Komponente, welche daraufhin ausgeführt werden soll. Innerhalb der Komponente, die zu diesem Template gehört muss nun also die Methode "onClick()" realisiert werden:

import { Component, OnInit, Input } from '@angular/core';

@Component({
    selector: 'app-button',
    templateUrl: './button.component.html',
    styleUrls:['./button.component.css']
})

export class ButtonComponent implements OnInit{
    @Input text: string;
    @Input color: string;
    
    constructor(){}
    
    ngOnInit(): void{
    }
    
    onClick(){
        console.log("Click!");
    }
}

Wenn diese Komponente eingebunden wird und der Button geklickt wird, sollte man nun in der Konsole ein "Click!" sehen.

So viel zu Standard-Events. Nun wird es aber nötig sein eigene Events, also eigene Output-Signale, weiterzugeben. Auch das ist mit Angular relativ simpel möglich. Hierzu erstellt man ein Attribut vom Typ "EventEmitter", welches dann ein Event ausgeben kann:

import { Component, OnInit, Input, Output, EventEmitter } from '@angular/core';

@Component({
    selector: 'app-button',
    templateUrl: './button.component.html',
    styleUrls:['./button.component.css']
})

export class ButtonComponent implements OnInit{
    @Input() text: string;
    @Input() color: string;
    @Output() btnClick = new EventEmitter();
    
    constructor(){}
    
    ngOnInit(): void{
    }
    
    onClick(){
        this.btnClick.emit();
    }
}

Das angelegte EventEmitter Attribut wird nun in der "onClick()" Methode "aktiviert" und sendet ein Event an seine Parent-Komponente. Innerhalb der Parent-Komponente kann man dieses Event nun wieder wie bei Standard-Events abfangen:

Nun wird also indirekt "printSomething()" dieser Parent-Komponente aufgerufen wenn der Button geklickt wird. Dabei geht erstmal ein "click" Event an die Button-Komponente, welche das eigens erstelle Event "btnClick" auslöst, welches dann die Methode auslöst.

Modelle

Innerhalb von Angular ist es häufig eine gute Idee ein Modell von einem behandelten Datenobjekt zu erstellen. Ein einfaches Beispiel hierfür wäre eine To-Do Liste. Ein wiederkehrendes Element für welches ein Datenmodell sinnvoll ist wäre hier eine Aufgabe. Modelle werden typischerweise im "app" Ordner erstellt und nach dem Schema ".model.ts" benannt. Prinzipiell ist ein Modell einfach nur eine Klasse, jedoch wird es in TypeScript als "Interface" bezeichnet. Es folgt ein Beispiel:

export interface Task {
  id?: number;
  text: string;
  day: string;
  reminder: boolean;
}

Dieses Modell kann nun in anderen Teilen der Applikation verwendet werden. Beispielweise für Services, welche mit Aufgaben arbeiten, oder der HTTP-Client welcher Aufgaben aus dem Backend laden wird.

Directives

Directives sind "Logik-Bausteine" welche teilweise mit Angular ausgeliefert werden, aber auch selbst definiert werden können. Mit ihnen kann das Aussehen, oder das Verhalten von Elementen im DOM (Document Object Model) verändert werden. Directives können dann in Elementen eingebaut und mit diesen verwendet werden. Nun folgen einige Beispiele:

Beginnen wir mit "ngStyle". Hiermit können inline CSS Regeln definiert werden, welche aber auch mit Attributen aus der Komponente (aus der TypeScript-Klasse) gefüttert werden können:

So wird der Hintergrund des Buttons grün dargestellt.

Eine ähnliche Directive, wie "ngStyle" ist "ngClass". Mithilfe von "ngClass" kann einem Element dynamisch eine spezielle Klasse zugewiesen werden, um so z.B. spezielle CSS-Regeln auf dieses Element anzuwenden. Es folgt ein Beispiel:

...

In diesem Beispiel wird dem "div"-Element die Klasse "toggled" zugewiesen, falls der Wert "isToggled" des Objektes "data" auf "true" steht.

Ein weiterer wichtiger Baustein, der direkt mit Angular daherkommt, ist "ngFor". Wie der Name schon vermuten lässt, handelt es sich hierbei um eine Art For-Schleife, mit der eine Komponente für z.B. mehrere Elemente eines Arrays erzeugt werden kann. ngFor ist eine Strukturelle Directive und das wird mit einem vorangestellten "" gekennzeichnet:


    {{task.name}}

Hier würde durch das Array "tasks" iteriert werden, und für jeden Task ein p-Tag angelegt werden, in welchem der Name des Tasks ausgegeben wird.

Die nächste wichtige strukturelle Directive wäre "*ngIf". Auch hier ist der Name Programm. Mit "*ngIf" lassen sich gewisse Elemente in Abhängigkeit zu einer Bedingung anzeigen, oder eben auch nicht.


    {{task.name}}

In diesem Fall wird der Paragraph also angezeigt wenn "dummyBoolean" den Wert "true" enthält. Innerhalb der Anführungszeichen kann aber auch jede andere Expression stehen, solange diese am Ende entweder "true" oder "false" ergibt.

Services

Services werden strikt von Komponenten getrennt, um die Modularität und Wiederverwendbarkeit des Codes zu verbessern. Durch diese Aufteilung werden die Komponenten um einiges aufgeräumter, da man die Funktionalität die direkt mit der Ansicht zu tun hat, von anderen Prozessen "im Hintergrund" trennt. So kann eine Komponente dann spezielle Aufgaben an verschiedenste Services deligieren.

Services können ebenfalls durch das CLI erstellt werden:

ng generate service

Auch hier gilt: Optional kann ein Pfad zum Service (ausgehend vom Ordner "src") angegeben werden, unter welchem dieser zu finden sein soll. Alle Unterordner zu diesem Pfad werden falls nötig automatisch erstellt.

Ein Service besteht aus einer TypeScript Datei, welche nach dem Schema .service.ts benannt ist. Diese Datei sieht typischerweise so aus:

import { Injectable } from '@angular/core';
    
@Injectable({
    provideIn:'root'
})    

export class DummyService {
    
    constructor() { }
    
    dummyMethod():string{
        return "dummy";
    }
}

Dieser Service kann natürlich erstmal nicht viel. Doch wie bindet man ihn jetzt ein?

import { Componentn} from '@angular/core';
import {DummyService} from '../../services/task.service';

@Component({
    selector: 'app-button',
    templateUrl: './dummy.component.html',
    styleUrls:['./dummy.component.css']
})

export class Dummy implements OnInit{
    dummy_atribute:string;
    
    constructor(private dService: DummyService){}
    
    ngOnInit(): void{
        dummy_atribute = this.dService.dummyMethod();
    }
}

Hier passiert auf den ersten Blick sehr viel. Zuerst wird der Service importiert, um dann in die Komponente eingebunden zu werden. Das passiert als Parameter innerhalb des Konstruktors der Komponente. Von nun an exisitert in der "Dummy" Komponente eine Instanz vom DummyService mit dem Namen "dService". Diese Instant wird in der "onInit()" Methode verwendet um eine Methode, welche der Service bereitstellt zu verwenden.

Ein sehr gutes und auch weit verbreitetes Beispiel für einen Service, ist die Anbindung an ein Backend, um Daten von diesem zu beziehen, oder sie bereitzustellen. Im Abschnitt zum HTTP-Client wird so ein Service allgemein umschrieben.

Observables

Im Zusammenhang mit HTTP Requests lässt der Begriff "Asynchrone Kommunikation" natürlich nicht lange auf sich warten. Angular soll ja Clientseitig weiter funktionieren während es auf eine Antwort auf einen Request wartet. Hierfür stehen unter Angular sogenannte "Observables" bereit. Ein Observable ist quasi ein Objekt welches beobachtet ("observed") werden kann, und Rückmeldungen weitergeben kann, sobald diese eintriffen. Angular verwendet hier die rxjs-Bibliothek. Wie genau das aussehen kann zeige ich am Beispiel des DummyServices:

import { Injectable } from '@angular/core';
import {Observable, of} from 'rxjs';
    
@Injectable({
    provideIn:'root'
})    

export class DummyService {
    
    constructor() { }
    
    dummyMethod(): Observable{
        const data = of("dummy");
        return data;
    }
}

Nun liefert die dummy-Methode ein Observable. Man spricht ab jetzt davon, dass man ein Observable "abonniert" sodass man es durchgehen überwachen kann. Das sieht in der Komponente so aus:

import { Componentn} from '@angular/core';
import {DummyService} from '../../services/task.service';

@Component({
    selector: 'app-button',
    templateUrl: './dummy.component.html',
    styleUrls:['./dummy.component.css']
})

export class Dummy implements OnInit{
    dummy_atribute:string;
    
    constructor(private dService: DummyService){}
    
    ngOnInit(): void{
        this.dummyService.dummyMethod().subscribe(
            (data) => (this.dummy_atribute = data);
        );
    }
}

Man kann sich das abonnieren (subscribe) ein wenig so vorstellen wie ein "Promise" mit ".then()". Innerhalb des Aufrufes der "subscribe" Methode wird mit einer Arrow-Function angegeben, was mit den übergebenen Daten (hier "data") passieren soll.

Subjects und Subscriptions

Eine andere Form von Observables sind Subjects. Ein Subject ist ein einzelnes Element, welches als Quell-Observable bezeichnet werden kann. Nun kann es ein oder mehrere Ziele geben, welches die Quelle durchgehend beobachten (eine/mehrere Subscription/s). Ein Subject wird häufig in einem Service abgebildet:

import { Injectable } from '@angular/core';
import {Observable, Subject} from 'rxjs';
    
@Injectable({
    provideIn:'root'
})    

export class SubjectService {
    private dummy_data: boolean = false;
    private subject = new Subject();
    
    constructor() { }
    
    toggleDummyData():void {
        this.dummy_data = !this.dummy_data;
        this.subject.next(this.dummy_data);
    }
    
    onToggle(): Observable {
        return this.subject.asObservable();
    }
}

Die Methode "toggleDummyData" im Beispiel, beschreibt eine Methode, die aufgerufen wird, sobald Daten verändert werden sollen. "onToggle()" wäre die Methode die nun von mehreren Zielen abonniert werden kann, damit diese Ziele auf Änderungen reagieren können:

import { Componentn} from '@angular/core';
import {SubjectService} from '../../services/subject.service';
import {Subscription} from 'rxjs';

@Component({
    selector: 'app-button',
    templateUrl: './dummy.component.html',
    styleUrls:['./dummy.component.css']
})

export class Dummy implements OnInit{
    dummy_atribute:boolean;
    subscription: Subscription;
    
    constructor(private sService: SubjectService){
        this.subscription = this.sService.onToggle().subscribe(
            (value) => (this.dummy_attribute = value)
        );
    }
    
    ngOnInit(): void{
        
    }
    
    toggleDummy(){
        this.sService.toggleDummyData();
    }
}

In diesem Beispiel befinden sich der Auslöser für Änderungen in den Daten, also die Methode "toggleDummy()" und die Reaktion auf die Änderungen, also die Subscription, in der selben Komponente. Nun ist es essenziell zu verstehen, dass so eine Reaktion/Subscription von überall aus stattfinden kann. Man hat also eine Quelle und 1-n Empfänger, die auf die Quelle reagieren können. Die eigentliche Subscription funktioniert prinzipiell wie ein einfacher aufruf eines Observables mittels ".subscribe()" und einer Arrow-Function als Parameter.

HTTP Client

Wie bereits erwähnt spielen Services und Observables vor allem in Zusammenhang mit HTTP-Requests eine Rolle. Angular kommt, in Kontrast zu anderen Frameworks, mit einem eingebauten HTTP-Client daher, welcher außerdem automatisch immer Daten vom Typ "Observable" zurückgibt. Ich beschreibe das ganze hier weiter anhand des DummyServices und unter der Annahme, dass ein voll funktionsfähiges Backend zur Verfügung steht. Zu Beginn ist es wichtig den Client in den Service zu importieren:

import { HttpClient, HttpHeaders } from '@angular/common/http';

Doch damit das überhaupt funktionieren kann ist es noch nötig den Client als Modul zur Applikation hinzuzufügen. Das ganze macht man, indem man in der Datei "app.module.ts" folgenden Import vornimmt:

import { HttpClientModule } from '@angular/common/http';

Außerdem muss man das Modul noch zum "imports"-Array hinzufügen:

imports:[
    BrowserModule,
    HttpClientModule
],

Nun folgt ein vollständiges Beispiel für einen GET-Request an ein Backend innerhalb des DummyServices:

import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';
import {Observable, of} from 'rxjs';
    
@Injectable({
    provideIn:'root'
})    

export class DummyService {
    private apiUrl = 'http://myBackend:5000/data';
    
    constructor(private http:HttpClient) { }
    
    dummyGET(): Observable{
        return this.http.get(this.apiUrl);
    }
}

Ähnlich wie bei einem eigens erstellten Service ist es hier nötig den Client in den Konstruktor einzubinden, um ihn dann verwenden zu können. Der eigentliche GET-Request ist relativ selbsterklärend. Interessanter wird es z.B. bei DELETE oder POST-Requests, da hier ggf. noch ID's und Header mit ins Spiel kommen. Dabei kommt es natürlich ganz auf die Funktionalität des Backends an. Hier also nochmal das Beispiel, aber diesmal mit einer Delete-Methode, welche die ID eines Datenelementes bennötigt, und mit einer Put- sowie Post-Methode, welche HTTP-Header verwenden:

import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';
import {Observable, of} from 'rxjs';
    
const httpOptions = {
    headers: new HttpHeaders({
        'Content-Type':'appliction/json'
    })
}
    
@Injectable({
    provideIn:'root'
})    

export class DummyService {
    private apiUrl = 'http://myBackend:5000/data';
    
    constructor(private http:HttpClient) { }
    
    dummyGET(): Observable{
        return this.http.get(this.apiUrl);
    }
    
    dummyDELETE(dummyData:data): Observable {
        const url = `${this.apiUrl}/${data.id}`;
        return this.http.delete(url);
    }
    
    dummyPUT(dummyData:data):Observable {
         const url = `${this.apiUrl}/${data.id}`;
         return this.http.put(url, data, httpOptions);
    }
    
    dummyPOST(dummyData:data):Observable {
         return this.http.post(this.apiUrl, task, httpOptions);
    }
}

Forms

In fast jeder Applikation wird es wichtig sein, mit Web-Forms zu interagieren. Egal ob Textfeld, Radiobuttons, oder Dropdowns, User-Input wird so gut wie immer gefragt sein. Auch hier bietet Angular viele Funktionen, um den Umgang mit Forms möglichst angenehm zu gestalten. Schauen wir uns ein sehr einfaches Form an:


    
        Dummy Textbox

Wenn man jetzt ein Attribut der Komponente, in der dieses Form exisitert, mit einem Input-Feld des Forms beidseitig verknüpfen möchte ("Two-way Databinding) bietet Angular hier das "ngModel". Mit "ngModel" kann so ein "Two-way Databinding" erzielt werden. Ein Attribut der Komponente wird bidirektional mit einem Input-Element verknüpft. Dafür muss die Komponente natürlich ein Attribut für jedes Input-Element bereithalten. Um die Directive "ngModel" verwenden zu können muss die Datei "app.module.ts" noch angepasst werden. Es muss, wie beim HttpClient, ein weiteres Modul zur Applikation hinzugefügt werden:

import { FormsModule } from '@angular/forms';

Außerdem muss man das Modul noch zum "imports"-Array hinzufügen:

imports:[
    BrowserModule,
    HttpClientModule,
    FormsModule
],

Innerhalb des HTML-Templates sieht die verwendung von "ngModel" wie folgt aus:


    
        Dummy Textbox

Mit Hilfe von ngModel ("[()]" = Input+Output) wird die Textbox "dummy" nun mit dem Attribut "dummy_attribute" verknüpft.

Auch für das Abschicken von Forms (submit) bietet Angular seine eigene Funktionalität.


    
        Dummy Textbox

Mit dem Angular-Event "ngSubmit" kann das Abschicken des Forms abgefangen und mit einer Custom-Methode behandelt werden.

Routing

Angular ist ein Framework für "Single-Page Applications". Das bedeutet natürlich nicht, dass man mit Angular immer nur eine einzelne Seite eine Applikation bauen kann. Es bedeutet vielmehr, dass im Browser immer nur eine Seite geöffnet bleibt, und das "routing" verschiedener Seiten quasi im Hintergrund unter Angular passiert. Prinzipiell wird erstmal die "app-root" Komponente geladen, und mit dieser dann alle Komponenten, welche in "app-root" verankert sind. Nun bietet Angular auch die Funktionalität, verschiedene Komponenten unter verschiedenen URL's bereitzustellen. So können unter "myDomain.com/" andere Komponenten geladen und angezeigt werden als unter "myDomain.com/about". Hierfür verwendet man den Angular Router.

Den Router aktiviert man entweder beim erstellen einer neuen App, oder man aktiviert ihn später manuell, indem man wieder eine kleine Änderung an der Datei "app.module.ts" vornimmt:

import { RouterModule, Routes } from '@angular/router';

Außerdem muss man das Modul noch zum "imports"-Array hinzufügen:

imports:[
    BrowserModule,
    HttpClientModule,
    FormsModule,
    RouterModule.forRoot(appRoutes)
],

Nun kann man auch schon seine Routes erzeugen. Das ganze passiert ebenfalls in der "app.module.ts" Datei, überhalb des Decorators "@NgModule". Hier einmal ein Beispiel für verschiedene Routen:

const appRoutes: Routes = [
    {path: '', component:DummyComponent},
    {path; 'about', component; AboutComponent}
]

Das ganze ist relativ selbsterklärend. Man verknüpft einfach einen spezifischen Pfad mit einer gewünschten Komponente, welche dann unter diesem Pfad erreichbar ist. Damit Angular weiß, wo genau der "Output" des Routers geladen und gerendert werden soll ist noch eine Modifikation an der Hauptkomponente, unter "app.component.html" nötig. Hier muss noch ein spezieller Tag eingefügt werden:

Jetzt werden in "app-root" immer die Komponenten, die zum derzeitigen Pfad passen, geladen und angezeigt.

Weiterführendes Material

Ich hoffe ich konnte mit dieser knappen Einführung einigen Leuten weiterhelfen, oder zumindest Interesse erwecken. Vermutlich ist es am wichtigsten, die hier erklärten Funktionen einfach mal selbst auszuprobieren, um sie richtig zu verstehen und sie mal vor Augen zu haben. Dafür möchte ich noch zwei Quellen verknüpfen, welche meiner Meinung nach den Umgang mit Angular sehr detailliert, aber auch verständlich erklären:

Vielen Dank für's lesen!