Fermer le menu
 

Perfect : du Swift « côté serveur »

Anthony Nelzin-... | | 08:30 |  38

Nombre d’applications ne font rien d’autre que de présenter des données envoyées par un serveur. Le développeur sait qu’il devra écrire le front-end, c’est-à-dire son application iOS, en Objective-C ou en Swift. Mais il n’a que l’embarras du choix pour le back-end, c’est-à-dire le composant serveur. PHP, Python, RoR… mais pourquoi pas du Swift aussi ? C’est l’idée derrière le projet Perfect.

Perfect fournit un framework permettant de développer des services REST en Swift, et donc d’utiliser — du moins en théorie — un seul et même langage pour le back-end comme le front-end. Il fonctionne avec son propre serveur HTTP, ou sous la forme d’un module FastCGI avec Apache 2.4, et offre un mécanisme de chargement des modules Swift au démarrage, ainsi qu’une interface entre ces modules et un système de mise en forme du type Mustache.

Le premier de ces modules Swift est celui proposé par Perfect, qui contient notamment un connecteur vers les principaux systèmes de gestion de base de données, des API pour la manipulation de données et la gestion des connexions au réseau, ou encore un encodeur/décodeur JSON. Car application et serveur s’échangent leurs données avec des fichiers JSON (ou XML) — de ce point de vue, Perfect ne réinvente pas la roue.

Perfect ne peut réussir qu’à condition d’être compatible avec GNU/Linux… ce qui n’est pas encore le cas. PerfectlySoft promet toutefois que ce sera le cas dès qu’Apple tiendra sa promesse de rendre Swift open-source. En attendant, les différents composants du projet sont déjà disponibles sur Github : la librairie Perfect, le serveur, et quelques exemples.

Catégories: 
Tags : 

Les derniers dossiers

Ailleurs sur le Web


38 Commentaires

avatar Mrleblanc101 23/11/2015 - 08:32 via iGeneration pour iOS

Swift sera open-source quand FaceTime sera multiplateforme (pour ceux qui se rappel de celle-là...)

avatar Mrleblanc101 23/11/2015 - 08:33 via iGeneration pour iOS

@Mrleblanc101 :
Pour les autres aller revoir la présentation de l'iPhone 4 par Steve Jobs

avatar patrick86 23/11/2015 - 08:55

@Mrleblanc101 :

Sauf que FaceTime ouvert — et non multiplateforme, nuance — n'était pas dans le cahier des charges initial du système qui n'a donc pas été conçu de sorte à permettre cela.

C'est Steve Jobs qui avait décidé quasi au dernier moment et sans consulter les ingénieurs, que FaceTime devrait être ouvert.

"Pour les autres aller revoir la présentation de l'iPhone 4 par Steve Jobs"

Et pour vous :
https://developer.apple.com/opensource/
http://www.apple.com/opensource/



avatar PiRMeZuR 23/11/2015 - 09:17

Pas la peine de justifier Apple, il faisait de l'humour et c'était pertinent car Apple fait dans l'open source uniquement quand ça l'arrange.

Quant à la petite histoire du FaceTime pas fait pour être ouvert, elle est difficile à avaler. Apple n'a jamais eu de problèmes pour revoir de fond en comble un composant ou une partie de ses systèmes. Ouvrir FaceTime n'était pas un problème technique mais une question de volonté. Et il est probable que Jobs n'était plus autant convaincu de son intérêt quelques semaines après cette présentation (qu'on l'en ait dissuadé ou non).

avatar patrick86 23/11/2015 - 12:22

"Pas la peine de justifier Apple"

Ben nan, pourquoi faire !?

"Apple fait dans l'open source uniquement quand ça l'arrange."

Exactement !

Apple fait ce qu'elle juge être dans son intérêt à elle.

"Quant à la petite histoire du FaceTime pas fait pour être ouvert, elle est difficile à avaler."

Dans le fond je m'en tamponne un peu, hein.

avatar C1rc3@0rc 23/11/2015 - 14:23

Quel systeme de messagerie de grande diffusion est opensource?

C'est que mine de rien un systeme de messagerie/visoconference opensource ce serait aussi chiffré et ca utiliserait l'architecture P2P, donc pas legal selon la NSA et ses vassaux. CQFD

Apres, la remplacer un m@#$% comme PHP par une API base sur Swift qui va se placer en concurrence de NodeJS, ça embête personne.

avatar oomu 23/11/2015 - 14:42

"Quel systeme de messagerie de grande diffusion est opensource?"

aucun. (enfin heu.. y a imap :) )

il existe Jabber / xmpp qui n'est dans l'intérêt d'AUCUN acteur commercial de répandre et se baser dessus.

Google a fait mine un temps de créer une passerelle XMPP pour Google Talk, sans la rendre pleinement fonctionnelle, puis abandonnée quand google talk fut réinventé (hangout).

Bref, c'est mort, car il est mieux de créer des petits ilots propriétaires et en compétition pour créer de la différenciation entre acteurs/constructeurs/fai/marque de lessive, etc.

sinon, SIP (l'autre SIP, pas celui de El Capitan), xmpp etc. Utilisés par ci par là par l'industrie (dont apple) pour créer leurs plateformes propriétaires.

Les temps à la con genre usenet et autres imap c'est fini : place à l'isolation. (même si j'apprécie beaucoup la qualité de facetime et iMessage, ils sont la continuité de l'isolation et propriétarisation qui complique tout. et non je n'ai pas envie de mettre pour autant tous mes oeufs dans whatsapp ou skipy le grand gourou)

-
"donc pas legal selon la NSA et ses vassaux. CQFD"

c'est totalement légal. La NSA n'est pas un parlement secret omnipotent sur les USA et le Monde ni la NSA est un seigneur féodal dominant des vassaux avec des serfs.

C'est légal aux USA. Même si la NSA fait un puissant lobbying pour dire "ça nous complique notre job ! si vous l'interdisiez, notre vie serait beaucoup + simple et pourrait rentrer boire l'apéro + souvent".

qu'importe, pour l'heure c'est farpaitement et parfaitement légal aux USA et en _France_

(et pour remettre le génie dans la bouteille tout en étant "libéral capitaliste pro-marché ouvert démocratie vive les entreprise et la sécurité et le commerce en ligne et télétraval" ça va être chaud. je me marre déjà.)

-
"Apres, la remplacer un m@#$% comme PHP par une API base sur Swift qui va se placer en concurrence de NodeJS, ça embête personne."

ça m'embêterait pas du tout :)

avatar byte_order 03/12/2015 - 17:08 (edité)

> Quel systeme de messagerie de grande diffusion est opensource?

J'imagine qu'on parle de messagerie instantannée, ici, hein.

IRC
Jabber/xmpp + SIP
Telegram Messenger
TextSecure / Signal

Dans le cas de Telegram, le protocole est open source ainsi que le code source des clients Android/iOS & Web. seule *l'implémentation serveur* de telegram.org n'est pas open source. Reste qu'en théorie, connaitre les détails du protocole et la façon dont les clients intéragissent avec doit permettre à quiconque d'implémenter son propre serveur.

Mais à ce jour, je n'ai pas connaissance de projets open source dans ce sens.

Y'a des projets P2P open source prometteurs, tel que TextSecure/Signal, mais pas encore avec la solidité prouvée de IRC, Jabber ou Telegram.

Et aucun système de videoconférence open source à ma connaissance.

avatar Mrleblanc101 23/11/2015 - 10:07 via iGeneration pour iOS

@patrick86 :
Et tu tien ça de quelle source ? À oui, aucune...
Je sais bien qu'apple à des projets open source... Certain même très gros (webkit), mais après tant d'attente à propos de Swift "Open source" les espoirs sont rendu très mince de voir cette promesse se concrétiser ! Surtout avec Microsoft qui veux porter les apps iOS sur Windows ça deviendrait drôlement trop facile...

avatar BeePotato 23/11/2015 - 10:15

@ Mrleblanc101 : « Et tu tien ça de quelle source ? À oui, aucune... »

Ben pour le fait que Steve Jobs parlait d’un FaceTime ouvert et non multi-plateformes, il tient ça de la source que tu conseillais d’aller consulter : la présentation où il a dit ça. ;-)

« mais après tant d'attente à propos de Swift "Open source" les espoirs sont rendu très mince de voir cette promesse se concrétiser ! »

Ben pourquoi ?
Il n’y a pas eu énormément d’attente, puisque ça n’a été annoncé qu’il y a 5 mois, avec comme cible un vague « d’ici la fin de l’année » — cible qui n’a donc pas encore été ratée.
Et Chris Lattner a récemment confirmé que c’était toujours sur les rails.

Si on attendait de ne plus être dans le cadre de ce qui a été annoncé avant d’être pessimiste ? ;-)

« Surtout avec Microsoft qui veux porter les apps iOS sur Windows ça deviendrait drôlement trop facile... »

Pas beaucoup plus facile, en fait. Le plus dur reste l’implémentation par Microsoft d’une bibliothèque offrant les mêmes API que Cocoa Touch.

Cela dit, j’espère bien que ce projet de Microsoft va foirer. Même si pour l’instant le danger qu’il représente pour iOS est faible, on n’est jamais à l’abri d’un retournement de situation.

avatar Un Type Vrai 23/11/2015 - 13:17

"Cela dit, j’espère bien que ce projet de Microsoft va foirer"

L'objectivité de la réponse est passée à 0%...

avatar BeePotato 23/11/2015 - 14:12

@ Un Type Vrai : « L'objectivité de la réponse est passée à 0%... »

Ça, c’est ce qui arrive quand on lit sans réfléchir à ce qui est écrit : on se met à prêter au rédacteur des défauts qu’il n’a pas. :-P
En sortant, qui plus est, des remarques totalement loufoques : le reste de ma réponse reste parfaitement objectif, faisant dans le factuel ; et la dernière partie, qui dit en liminaire qu’elle va parler de mes espoirs, est donc explicitement non objective, sans surprise pour le lecteur qui en a été prévenu dès les premiers mots. ;-)

avatar BeePotato 23/11/2015 - 14:15

Comme je suis d’un naturel sympa, je vais t’épargner un instant de réflexion en explicitant la raison pour laquelle j’espère que ce projet ne rencontrera pas de succès. Ça tient en quelques mots : le risque d’appropriation de l’API.
Tu en as sûrement déjà entendu parler, voire l’as vécu. Si quelqu’un réimplémente les API d’une plateforme et remporte grâce à ça un gros succès, le créateur de la plateforme d’origine peut se retrouver dépossédé de fait du contrôle de ces API et de leur évolution (et donc du contrôle de sa plateforme).
En effet, les développeurs seront tentés de rester compatibles avec les deux intervenants et seront moins prompts à adopter les nouveautés tant qu’elles ne sont pas implémentées des deux côtés. Pire : le nouvel intervenant, s’il a acquis un poids important, peut commencer à proposer ses propres évolutions, divergentes. Ou au moins des extensions « propriétaires », qui, si elles sont intéressante, pourraient conduire peu à peu les développeurs à abandonner la plateforme d’origine qui en est dépourvue.
C’est le même mécanisme qu’on a vu à l’œuvre avec le web et Internet Explorer — et on a pu voir à quel point il a été difficile de s’en sortir.

Alors certes, comme je l’ai dit, le risque de voir ce cas se produire avec l’adoption des API iOS par Microsoft peut paraître faible au vu des positions actuelles de Microsoft et d’Apple sur le marché des engins mobiles. Mais, comme je l’ai dit aussi, on n’est jamais à l’abri d’un changement de situation, d’autant que cette adoption d’API serait justement destinée à booster l’intérêt de Windows pour les utilisateurs.

C’est pour ça que, dans l’intérêt de l’indépendance de la plateforme iOS, j’espère que ce projet de Microsoft ne rencontrera aucun succès.
En toute subjectivité, tout en ayant auparavant présenté en toute objectivité la raison de cet avis. ;-)

avatar oomu 23/11/2015 - 14:50

"Pas beaucoup plus facile, en fait. Le plus dur reste l’implémentation par Microsoft d’une bibliothèque offrant les mêmes API que Cocoa Touch.
"

il est peu probable que cela aille loin.

Déjà parce que c'est extrêmement difficile (Apple contrôle le planning d'ajouts et modifications à Cocoa), qu'il faut pas simplement reproduire le comportement (qui n'est pas formellement normalisé comme l'était son ancêtre Openstep) ET LES BUGS (qu'apple ne détaille pas en long et en large dans de jolis documents prêt à lire)

Ensuite parce que légalement c'est une zone grise en cours de réflexion suite à l'affaire Google vs Oracle sur java.
Pour l'heure, Oracle a gagné, ce qui donnerait un argument à Apple pour planter Microsoft si cela lui prenait.

-
et enfin, à titre ULTRA PERSONNEL MEGA subjectif, oui je pense qu'il faut que MS échoue sur ce projet précis.

C'est le même danger que quand Sun tentait de faire de Java un standard et MS tentait d'en faire un dérivé propriétaire au seul Windows: l'appropriation.

Imaginons que la version MS devient populaire
et que de grandes apps super géniales et populaires s'en servent
et bien Apple se retrouvera obligée d'en tenir compte si elle veut corriger d'éventuels bugs de Coca ou le modifier pour de nouvelles approches et technologies.

La rendant à NOUVEAU (comme au temps de CARBON et Foundation) dépendantes des stratégies des éditeurs (par exemple Adobe et...ho... Microsoft) pour suivre.

Apple a tout fait pour empêcher la création de Frameworks parallèles à Cocoa sur IOS pour pouvoir justement garder le contrôle de sa propre plate-forme et pouvoir faire migrer les développeurs selon SON rythme à elle.

Elle empêchera de toutes ses forces de perdre cela. C'est carrément le principal outil pour continuer à vendre des appareils iOS. Vital.

Il m'apparait donc que le copyright sur API est inéluctable. Car cela va correspondre à une extension de la propriété des entreprises informatiques. très tendance.

avatar oomu 23/11/2015 - 14:54

je rajoute:

on voit face à ce genre de considérations pourquoi une base de bugs est elle aussi un secret thermonucléaire à protéger de très près.

L'ouverture du logiciel libre (les bugzillas etc) n'est pas seulement sur le code, mais aussi la transparence de leur développements et l'accès énorme qu'on a à ce que j'appellerai grossièrement des "meta-infos" sur le projet lui même. Très important.

Mais vous ne pouvez pas demander cela d'un constructeur comme Apple. C'est lui demander de scier ses pattes. En tout cas, pas sur Cocoa.

-
Pour revenir au propos + général d'une api cocoa par MS,

Facetime et autre Hangout, Skip etc, oui l'industrie pourrait faire un effort, parce qu'il est grotesque d'en être encore à valoriser et capitaliser sur ce qui devrait maintenant devenir de l'infrastructure à la GSM.

Mais Apple se doit d'être ultra-bornée sur Cocoa.

avatar BeePotato 23/11/2015 - 15:20

@ oomu : « il est peu probable que cela aille loin. »

En effet, et heureusement.
Mais on ne se méfie jamais assez. Après tout, Microsoft nous a déjà prouvé plusieurs fois qu’il n’y avait pas besoin de produire un clone parfait pour prendre le dessus sur l’original. Le « good enough » guette…

« C'est le même danger que quand Sun tentait de faire de Java un standard et MS tentait d'en faire un dérivé propriétaire au seul Windows: l’appropriation. »

C’est ce que j’ai déjà expliqué, oomu. Mais c’est gentil tout de même de te joindre à la conversation. ;-)

« La rendant à NOUVEAU (comme au temps de CARBON et Foundation) dépendantes »

Foundation, ça va depuis toujours avec Cocoa et c’est actuellement dans Mac OS et iOS, et ça n’a jamais posé de problème. Tu dois confondre avec autre chose (mais je ne vois pas quoi).

avatar oomu 23/11/2015 - 18:05

@BeePotato

"C’est ce que j’ai déjà expliqué, oomu. Mais c’est gentil tout de même de te joindre à la conversation. ;-)"

en effet vous l'aviez expliqué avant.

-
"Tu dois confondre avec autre chose (mais je ne vois pas quoi)."

En fait je pensais à Core Foundation uniquement comme une bibliothèque pour les applications hérité de Mac Os. Or, CF est la base commune qui a été écrite pour les apps cocoa et carbon pour permettre aux deux genre d'apps de fonctionner ensemble.

avatar BeePotato 24/11/2015 - 09:33 (edité)

@ oomu : « En fait je pensais à Core Foundation uniquement comme une bibliothèque pour les applications hérité de Mac Os. Or, CF est la base commune qui a été écrite pour les apps cocoa et carbon pour permettre aux deux genre d'apps de fonctionner ensemble. »

En effet, Core Foundation est très activement utilisé par les applications Cocoa (et Cocoa Touch).
D’autre part, Foundation n’est pas du tout la même chose que Core Foundation : le second est une bibliothèque de relativement bas niveau avec des API en C, tandis que le premier est une bibliothèque de niveau plus élevé (reposant en partie sur Core Foundation, d’ailleurs) avec des API en Obective C.
Foundation nous vient de NeXTStep. Core Foundation a été développé spécifiquement pour Mac OS X (avant d’être réutilisé dans iOS et ses dérivés).

avatar patrick86 23/11/2015 - 12:32

@Mrleblanc101 :

Juste pour compléter la réponse de BeePotato, concernant la raison pour laquelle FaceTime n'est toujours pas ouvert, MacG avait évoqué la chose il y a plusieurs mois.

avatar fgirardey 23/11/2015 - 09:33 (edité)

Je suis curieux de voir un benchmark face à Node.js parce que Node a quand même une sacré avance niveau communauté avec NPM alors si les performances ne sont pas largement meilleures je ne vois pas l'intérêt…

avatar BeePotato 23/11/2015 - 10:48

@ fgirardey : « si les performances ne sont pas largement meilleures je ne vois pas l’intérêt… »

L’intérêt peut se trouver dans les préférences du développeur en termes de langage. Je sais, c’est mal de trop se laisser influencer par ça, mais ça existe tout de même (et Swift a quelques atouts à mettre en avant dans ce domaine, comme une gestion bien propre des chaînes de caractères, par exemple).

Mais surtout, l’intérêt peut être se trouver dans le partage de bouts de code entre client et serveur, ce qui est évidemment plus facile quand les deux sont écrits dans le même langage.

Il peut donc y avoir un intérêt pour certains, même sans considérer les performances. Il n’est pas absolument nécessaire qu’il y ait un intérêt évident pour tout le monde et que Node.js se retrouve balayé de la surface de la planète. :-)

avatar fgirardey 23/11/2015 - 13:29

Au contraire je trouve tes arguments totalement valables, les préférences des devs c'est hyper important surtout quand ton business prend de l'ampleur, il faut pouvoir être capable de trouver des développeurs.

Ma préférence pour Node.js se fait à ce niveau car il faut avoir une certaine experience pour faire une API REST béton, surtout quand il faut maintenir à la fois le back et le front, et je pense aujourd'hui qu'il y a beaucoup plus de devs JavaScript que des devs Swift, même si le langage est clairement prometteur.

avatar BeePotato 23/11/2015 - 14:19

@ fgirardey : « et je pense aujourd'hui qu'il y a beaucoup plus de devs JavaScript que des devs Swift »

Aujourd’hui, c’est sûr, il n’y a pas photo. Je me projetais dans l’avenir en parlant de l’intérêt de ce truc — bien obligé, puisque pour pouvoir tourner à grande échelle, ce projet doit attendre la disponibilité de la version Linux de Swift (ainsi, sûrement, qu’une bonne phase de débugage avec la première sortie de cette version).

avatar fgirardey 23/11/2015 - 14:21

Ah oui tu as raison, mieux vaut voir à long terme là, je pensais qu'il était déjà utilisable en prod sur du Linux ^^‘

avatar Un Type Vrai 23/11/2015 - 13:20

"parce que Node a quand même une sacré avance niveau communauté avec NPM"

Je ne vois peu de projet node.js chez mes clients...
Ruby avait aussi une grosse communauté ...

Bref, il n'y a pas de lien entre la communauté et la pérénité d'un langage

Et puis, entre "faire parler de lui" et vraiment être omniprésent, il y a aussi une marge.

Pages