© Liashko/Shutterstock.com
TypeScript-Applikationen und Libraries modular und wiederverwendbar gestalten

Modular mit Node.js und TypeScript


JavaScript hat die Welt erobert und ist dort, wo Java vor Jahren gerne gewesen wäre: auf verschiedensten Plattformen, sowohl am Client als auch am Server. Doch wie baut man die TypeScript Libraries und -Apps möglichst wiederverwendbar auf?

JavaScript ist zur Universalsprache für verschiedenste Aufgaben auf verschiedensten Plattformen geworden: Von „klassischer“ clientseitiger Entwicklung für Websites oder Apps über serverseitige Lösungen mit Node.js bis hin zu Scripting- und Verwaltungstools. Mit TypeScript steht ein mächtiger Transpiler zur Verfügung, dessen statische Typisierung skalierbare Entwicklung, Fehlerfindung zur Compile-Zeit, bessere IDE-Integration und Rücktranspilierung von neueren ECMAScript-Konstrukten in ältere ECMAScript-Versionen ermöglicht. Bei all diesen Vorteilen wäre es doch schön, wenn man vorrangig nur mehr mit TypeScript programmierte und damit viel Aufwand bei der Ausbildung und Schulung der Mitarbeiter, bei Projekt-Onboardings und bei der Applikationsentwicklung sparen könnte.

Eine Frage für Unternehmen, Entwickler und Architekten

Ich wurde kürzlich auf einer Veranstaltung gefragt, welche Programmiersprache man neuen bzw. umzuschulenden Mitarbeitern beibringen solle. Es ergab sich schnell eine hitzige Diskussion und Statistiken wie z. B. die von IEEE Spectrum [1], des PYPL PopularitY of Programming Language Index [2] oder des TIOBE Index [3] wurden in den Raum geworfen. Wenn man auf GitHub nachsieht, sind die meisten Pushs und die aktivsten Repositories diejenigen mit JavaScript. Ein Blick auf jährliche Wachstumsraten zeigt JavaScript als einen der Wachstumsträger. Wie auch immer die genauen Zahlen sein mögen, die Bandbreite der JavaScript-Einsatzgebiete wächst laufend, und moderne progressive Web- und Mobile-Apps mit Frameworks wie React und AngularJS tun ihr Übriges.

Eine für alle – JavaScript am Client und am Server

Gesetzt den Fall, wir entschließen uns nun bei einem neuen Projekt für den „TypeScript-only“-Weg, müssen wir uns überlegen, wie und mit welchen Tools wir den Entwicklungszyklus aufbauen und die Applikation strukturieren und paketieren. Ein großes Ziel dabei ist, dass wir an Client und Server die gleichen Mechanismen verwenden und einen hohen Code-Reuse erreichen.

Die Aufgabe: eine Single-Page-App mit einem Node. js-Serverteil

Wir nehmen als Bespiel eine Single-Page-Applikation, die auf Node.js-REST-Services zugreift. Diese Services kommunizieren ihrerseits über eine Datenzugriffsschicht und den Tedious-Treiber mit SQL Azure. Abbildung 1 zeigt die vereinfachte Architektur.

mahringer_1.tif_fmt1.jpgAbb. 1: Architekturüberblick

Die Herausforderung besteht nun darin, die am Client und am Server benötigten Funktionen (das Domain Model sowie Utilities für Arrays, Datumsberechnung, Logging, Decorators usw.) so zu strukturieren, dass sie nicht doppelt gewartet werden müssen. Was kann dabei schwierig sein? Ein Unterschied zwischen client- und serverseitiger Programmierung besteht in der Modularisierung. Beim clientseitigen JavaScript gibt es zahlreiche Varianten, angefangen beim klassischen Inkludieren der JavaScript-Dateien über <script>-Tags, über Module Loader wie AMD (RequireJS) oder JSPM bis hin zu Bundlingtools wie webpack.

Ein Blick auf das Modulsystem von Node.js aus 3 000 Meter Entfernung

Auf das Modulsystem von Node.js können wir in diesem Artikel nicht im Detail eingehen. Wir beschränken uns daher an dieser Stelle nur auf das Nötigste: Ein Node. js-Modul entspricht der CommonJS-Konvention [4] und ist eine Sammlung von JavaScript-Dateien, die in einem Unterordner des Ordners node_modules liegen. Der Einsprungspunkt in ein Modul ist die Datei index.js, die bei Bedarf andere JavaScript-Dateien einbinden kann. Die Verzeichnisst...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang