Der Schepp, Rodney und Hans sprechen über die Entwicklung von serverseitigen Applikationen mit Node.
Unser Sponsor
Diese Folge wird gesponsert vom neuen CV-Tool “GravityCV”, für einfaches, flexibles und schnelles erstellen und versenden Deines Lebenslaufs.
“GravityCV” – Professionelles Design & hoher Datenschutz für dein CV.
Kostenlos anmelden unter gravitycv.com.
Schaunotizen
- [00:01:27] CLI Tools
- Selbstgeschriebene Command Line Interface (CLI) Tools sind hilfreich, wenn man viel auf der Command Line unterwegs ist. Mit Node kann man eigene Tools sehr einfach schreiben. Wir erklären wie und welche Module dabei helfen können. Hier eine Auswahl der genannten:
- Meow – Argument Parsing
- opn – Liest einzelne Dateien oder Websites
- ora – Aktivitätsindikator (Spinner)
- prompt – Abfragen von User-Input
- shelljs – Einheitliche Command Line API für Windows, Linux und Mac
- as-table – Tabellarische Daten ausgeben
- decompress und archiver – Einfacher Umgang mit zip, tar und Co.
- keytar – Lokaler Passwort-Speicher
Zur Installation eines eigenen CLI kann man einfach ein Paket von NPM installieren oder direkt von GitHub per entsprechendem Command:
npm install -g git+ssh://@github.com:username/repository.git - [00:20:40] Serverseitige Services
- Natürlich sprechen wir auch drüber, wie man einen Service mit Node bauen kann. Wir haben alle mehr oder minder viel Erfahrung damit und diskutieren über unsere Ansätze. Grundsätzlich sind wir der Meinung, dass Services sich immer an die 12 Factors halten sollten.
Einige Tools die wir empfehlen:- Express – HTTP Server, Middleware-Pattern
- pino (für Express: express-pino-logger) – Serverseitiges Logging
- fluentd – Logging auf stdout
- Sequelize – ORM Modul für MySQL, MariaDB, Postgres
- finale-rest – RESTful Implementierung für Sequelize Models in Express
- Passport – Authentifizierungslirary
- Helmet – Header Management in Express Apps, hier steht wies geht, hier auch.
- dotenv – Configuration einfach verwalten mit einem Dotfile
- brakes – Hystrix equivalent in Node zur Umsetzung des CircuitBreaker-Patterns
Kommentare
Tim Schumacher #
Geschrieben am 8.08.2018 um 08:14
Hi Leute,
eine Sache die inzwischen auch bei der Node-Entwicklung zumindest bei mir unabdingbar ist und nicht im Podcast erwähnt wurde: TypeScript!
Mittels [ts-node](https://github.com/TypeStrong/ts-node) kann man zumindest schnell etwas bauen. Für den Produktivbetrieb würde ich das immer noch compilieren und dann den JavaScript Code mit node ausführen, zudem wenn man als target `es2017` einstellt, ist der Code auch nicht fundamental anderst. Vieleicht ändert sich das ja auch mit [deno](https://github.com/denoland/deno).
Wenn man jetzt TypeScript hat, gibt es einige echt nette Bibliotheken:
**[typeorm](https://github.com/typeorm/typeorm)**
Ähnlich wie sequelize, aber in TypeScript mit Annotations und dadurch kann man seine Models wesentlich besser beschreiben.
**[class-validator](https://github.com/typestack/class-validator)**
Stellt sicher das die Klasse auch die richtigen Daten zur Laufzeit enthält, muss ja in JavaScript nicht umbedingt der Fall sein.
**[class-transformer](https://github.com/typestack/class-transformer)**
Sehr mächtige Bibliothek um plain Objekte in Klassen transformieren. Sehr praktisch wenn man eine eher so mäh API hat, die zwar JSON liefert, die Objekte aber eher Kraut und Rüben sind.
**[routing-controllers](https://github.com/typestack/routing-controllers)**
Wie ich finde, der einzig richtige Weg™ in express Routen zu definieren.
Ich sehe so automatisch generierte Routen von Models immer etwas problematisch. Wir haben das auf Arbeit auch mittels [loopback](https://loopback.io/) gemacht und das geht solange gut, bis man gegen das Framework arbeiten muss, weil das Projekt irgendwelche komischen Anforderungen hat.
Inzwischen machen wir das mit typeorm und routing-controllers und einer Hilfsbibliothek mit der man seinen Endpunkt relativ einfach selbst zusammen stellen kann. Siehe dazu auch [„Composition over inheritance“](https://en.wikipedia.org/wiki/Composition_over_inheritance).
**Logging**
Beim loggen nach stdout gehen unter umständen strukturierte Daten verloren. Wir haben die bessere Erfahrung gemacht, besser mit Bibliotheken wie [winston](https://github.com/winstonjs/winston#readme) direkt nach elk zu loggen, weil da kann man direkt JSON hin schieben und es muss nicht wieder von stdout geparsed werden.
Vielen Dank für die Sendung und liebe Grüße
Tim
ps Ich weis jetzt nicht ob ich hier Markdown posten kann, aber ich hab es einfach mal gemacht ;-), den Artikel gibt es auch nochmal hier: https://hackmd.io/YOzKEej0RY2qJcz–Gln_w
pps [utteranc.es](https://utteranc.es/) ist für Kommentare auch großartig.
RSS-Feed zu diesem Beitrag