Cross-Platform-Blog.de

Electron.NET – Erstelle eine minimale MusicPlayer App mit ASP.NET Core 2 für den Desktop

2017-10-27T00:00:00-00:00

Der Blog richtet sich in der Regel an die Entwicklung von Cross-Plattform Lösungen mit JavaScript. Diesmal gibt es eine besondere Ausnahme, denn gemeinsam mit meinem Microsoft MVP Kollegen und Freund Robert Mühsig, habe ich ein neues Open-Source Projekt gestartet: Electron.NET

Wie der Name es schon erahnen lässt, haben wir ein Electron Derivat für.NET Core entwickelt. Dies ermöglicht die Cross-Plattform Desktop Entwicklung mit C# und ASP.NET Core. Wir haben das Rad nicht neu erfunden, die darunterliegende Runtime basiert auf Electron. So baut Electron.NET auf eine bereits hochentwickelte und stabile Plattform auf.

Dieser Blog-Post zeigt mit einem einfachen Beispiel, wie simpel es ist, mit Electron.NET und ASP.NET Core 2 eine Cross-Plattform Desktop Software zu entwickeln. Es handelt sich hierbei um einen MusicPlayer. Dieser greift auf das Musik-Verzeichnis zu und kann dann ein beliebiges Lied abspielen.

Vorbereitungen für den Start:

Ein neues ASP.NET Core 2 Projekt anlegen

Aus den Projektvorlagen wählen wir eine „ASP.NET Core Web Application“. Der Name lautet hierbei MyElectronMusicPlayer. Für dieses Beispiel reicht ein komplett leeres Projekt aus. Achte darauf, dass oben .NET Core in Version 2.0 ausgewählt ist.

Abbildung 1 – Ein neues ASP.NET Core 2 Projekt anlegen

Jetzt muss die MVC Erweiterung über den NuGet Package Manager installiert werden:
Install-Package Microsoft.AspNetCore.Mvc -Version 2.0.0

Nach der Installation, gibt es ein paar Dinge, die wir zur Startup.cs hinzufügen müssen. Konfigurieren wir zunächst die App, um das MVC-Framework zu verwenden.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
}

Im zweiten Schritt, konfigurieren wir die App so, dass sie die MVC-Anforderungsausführungspipeline (Routing) mit einer Standardroute verwendet.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{ 
    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });

    // ...
}

Jetzt, da das MVC-Framework hinzugefügt wurde, können wir einen Controller und eine View erstellen. Hierzu legen wir einen neuen Ordner namens Controller an. Per Rechtsklick auf diesen, fügen wir einen neuen Controller hinzu.

Abbildung 2 – Einen neuen Controller hinzufügen

Der HomeController wird mit einer Standardmethode namens Index hinzugefügt. Klicken wir mit der rechten Maustaste auf View() und wählen AddView.

Abbildung 3 - Eine neue View hinzufügen

Ein neuer Views-Ordner mit Index.cshtml wurde automatisch angelegt. Das ASP.NET MVC Core Projekt ist jetzt für die Implementierung der Logik bereit.

Electron.NET hinzufügen

Es sind nur wenige Schritte nötig, um unsere ASP.NET MVC Core 2 Anwendung auf Electron.NET zum Laufen zu bringen. Zuerst muss die Electron.NET API über den NuGet Package Manager installiert werden:
PM> Install-Package ElectronNET.API

In der Program.cs-Datei wird dann die UseElectron WebHostBuilder-Extension hinzugefügt.

public static IWebHost BuildWebHost(string[] args)
{
    return WebHost.CreateDefaultBuilder(args)
        .UseElectron(args)
        .UseStartup<Startup>()
        .Build();
}

Das war auch schon alles, damit Electron.NET für das Projekt verwendet werden kann. Bis jetzt würde allerdings beim Ausführen vom Projekt nichts passieren. Die Anwendung würde einfach im Hintergrund laufen. Da wir keinen Hintergrundprozess programmieren wollen, wird bei der Startup.cs-Datei ein kleiner Bootstrap-Code für das Anzeigen von einem Hauptfenster implementiert. Zusätzlich möchten wir als Option die Security deaktivieren. So dass wir später ohne Probleme auf das Musik-Verzeichnis zugreifen können.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });

    Bootstrap();
}

public async void Bootstrap()
{
    var options = new BrowserWindowOptions
    {
        WebPreferences = new WebPreferences
        {
            WebSecurity = false
        }
    };

    await Electron.WindowManager.CreateWindowAsync(options);
}

Zugriff auf das Dateisystem

Beim HomeController benötigen wir jetzt den Zugriff auf das Dateisystem. Dazu bietet uns die Electron.NET API die Möglichkeit den Pfad der aktuellen Plattform für das Musik-Verzeichnis zu ermitteln. Mit .NET Core greifen wir dann auf die Dateinamen innerhalb des Verzeichnisses zu. Das Ergebnis liefern wir dann direkt an die View weiter.

using ElectronNET.API;
using ElectronNET.API.Entities;
using Microsoft.AspNetCore.Mvc;
using System.Collections.Generic;
using System.IO;
using System.Threading.Tasks;

namespace MyElectronMusicPlayer.Controllers
{
    public class HomeController : Controller
    {
        public async Task<IActionResult> Index()
        {
            string musicPath = await Electron.App.GetPathAsync(PathName.music);
            string[] mp3Files = Directory.GetFiles(musicPath, "*.mp3", SearchOption.TopDirectoryOnly);
            string[] mp4Files = Directory.GetFiles(musicPath, "*.mp4", SearchOption.TopDirectoryOnly);

            List<string> musicFiles = new List<string>();
            musicFiles.AddRange(mp3Files);
            musicFiles.AddRange(mp4Files);

            return View(musicFiles);
        }
    }
}

Die Oberfläche

Die Oberfläche und Funktionalität wird für dieses Beispiel unspektakulär und einfach gehalten. So soll nur eine Liste der Dateien angezeigt werden, die durch einen Button-Klick das gewünschte Lied abspielt. Dazu wird die HTML5 Audio-Klasse eingesetzt.

@model List<string>

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>My Electron Music Player</title>
    <meta charset="utf-8" />
</head>
<body>
    <h3>My Music</h3>
    <ul>
        @foreach (string musicFile in Model)
        {
            <li>
                 @System.IO.Path.GetFileNameWithoutExtension(musicFile)

                <button onclick="playMusic('@musicFile.Replace(@"\", "/")')">Play</button>
            </li>
        }
    </ul>

    <script>

        function playMusic(musicFile) {
            let audio = new Audio(`file:///${musicFile}`);
            audio.play();
        }

    </script>
</body>
</html>

Start der Electron.NET Anwendung

Für das Ausführen der Electron.NET Anwendung wird die Electron.NET CLI benötigt. Die Installation kann leider nicht über NuGet wie gewohnt erfolgen. Das Paket muss ausschließlich über die .csproj-Projektdatei referenziert werden. Dazu folgenden Eintrag hinzufügen:

<ItemGroup>
       <DotNetCliToolReference Include="ElectronNET.CLI" Version="*" />
</ItemGroup>

Anschließend in der Console dotnet restore eingeben.

Bei einem neuen Electron.NET Projekt, muss zu Beginn einmalig dotnet electronize init eingegeben werden. Hierzu wird eine electron.manifest.json-Datei angelegt und ein neues Debug-Profil bereitgestellt.

Mit dem Befehl dotnet electronize start wird dann die ASP.NET MVC Core 2 Anwendung als Desktop-Software gestartet.

Wichtig! Beim ersten Mal dauert der Startvorgang etwas. Wir arbeiten daran, dies in Zukunft zu beschleunigen.

Abbildung 4 – Die Electron MusicPlayer Anwendung

Das Builden

Die Electron.NET CLI ermöglich ebenfalls das Builden einer ausführbaren Anwendung für Windows, Mac und Linux. Dazu gibt es allgemein den Befehl dotnet electronize build.

Für einzelne Plattformen:
dotnet electronize build win
dotnet electronize build osx
dotnet electronize build linux

Wichtig! Für das Builden von Mac-Anwendungen wird ein Mac oder Linux benötigt.

Fazit

Wir haben in diesem Beispiel gesehen, wie einfach mit Electron.NET eine Desktop-Software mit ASP.NET MVC Core 2 erzeugt wird. Der C#-Code greift hierbei auf die Verzeichnisse zu und übermittelt diese Informationen an die MVC-Oberfläche. Normal wäre dies über einen Web-Browser nicht möglich.

Weitere Beispiele der Electron.NET API demonstriert die API Demo-App. Wer mag kann gerne zur Übung probieren, wie ein OpenFile-Dialog über die API angesprochen wird. So dass unsere Beispielanwendung auch andere Verzeichnisse einlesen kann. Als kleinen Bonus könnte man einen Shortcut hinterlegen, der per Zufall eines der Lieder aus der Liste abspielt. Wer das geschafft hat, kann gerne ein Kommentar hinterlassen 😊

Hier der MusicPlayer auf GitHub
Hier die Electron.NET API Demo App auf GitHub

Wie gefällt euch Electron.NET? Ich freue mich auf dein Feedback als Kommentar.

Electron.NET – Erstelle eine minimale MusicPlayer App mit ASP.NET Core 2 für den Desktop was originally published by Gregor Biswanger at Cross-Platform-Blog.de on October 27, 2017.

Interview mit webpack Gründer Tobias Koppers

2017-03-04T00:00:00-00:00

Tobias Koppers ist freiberuflicher Software-Entwickler und Berater aus Nürnberg. Bekannt wurde er als Autor von webpack, das weltweit von mehreren Millionen Entwicklern eingesetzt wird. Seine Schwerpunkte liegen bei der JavaScript Entwicklung und Open-Source Projekten. Ich konnte ein Exklusivinterview mit Tobias führen, das ich euch nicht vorenthalten möchte. Viel Spaß beim Lesen.

Gregor: Hallo Tobias, die ganze JavaScript-Welt spricht über webpack. Sogar Google setzt darauf und hat es direkt bei der Angular CLI integriert. Ich bin auch ganz besonders stolz darauf, dass webpack aus Nürnberg, der Nähe meiner Heimatstadt Ingolstadt stammt. Erzähl uns doch mal die Geschichte, wie du auf die Idee gekommen bist und wie webpack sich so schnell verbreiten konnte.

Tobias: Hi Gregor. Tatsächlich war Google in der Entstehung auch involviert, wenn auch nur indirekt. Bevor ich süchtig nach JavaScript wurde habe ich auch mal mit Java gearbeitet. Hier gibt es ein Tool von Google welches es ermöglicht eine clientseitige Web-Anwendung in Java zu entwickeln: Google Web Toolkit (GWT). Das ist ein Java-zu-JavaScript Compiler für SPAs, welcher auch Basis von einigen Google Anwendungen ist.

Beim GWT hat mir besonders ein Feature besonders gefallen: Code Splitting. Dies ermöglicht unter anderem selten benutzten Code erst später nachzuladen. Diese Feature ist besonders wichtig für große Anwendungen um die initiale Ladezeit klein zu halten. Mir hat dieses Feature in existierenden JavaScript-Tooling gefehlt (2012) und daraus ist letztlich webpack entstanden.

Das heißt webpack ist mit dem Fokus auf Code Splitting entstanden, und meiner Meinung nach war das auch der Grund warum es sich so verbreitet hat. Mit wachsender Größe von Webanwendungen und gleichzeitigen verstärkten Gebrauch von mobilen Geräten (mit schwacher Netzanbindung) sie die Relevanz von Code Splitting mit der Zeit gewachsen. Ansonsten lässt sich die gewünschte Performance nur schwer umsetzen.

Gregor: Viele vergleichen webpack mit Task-Tools wie NPM-Scripts, Grunt und Gulp. Einige haben mit webpack auch wirklich ihren Ersatz gefunden. Ich selbst nutze zukünftig auch nur noch NPM-Scripts und webpack. Wie stehst du zu diesem Thema und nutzt du ein Task-Tool zusätzlich zu webpack?

Tobias: Mir selbst reichen NPM Skripte auch aus. Tatsächlich ist aber eigentlich nicht richtig webpack als Ersatz für Grunt/Gulp zu bezeichnen. Grunt und Gulp fallen in eine andere Kategorie von Tools wie webpack. Grunt, Gulp und NPM Skripte sind Task Runner.

Webpack ist ein Module Bundler. Dies sind Werkzeuge mit unterschiedlichen Zielen. Es ist aber richtig, dass webpack die notwendigen “Tasks” zum Bauen einer Web-Anwendung soweit vereinfacht, dass es eventuell ein Overkill ist Task Runner wie Grunt und Gulp zu verwenden und NPM Skripte ausreichen. NPM ist also der Ersatz für Grunt und Gulp.

Allerdings haben Task Runner immer noch ihre Daseinsberechtigung für andere Aufgaben neben vom reinen Bauen der Web-Anwendung: Deployment, Linting, Versionsmanagement, etc.

Gregor: Bei meinen JavaScript Schulungen bekomme ich bei meinen Teilnehmern immer wieder mit, wie schwer Ihnen der Einstieg mit webpack fällt. Hast du dazu auch schon Feedback bekommen? Wenn ja, hast du auch schon Ideen, wie man das verbessern kann?

Tobias: Ja tatsächlich kommt dieses Feedback auch an. Allerdings sagen auch viele Nutzer, dass sobald es erstmal “Klick” gemacht hat, ist es eigentlich recht einfach zu benutzen. Wer webpack “kann” sagt sogar, dass es einfacher ist als die vorherigen Tools.

Ich glaube dieses Feedback ist darin begründet, dass die Konzepte von webpack deutlich von den Konzepten anderer Tools abweichen. Vor allem bei der Migration von Grunt/Gulp zu webpack. Task Runner haben eher eine imperative Konfiguration, d. h. man beschreibt die Schritte die vom Task Runner auszuführen sind. Webpack hingegen hat eine deklarative Konfiguration, d. h. man beschreibt nicht die Schritte die webpack ausführen soll, sondern beschreibt nur die Art und Weise wie diese Schritte auszuführen sind bzw. wie das Ergebnis auszusehen hat.

Gregor: Was steht noch auf deiner Agenda? Welche Features sind bei der nächsten webpack-Version geplant?

Tobias: Das ist noch nicht ganz klar. Es gibt so viele Dinge die möglich sind. Um nur einige spannende Punkte zu nennen:

Scope Hoisting: kleine und performantere Art die Module zusammenzuhängen
WebAssembly: Unterstützung von binärem Code in der WebApp
Persistenter Cache: Schnelleres initiales Kompilieren
CSS (und HTML) als First-Class-Citizen: Schönere Unterstützung für Stylesheets (und HTML)
Und noch viele spannende Kleinigkeiten

In welcher Reihenfolge diese angegangen werden entscheiden die Nutzer und Sponsoren. Wir haben eine Voting-Seite auf dieser für die nächsten Punkte abgestimmt werden kann. Jeder bekommt täglich einen Einflusspunkt und Sponsoren und Contributor bekommen für Spenden bzw. Contributions goldene Einflusspunkte. Das geschieht aus der Motivation heraus Sponsoren und Contributor etwas zurückgeben zu wollen. Außerdem ist es natürlich interessant was Nutzer am meisten wollen.

Gregor: Kannst du uns einen Top Best Practictes Tipp zu webpack verraten?

Tobias: On-Demand-Loading verwenden. Es ist super einfach zu verwenden und bringt unglaublich viel.

Gregor: Was sind deine persönlichen Ziele? Werden wir bald alle lesen, dass du bei Google in Mountain View arbeiten wirst? ;)

Tobias: Eher nicht. Ich werde demnächst als Freelancer arbeiten. Ich werde versuchen so viel wie möglich an Open Source zu arbeiten und das Ganze über Spenden zu finanzieren. Da Spenden allerdings meist nicht reichen, werde ich den Rest über Auftragsarbeiten oder Consulting finanzieren. Ich bin schon gespannt wie das läuft. Vielleicht findet sich ja ein Sponsor der mir ein paar zusätzliche Wochen Open Source finanziert (hey Google ;) ).

Der Aufwand ein Open Source Projekt zu maintainen wird häufig unterschätzt. Aktuell verbrauchen Code Reviews und Issues 80% meiner Zeit. Ich komm kaum noch dazu selbst Code zu schreiben, geschweige denn zu Refactorn. Ich muss sogar teilweise Pull Requests erstmal eine Zeit liegen lassen bevor ich die Zeit finde sie im Detail anzuschauen. Das ist natürlich demotivierend für die Contributor. Ich denke, dass sich das ändern kann, wenn ich Vollzeit an webpack arbeite. Hoffentlich habe ich dann auch mehr Zeit um selbst mehr Code zu schreiben.

Gregor: Ganz vielen Dank, dass du dir die Zeit für uns und das Interview genommen hast! Danke auch für webpack, das uns JavaScript-Entwickler extrem unterstützt. Ich liebe dein Tool!

Tobias: Gerne. Mein Dank geht zurück an die Community. Webpack ist nicht “mein” Tool, es wird von mehr als 500 Contributoren gestaltet. Zu webpacks Erfolg zählt auch sein großes Ecosystem.

Interview mit webpack Gründer Tobias Koppers was originally published by Gregor Biswanger at Cross-Platform-Blog.de on April 03, 2017.

JavaScript Coding Dojo: Der DictionaryReplacer Kata

2017-03-02T00:00:00-00:00

Das Dojo ist die Übungshalle in den japanischen Kampfkünsten und die Übungen werden hierbei Kata genannt. Beim Coding Dojo geht es darum eine Übungsaufgabe (Kata) zu meistern. Ganz nach dem Motto „Learning by doing“. Der Cross-Platform-Blog wird jetzt regelmäßig JavaScript Katas veröffentlichen.

Der DictionaryReplacer Kata

Bei diesem Kata handelt es sich um einen einfachen String-Replacer. Die Inspiration zu diesem Kata entstand durch einen Vortrag von Cory Haines zum Thema Übungen. Erstelle eine Methode, die einen String und ein Dictionary erhält. Darin soll nun jeder Key des Dictionaries, welcher mit einem Dollarzeichen beginnt und endet, mit dem entsprechenden Wert des Dictionaries ersetzt werden.

Tests:
input: “”, dictionary: empty, output: “”

input: “$temp$”, dictionary: [“temp”, “temporary”], output: “temporary”

input: “$temp$ here comes the name $name$”, dictionary: [“temp”, “temporary”] [“name”, “John Doe”], output: “temporary here comes the name John Doe”

Schwierigkeit: Einfach
Dauer: Ca. 5-20 Minuten
Quelle: http://codingdojo.org/kata/DictionaryReplacer/

Vorbereitungen für den Start

Für das Projekt wird folgendes benötigt:

Node.js (Läuft auf Windows, Mac und Linux)
TypeScript
In der Konsole npm install typescript –g eingeben
Visual Studio Code (Läuft auf Windows, Mac und Linux)

Für dich ist bereits ein fertiges Übungsprojekt auf GitHub hinterlegt:

git clone https://github.com/GregorBiswanger/KataDictionaryReplacer.git

Anschließend innerhalb des Projekts mit npm install alle nötigen Module installieren.

Du kannst kein TypeScript? Keine Sorge! TypeScript == JavaScript und du kannst dein bisheriges JavaScript Wissen ohne Probleme einsetzen. Die Vorteile? Spüre es selbst bei der Codeübung. ;) Ein wesentlicher Unterschied ist, dass die Dateiendung hierbei mit *.TS endet. Die TypeScript erstellten JavaScript und Source Map-Dateien habe ich für die Übung von Visual Studio Code ausblenden lassen. Das sorgt für eine bessere Übersicht. Im Dateisystem existieren diese allerdings.

Der Start

Öffne das Projekt mit Visual Studio Code
Starte den TypeScript Compiler mit der Tastenkombination [strg] + [shift] + [b]
Beim Terminal gibst du innerhalb deines Projekts npm test ein

Jetzt läuft der Testrunner Jasmine und bemerkt Dateiänderungen automatisch. Hast du einen zweiten Monitor, ist dort für den Terminal der ideale Platz. So kannst du während der Entwicklung den aktuellen Status beobachten.

Der Prozess

Wichtig bei Coding Dojo ist mit Babysteps die Lösung zu meistern. Löse jede Aufgabe Schritt für Schritt und nicht alles auf einmal. Dieses Prinzip ist für viele Entwickler nicht einfach, aber genau die Vorteile an dieser Herangehensweise lehrt uns ein Coding Dojo.

Welche Aufgaben Schritt für Schritt erfüllt werden müssen, findest du im spec-Verzeichnis. Beim src-Ordner findet dann die eigentliche Programmierung statt.

Debugging

Das Projekt hat bereits alle nötigen Visual Studio Code Einstellungen, so dass du ohne Probleme innerhalb der Tests oder beim eigenen Code debuggen kannst. Dazu einfach mit der [F9]-Taste einen Breakpoint setzen und mit [F5] das Debugging starten.

Regeln

Löse das Kata bis alle Tests grün sind
Anschließend kopiere deine Lösung hier auf jsfiddle.net: https://jsfiddle.net/GregorBiswanger/n6zm9wz7/
Klicke links oben auf den „Update“-Button und kommentiere deinen Link hier bei diesem Blog-Post
Erst dann, darfst du deine Lösung gerne mit bereits Kommentierten Lösungen vergleichen

Let’s get ready to rumble!

Bei meinen JavaScript Schulungen mache ich immer wieder gerne Katas mit meinen Teilnehmern. Ich liebe es anschließend die unterschiedlichen Lösungen zu begutachten. Ich bin auch jetzt gespannt, wie du die Aufgabe meistern wirst. Und jetzt: Let’s get ready to rumble!

JavaScript Coding Dojo: Der DictionaryReplacer Kata was originally published by Gregor Biswanger at Cross-Platform-Blog.de on February 03, 2017.

Node.js: Die REST Web-API Express.js mit TypeScript

2017-30-01T00:00:00-00:00

Bei Node.js hat sich ein Web Application Framework stark durchgesetzt: Express.js. Dieses wurde vom Sinatra-Framework aus der Ruby-Welt inspiriert. Es erweitert das vorhandene Build-In Modul http von Node.js, damit das Entwickeln moderner Webanwendungen einfacher gestaltet wird:

Vergleichbar mit der Microsoft Web-API (Nur besser :))
Kommunikation mit REST (HTTP) per Standard
Request/Response-Handling
Routing
View Templating
Session Support
Static Files Support
Middleware
- Zum Beispiel Funktionen, die sich zwischen Request und Response hängen können (Logger etc.)
Und vieles mehr…

Die Installation

Zuerst wird ein neues Node.js-Projekt mit einer TypeScript Compiler-Konfiguration benötigt. Passend dazu die Visual Studio Code Build- und Debugging-Konfiguration. Diese Schritte wurden bereits im folgenden Artikel ausführlich erklärt:

Visual Studio Code: Node.js mit TypeScript und Debugging

Zusätzlich wird jetzt Express.js und die TypeScript Deklaration für Express.js benötigt. Dazu innerhalb des Projekts im Terminal folgendes eintippen:
npm install express –save
npm install @types/express –save-dev

Das erste Express.js „Hello World“

Wir legen eine neue index.ts-Datei an oder ersetzen die vorhandene Datei mit dem Inhalt des folgenden Codes:

import express = require('express');
let app = express();

app.get('/', function (request, response) {
    response.send('Hello World');
});

app.listen(3000);

Der Code ist sehr ähnlich aus dem gewohnten „Hello World“-Beispiel für Node.js. Die Unterschiede: Express.js erstellt automatisch im Hintergrund bei der listen-Funktion einen Web-Server. Die Abfrage für REST wird explizit vergeben, wie hier zum Beispiel mit get. Das Routing wird daraufhin mit einem String-Wert festgelegt. Bei der Verarbeitung der Anfrage wird wie gewohnt eine anonyme Funktion ausgeführt, allerdings muss hier kein Stream explizit beendet werden. Darum kümmert sich Express.js automatisch.

Die GET-Aktion mit Parameter

Eine REST GET-Aktion wird mittels get-Funktion hinterlegt. Das Routing wird per String festgelegt und Parameter werden zusätzlich mit Doppelpunkt und Variablenamen gekennzeichnet. Wie folgendes Beispiel zeigt:

app.get('/api/sayhello/:name', (request, response) => {
    let name = request.params.name;

    if (!isNaN(name)) {
        response
            .status(400)
            .send('No string as name');
    } else {
        response.json({
            "message": name
        });
    }
});

In Visual Studio Code den TypeScript-Compiler starten [strg] + [shift] + [b], falls dieser noch nicht läuft. Als nächstes die Anwendung mit [F5] ausführen. Anschließend im Browser http://localhost:3000/api/sayhello/John eingeben. Der Web-Service sollte nun folgenden JSON-Wert zurückliefern:

{
    "message": "John"
}

Folgende Rückgabe-Funktionen sind mit der Get-Funktion möglich:

render für HTML-Inhalt mit View Engine
send für Text-Inhalt
json für JSON-Inhalt
redirect zur Weiterleitung

Queries

Gewöhnliche Query-Parameter können ebenfalls abgefragt werden. Diese befinden sich unter request.query.PARAMETERNAME. Ein zusätzliches Festlegen im Routing ist nicht notwendig.

app.get('/api/sayhello/', (request, response) => {
    let name = request.query.name;

    let result = {
        message: name
    };

    if (!isNaN(name)) {
        response
            .status(400)
            .send('No string as name');
    } else {
        response.json(result);
    }
});

Als nächstes die Anwendung mit [F5] ausführen. Anschließend im Browser http://localhost:3000/api/sayhello?name=NodeJS eingeben.

Die Post-Aktion

POST-Aktion mittels post-Funktion hinterlegen. Damit allerdings reguläre Form-Submit POST-Anfragen verarbeitet werden können, sind noch zwei weitere Pakete zur Installation notwendig:

npm install body-parser multer --save

Diese sind relevant zum Parsen von multipart/form-data und application/x-www-form-urlencoded. Als Single-Middleware wird upload.array() zusätzlich bei der Post-Funktion eingebunden. Forms gesendete Daten werden über request.body.VARIABLENAME abgefragt.

import express = require('express');
let app = express();

// For POST-Support
let bodyParser = require('body-parser');
let multer = require('multer');
let upload = multer();

app.use(bodyParser.urlencoded({
    extended: true
}));

app.post('/api/sayHello', upload.array(), (request, response) => {
    let name = request.body.name;

    if (!isNaN(name)) {
        response
            .status(400)
            .send('No string as name');
    } else {
        console.log('Hello ' + name);
    }

    response.send('POST request to homepage');
});

app.listen(3000);

Zum Testen eignet sich das Tool Postman. Bei Postman an erster Stelle „POST“ auswählen und in das URL-Feld http://localhost:3000/api/sayhello/ eintippen. Folgende Abfrage kommt dann direkt darunter:

Jetzt auf den Send-Button klicken und direkt darunter erscheinen die Response-Daten. Die Post-Anfrage kann direkt in Visual Studio Code gedebuggt werden.

Fazit

Mit Express.js kann man schnell und einfach Web-Services bereitstellen und noch viel mehr. In weiteren Artikeln werde ich noch tiefer und weiter auf das tolle Web Application Framework eingehen. Der Source-Code für die Beispiele liegt auf GitHub:

Code on GitHub

Wie gefällt dir Express.js? Ich bin auf deine Meinung im Kommentar gespannt.

Node.js: Die REST Web-API Express.js mit TypeScript was originally published by Gregor Biswanger at Cross-Platform-Blog.de on January 30, 2017.

Visual Studio Code: Node.js mit TypeScript und Debugging

2017-27-01T00:00:00-00:00

Die kostenfreie Entwicklungsumgebung Visual Studio Code von Microsoft, bietet eine hervorragende Unterstützung von TypeScript und die Entwicklung von Node.js-Projekten. Dieser Blog-Post zeigt, wie einfach ein neues Node.js-Projekt mit TypeScript-Support erzeugt wird. Gegen Ende wird auch ein kleines „Hallo Welt“-Beispiel im Debug-Modus durchlaufen.

Für das Beispiel werden folgende Installationen benötigt:

Node.js - http://www.nodejs.org (Läuft auf Windows, Mac und Linux)
TypeScript
In der Konsole npm install typescript –g eingeben
Visual Studio Code - http://code.visualstudio.com (Läuft auf Windows, Mac und Linux)

Ein neues Projekt

Für ein neues Projekt wird nur ein neues Verzeichnis benötigt. In Visual Studio Code wird dieses im Menü über File | Open Folder… geöffnet. Als Projektdatei wird die packages.json-Datei benötigt. Dazu wird in der Konsole npm init -y eingetippt (In VSCode unter Windows [Strg] + [ö] die integrierte Konsole öffnen).

Node.js Deklaration-Dateien installieren

Damit Visual Studio Code die Funktionen von Node.js per IntelliSense auflösen kann, werden die TypeScript Deklaration-Dateien von Node.js benötigt. Diese installiert man ab TypeScript 2 über den Node Package Manager (NPM). Für Node.js wird dazu npm install @types/node –save-dev eingegeben. Für andere Pakete würde man dann zum Beispiel: npm install @types/jquery –save-dev aufrufen.

TypeScript Compiler-Konfiguration

Für einen geeigneten Node.js-Support mit TypeScript, wird eine Compiler-Konfigurationsdatei benötigt. Diese legen wir im Root-Verzeichnis mit dem Namen tsconfig.json an. Dank dem JSON IntelliSense-Feature von Visual Studio Code, wird automatisch anhand des Dateinamens eine Autovervollständigung bereitgestellt. Dazu einfach die ersten geschweiften Klammern setzen und das IntelliSense mit der Tastenkombination [Strg] + [.] auslösen. Die Schema Informationen dazu bezieht sich Visual Studio Code direkt übers Internet. Sollte keine Verbindung möglich sein, entfällt leider der IntelliSense-Support. Tippe dazu die folgende Compiler-Konfiguration:

{
    "compilerOptions": {
        "module": "commonjs",
        "sourceMap": true,
        "watch": true
    }
}

Module: Bei einer klassischen Web-Anwendung bezieht sich der Browser über das Script-Tag die JavaScript Dateien. Bei Node.js wird der JavaScript code unabhängig einer Web-Seite ausgeführt. Daher wurde ein Modul-System mit dem Namen CommonJS ins Leben gerufen. Dieses ermöglicht das Laden von JavaScript-Dateien aus JavaScript-Code heraus. TypeScript benötigt daher die Information, welches Modul-System eingesetzt wird, um den passenden Code automatisch von „import“ und „export“ generieren zu können.

Source Map: Wie der Name bereits sagt, werden hierbei Dateien generiert, die als Karte für den Debugger-Service dienen. Diese helfen dem Debugger dabei, eine Code-Stelle der TypeScript-Datei auf die generierte JavaScript-Datei aufzulösen. Dank diesem Konzept, wird das Debuggen direkt aus der TypeScript-Datei ermöglicht.

Watch: Damit nicht vor jedem Debugging der TypeScript-Compiler gestartet werden muss, hilft die Watch-Option. Diese beobachtet alle TypeScript-Dateien auf Änderungen. Sollte sich eine Datei ändern, so wird automatisch der Compiler aktiv. So reicht es aus, dass nur einmalig der Compiler gestartet werden muss.

Das erste Node.js „Hello World“

Jetzt legen wir eine index.ts-Datei an. Dazu wird folgender Code für ein „Hello World“ Beispiel benötigt:

import http = require('http');

http.createServer((request, response) => {
    response.write('Hallo von Node.js!');
    response.end();
}).listen(3000);

Die erste Zeile beginnt mit einem TypeScript-Spezifischen Keyword import. Damit weiß TypeScript, dass es zu diesem Modul eine Deklaration existieren muss. Sollte keine Deklarations-Datei oder ein TypeScript-Code im Projekt vorhanden sein, wird wie gewöhnlich einfach let geschrieben. Dann greifen wir auf ein Node.js Build-In Modul http von Node.js zu. Die erste Zeile ist somit vergleichbar wie ein using, import oder include aus anderen Hochsprachen.

Ab Zeile 3 wird bereits ein Web-Server erzeugt. Beim Aufruf wird die anonyme Funktion ausgelöst und ein Streaming zum Client ist aktiv. Hier erhalten wir alle Client Anfrageinformationen beim request-Parameter. Über den response-Parameter können wir Daten an den laufenden Stream hängen. Dazu wurde die einfache write-Funktion genutzt, um einen einfachen String-Wert zu senden. Um den laufenden Stream zu beenden, wird die end-Funktion benötigt. Mit der listen-Funktion wird der aktuelle Web-Server für den definierten Port aktiv. Das war es auch schon.

TypeScript Compiler starten über Visual Studio Code

Die TypeScript-Datei wurde geschrieben, allerdings wird ja eine JavaScript-Datei zum Ausführen benötigt. Mit der Tastenkombination [Strg] + [Shift] + [b] wird Visual Studio Code zum Builden aufgefordert. Alternativ kann auch die Command-Line mit [F1] geöffnet werden und man Tippt Build ein. Nun weiß Visual Studio Code nicht, was genau es machen soll. So erfolgt eine Anfrage, was genau man möchte. Hierbei wählen wir TypeScript – tsconfig.json aus.

Es wird ein neues Verzeichnis mit .vscode erzeugt und eine tasks.json-Datei angelegt. Das angenehme an diesem Template ist, dass bereits alle relevanten Einstellungen hinterlegt sind. So können wir diese Datei wieder schließen und rufen wiederholt den Build-Vorgang mit [Strg] + [Shift] + [b] auf. Links unten sehen wir ein rotierendes Zeichen und im File-Explorer sehen wir zwei neue Dateien zu unserer TypeScript-Datei. Einmal die generierte JavaScript-Datei und die SourceMap-Datei, die für das Debuggen nötig ist.

Debuggen der Node.js-Anwendung

Zum Ausführen der Anwendung gibt es unterschiedliche Möglichkeiten. Eine Möglichkeit ist es, unabhängig von Visual Studio Code über die Konsole mit node index.js zu starten. Nur haben wir hierbei keinen Debugging-Komfort. Deshalb nutzen wir die zweite Variante: In Visual Studio Code einfach die [F5]-Taste zum Debuggen drücken. Auch hier weiß Visual Studio Code erstmal nicht, was er Ausführen soll. Wir wählen hierbei das node.js-Template aus.

Hier wird im .vscode-Verzeichnis eine weitere JSON-Datei angelegt. Wichtig ist hierbei zu beachten, dass der JavaScript-Dateiname dem entspricht, was wir angelegt haben und das die Option Source Maps aktiviert ist. Ansonsten können wir nur innerhalb der JavaScript-Datei Debuggen. Anschließend drücken wir wieder die [F5]-Taste. Der Server wurde nun ausgeführt. Wenn wir in der response.write-Zeile die Taste [F9] drücken, oder alternativ neben der Zeilennummer klicken, erhalten wir einen roten Breakpoint. Geht jetzt in den Browser und ruft euren Web-Server mit http://localhost:3000 auf. Visual Studio Code stoppt dann beim Breakpoint und ihr könnt alle Parameter-Werte überprüfen, wie ihr es beim Debugging anderer Hochsprachen gewohnt seid.

Sollte es zu Problemen kommen, liegt es meistens daran, dass man vergessen hat einmalig den TypeScript-Compiler zu starten. Überprüft daher, ob auch eure JavaScript- und SourceMap-Dateien erzeugt wurden.

Fazit

Visual Studio Code ist ein großartiges Tool für die Entwicklung mit Node.js und TypeScript. Mit nur wenigen Zeilen Code, haben wir einen Web-Server und ein REST Web-Service erzeugt. So ganz ohne IIS, Tomcat oder Apache HTTP Server. Das Beispiel habe ich hier auf GitHub hinterlegt:

Code on GitHub

Konnte dir der Artikel helfen? Hast du weitere Fragen? Dann schreib mir ein Kommentar!

Visual Studio Code: Node.js mit TypeScript und Debugging was originally published by Gregor Biswanger at Cross-Platform-Blog.de on January 27, 2017.

Willkommen, schöne neue Welt…

2017-22-01T00:00:00-00:00

…und die konnte ich schon seit über drei Jahren mit JavaScript kennenlernen. Der Schritt war nicht wirklich einfach für mich. Nach über zehn Jahren, als erfahrener .NET Experte, einfach mal den Fokus zu wechseln. Meine ersten Schritte als Entwickler in der Berufswelt ging ich mit PHP. JavaScript war damals nur ein Mittel zum Zweck. Ich war froh, wenn ich so wenig wie möglich davon nutzen musste.

Als spannende und ideale Plattform beflügelte mich dann .NET und C#. Zugegeben, ein paar Jahre dazwischen legte ich mit Visual Basic einen Pfad in die Windows-Entwicklung, war aber nicht wirklich glücklich damit geworden. Microsoft mit .NET begeisterte mich so intensiv, dass ich in Ingolstadt eine großartige Community aufbaute. Ich war international auf anderen Communities und Konferenzen unterwegs und hielt Vorträge zu meinen Erfahrungen. Ich startete die größten Community Roadshows mit mehreren tausend Besuchern. Dann schrieb ich Bücher und Artikel für Fachmagazine. Kurz gesagt, ich habe mir einen Namen mit toller Karriere bei der Microsoft Dev Welt aufgebaut.

Eine neue Richtung gehen

Die Zeit bringt Änderungen mit sich und somit auch ganz neue Kundenanforderungen. Bei zahlreichen Kundengesprächen wurde das Thema „Bring your own device“ in den Fokus gestellt. Es sitzen Manager vor mir mit Windows-, Mac- und Linux-Computern. Alle wollen in den Genuss der neuen Software-Lösung kommen und am Ende hatte immer der Browser gewonnen. Eine Lösung mit .NET konnte oft nur bedingt zum Einsatz kommen. Ich merkte wo die Stärke von diesem tollen Framework auswandert: Ins Backend und in die Cloud! Ja, es gibt dann noch Xamarin, das .NET auf die mobilen Devices bringt. Dies hatte allerdings zahlreiche Nachteile gegenüber Apache Cordova, als wir immer wieder mal Proof of Concepts ausarbeiteten.

Als ich mich intensiv mit JavaScript und somit auch LISP beschäftige, konnte ich Douglas Crockfords Aussage: „The World’s Most Misunderstood Programming Language“
verstehen. Wir sind durch unseren Kunden Intel mit Node.js immer näher gekommen. Projekte wie Adobe Brackets, bei denen ich mitwirkte, sind komplett mit Node.js und JavaScript bestückt. Unsere Software von CleverSocial hatten wir komplett neu geschrieben von ASP.NET MVC 4/Entity Framework/SQL Server auf Node.js, Angular 2 und MongoDB. Wir lernten und spürten die Kraft der neuen JavaScript-Welt. Mein Fazit: Die JavaScript Entwicklung ist produktiver und schneller. Die Lösung am Ende läuft Cross-Platform und mit einer wahnsinnigen Geschwindigkeit. Details für den Umstieg habe ich bereits bei diesem Interview von Entwickler.de ausführlich erklärt: Was .NET-Entwickler über Node.js wissen sollten.

Alles aufgeben?

Überhaupt nicht! Gerade vor einer Woche noch gab ich einen Workshop zum Thema „.NET Entwicklung mit Microsoft Azure“ und hielt am Abend einen Vortrag bei der Ingolstädter .NET User Group über XAML. Wir selbst setzen intensiv auf eine Microservices-Architektur. Wenn wir eine Stärke von .NET brauchen, wird die Lösung ausgereizt. Mag es die Datenkommunikation mit dem Entity Framework zum SQL Server sein. Dann wird dazu ein ASP.NET Core Web-API mit Entity Framework Core eingesetzt oder auch auf das ältere ausgereifte Entity Framework 6. Ich werde weiterhin meine XAML Expertise-Kolumne für das Windows.Developer-Magazin schreiben. Schließlich bin ich immer noch oft genug bei Kunden zum Thema WPF unterwegs.

Fazit

Ich habe seit den letzten drei Jahren 70% mit JavaScript gearbeitet und nur noch 30% auf dem .NET-Stack. Ich habe viele Vorzüge von JavaScript kennengelernt und möchte hier auf meinem neuen Blog zeigen, wie einfach die JavaScript Entwicklung ist. Dazu schreibe ich allgemeines zu JavaScript/TypeScript, Tooling, Angular, Node.js, Electron, Cordova, MongoDB und vielem mehr.

Hast du eventuell auch deine Richtung von einer anderen Sprache zu JavaScript gewechselt? Wenn ja, würde ich mich um ein Kommentar zu deinen Beweggründen freuen. Ansonsten freue ich mich schon mein neues Wissen mit euch zu teilen und ich stehe auch gerne für Workshops/Trainings oder auch zur Beratung zur Verfügung. Dazu einfach eine E-Mail an mich schreiben.

Ich wünsche Dir viel Spaß auf meinem neuen Blog.
Gregor

Willkommen, schöne neue Welt… was originally published by Gregor Biswanger at Cross-Platform-Blog.de on January 22, 2017.