Il y a 7 ans -
Temps de lecture 6 minutes
Swift côté Serveur : quoi de neuf ?
Depuis le mois de novembre 2015, date de la publication du code source, l’utilisation de Swift côté serveur a commencé à devenir une réalité. L’interêt croissant pour le langage par la communauté et l’investissement de groupes internationaux tels que IBM a produit des évolutions rapides et concrètes, qui permettent aux développeurs de déployer des solutions de façon rapide et efficace.
Swift étant un langage récent, les nouveautés sont à l’ordre du jour dans ce domaine et plusieurs bibliothèques et outils sont publiés chaque semaine.
Dans cet article, nous verrons quelles nouveautés concernant l’utilisation de Swift côté serveur ont été annoncées lors de la WWDC 2016 et un exemple pratique de comment déployer une application Kitura sur CloudFoundry en utilisant les nouveaux outils annoncés.
Avant de commencer, nous vous suggérons la lecture de l’article « Créons notre premier Web Server Swift », qui a été publié sur notre blog au mois d’avril.
Un glossaire pour démarrer
Pour les lecteurs qui commencent aujourd’hui à découvrir la plate-forme, nous allons introduire les technologies actuellement disponibles à l’aide d’un petit glossaire.
- Swift Package Manager (SPM) est le gestionnaire de dépendances pour Swift.
- Kitura est une solution, publiée par IBM, pour construire un server HTTP qui comprenne les règles de routage nécessaires à naviguer dans notre application Web.
- Un BuildPack est un package qui comprend toutes les dépendances nécessaires à l’exécution d’une application serveur dans une instance CloudFoundry cf. article précédent.
- BlueMix est l’offre PaaS de IBM, qui permet le déploiement et l’exécution d’applications serveurs. Plusieurs langages sont supportés : Java, JavaScript, Go et Swift, ainsi que différentes solutions de déploiement : CloudFoundry, Docker et OpenWhisk.
- libdispatch est la bibliothèque OpenSource publiée par Apple pour implémenter efficacement concurrence et parallélisme, qui permet d’abstraire la gestion des thread pools.
Les nouveautés
Les nouveautés concernant Swift côté serveur sont principalement trois ; nous allons les découvrir dans la suite de l’article.
1. Application macOS IBM Cloud Tools for Swift
IBM vient de publier une application macOS pour assister à la création, la construction et au déploiement d’une application serveur.
Le logiciel, nommé IBM Cloud Tools for Swift, permet de :
- créer des projets Swift pour serveur et fournit notamment 3 gabarits : un projet vide, un projet comprenant Kitura, et un projet démo plus complexe ;
- déployer, gérer et monitorer une application serveur sur BlueMix ;
- s’interfacer avec Xcode pour simplifier l’interaction entre le projet client et le projet serveur.
L’application est désormais disponible au téléchargement.
Malheureusement, à date (25/06/2015), les gabarits fournis par l’application n’incluent pas la dernière version de Kitura (0.18) : en effet, le gabarit BluePic utilise Kitura 0.15, qui n’est pas compatible avec Swift 3. Cependant, il est possible d’utiliser le gabarit « Kitura buildpack », qui nécessite la snapshot du May 3, 2016, disponible sur le site Swift.org.
2. Buildpack pour Kitura
IBM a finalement mis à disposition un buildpack pour Kitura qui permet de déployer facilement Kitura via CloudFoundry. L’avantage, ici, est surtout lié à la rapidité de préparation d’une instance. Pour un déploiement plus robuste, notre avis est d’utiliser tout de même des conteneurs Docker.
Le buildpack de Kitura est en tout cas très pratique pour créer une instance de développement qui comprend libdispatch, ce qui permet à l’application Web de servir des réponses en parallèle.
Notamment, dans le contexte serveur, libdispatch joue en rôle très important, car elle permet de profiter pleinement du multithreading et rapproche Swift de Go, où la gestion de la concurrence est incluse dans le langage.
3. Xcode en tant qu’IDE pour projets serveur
À partir du mois de mars dernier, Xcode permet (finalement) d’être utilisé en tant qu’IDE pour des application serveurs. Il est donc possible de créer des répertoires .xcodeproj pour Swift serveur et de les ouvrir par le biais de votre détesté aimé Xcode. Ainsi, nous pouvons lancer une instance de notre application sur localhost et l’inspecter en utilisant, par exemple, des breakpoints ou les commandes du débogueur.
La procédure est documentée à l’intérieur du Wiki Kitura, et le guide est disponible dans la page Building-your-Kitura-application-on-XCode.
Afin de démontrer la mise en place de l’outillage décrit, nous terminons avec un exemple de création et déploiement d’un nouveau projet en utilisant les éléments présentés dans l’article.
Création et déploiement d’un projet Kitura
- Installons la Swift Development Snapshot – May 3, 2016
- Définissons le parcours du toolchain dans notre path à l’aide de la commande
[java]export PATH=/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin:"${PATH}"[/java]
- Créons un nouveau projet Kitura en cliquant sur Create a project with a Kitura buildpack
- Accédons au dossier du projet
- Installons les dépendances du projet et executant
make
Xcode
Pour simplifier le développement, nous pouvons nous servir de Xcode 7 en tant qu’IDE de notre application back. Pour information, nous n’utiliserons pas Xcode 8, car incompatible avec le development snapshot du 3 mai 2016.
Les étapes à suivre sont les suivantes :
- Créons un fichier .xcodeproj à partir des dépendances spécifiées à l’intérieur du fichier
Package.swift
du Swift Package Manager ; pour ce faire, ouvrons la console dans notre projet et saisissons la commande[java]swift build -X[/java]
- Compilons les composants à l’aide de la commande
[java]make[/java]
- Démarrons Xcode 7.
- Depuis le menu Xcode -> Preferences -> Components, sélectionnons le Swift Development Snapshot 2016-05-03 et acceptons le redémarrage (sic) de l’IDE.
- Une fois Xcode redémarré, ouvrons le fichier .xcodeproj généré.
- Ensuite, nous devons modifier les chemins des bibliothèques pour les targets Kitura et KituraNet, en ajoutant
[java]$SRCROOT/.build/debug[/java]
à l’intérieur du réglage
LIBRARY_SEARCH_PATHS
des “Build Settings” (cf. image ci-dessous) ;
Nous pouvons ainsi exécuter le scheme Console Application et mettre en place des breakpoints pour inspecter l’exécution. L’application est lancée en local sur le port 8090 et sera donc accessible depuis le navigateur à l’adresse http://localhost:8090.
Une fois nos modifications opérées, nous pouvons déployer en utilisant l’application IBM CloudTools for Swift en cliquant sur le bouton « deploy ». Il est ainsi possible de visualiser le résultat dans notre navigateur en utilisant le lien disponible à l’intérieur de l’application.
Une démo visuelle, présentée lors du talk Going Server-side with Swift Open Source, de la WWDC 2016, est disponible à l’adresse suivante : https://developer.apple.com/videos/play/wwdc2016/415/
Conclusion
Comme prévu, les environnements pour réaliser une application Web avec Swift s’améliorent chaque jour et les outils deviennent de plus en plus robustes.
Des nouveautés sont attendues avec la finalisation de Swift 3.0, prévue pour l’automne. Cette dernière apportera notamment une version complète de la bibliothèque swift-corelibs-foundation, ce qui permettra d’avoir accès à un grand nombre d’API utilitaires.
En attendant, nous avons désormais accès à un outillage complet pour développer, construire et déployer une application Web en utilisant Swift.
Commentaire