ASP.NET Web Api vs Node.js
J'ai récemment commencé à connecter une plate-forme Web sur laquelle je travaille à d'autres systèmes assez complexes, principalement écrits en C #. La plupart de mon expérience est dans le développement web en PHP et JavaScript Et j'ai aussi une certaine expérience dans l'écriture de services web en WCF.
Malheureusement, j'ai eu beaucoup de difficultés à écrire des services WCF pour ma PHP Web, développement lent, configurations très (très) compliquées afin de bien répondre en JSON et de travailler RESTful et plus encore.
Naturellement, j'ai commencé à regarder d'autres technologies, une en particulier a attiré mon attention sur Node.js qui pourrait être parfait pour moi parce que j'ai beaucoup d'expérience en JavaScript et que je n'aurai plus besoin de mon serveur Windows. Mon autre option est bien sûr de continuer à écrire des services en C # mais de passer à l'API Web ASP.NET à la place. Le changement sera probablement beaucoup plus facile que de WCF vers Node.js.
Des réflexions ou suggestions à ce sujet? Quelqu'un a-t-il de l'expérience dans l'écriture de services Web dans Node.js et peut-il m'orienter vers un bon tutoriel? ou suis-je loin et je ne devrais pas du tout utiliser Node.js pour les services Web?
J'ai récemment commencé à travailler sur express.js. Permettez-moi de vous dire que ce n'est pas pour les timides. Toute la mentalité de "Si vous êtes déjà familier avec JS alors c'est la moitié de la bataille." ne pouvait vraiment pas être plus loin de la vérité. C'EST À DIRE. si vous êtes un mec hardcore devops comme moi.
J'ai un processus de construction unifié pour toute la construction de mon application asp.net, les rapports de test et de couverture, le déploiement, la gestion de la configuration et l'analyse de la qualité du code, tous configurés et automatisés. Il me faut littéralement 5 minutes pour configurer un processus de construction autour d'un nouveau projet et le faire tester, analyser, mettre en scène et expédier dans un environnement de production. (Et vraiment tous les développeurs du monde devraient en faire autant. Mais bon, à qui je plaisante?) Ensuite, il y a la surveillance, la journalisation, l'analyse des performances et le profilage. Encore une fois tous bien unifiés, orchestrés et gérés de manière centralisée.
Je ne dis pas que node.js/express.js n'en a pas, mais vous devez développer/apprendre un ensemble de services et de plateforme COMPLÈTEMENT NEUFS juste pour exécuter node.js.
Marteler un tas de code est une chose. Faire fonctionner un système de production sur une technologie étrangère est tout autre chose.
À moins que vous ne recherchiez des problèmes ahem je veux dire, défiez: D, respectez WebAPI. WebDeploy est un envoi divin.
BTW. Utilisez BasicHttpBinding avec votre point de terminaison WCF et obtenez PHP pour générer la classe client à partir du WSDL. Oui. Soap est votre réponse, pas un "repos plus facile à utiliser". Quelque chose comme https : //code.google.com/p/php-wsdl-creator/ . L'archivage du WSDL à partir du point de terminaison WCF vous permet également de suivre avec précision la signature de votre service et les changements de format. Il garantit la sécurité du type, et gère ser/de pour vous. Je me fiche de la laideur du message si je n'ai pas à le traiter. Et oui, je l'ai déjà fait avec PHP et python. Fonctionne parfaitement.
Après 10 ans de développement .net, je voulais utiliser Nodejs pour une application de taille moyenne. Je partage juste mon expérience.
Empreinte Windows
La plupart des nouvelles applications sont déployées dans le cloud aujourd'hui. Pour un Asp.net, nous avons besoin de fenêtres, bien que cela fonctionne sous Linux en mono, je ne suis pas assez confiant sur les performances. Le serveur Windows nécessite à lui seul plus de 750 Mo de RAM, je voulais déployer mon application sur un serveur de mémoire de 1 Go pour réduire le coût. Je voulais donc un petit OS. Linux a fait ses preuves. Dans ce cas, Linux gagne, d'où le nœud js. Cependant, je crois que Windows Nano Server peut résoudre ce problème dans un avenir proche. Maintenant .Net (core) fonctionne sur linux
.Net Core
Maintenant, le noyau .net est le prochain Node JS. Il a ouvert la porte pour que C # s'exécute sur Linux et Mac. Unity, Xmarin permet également de créer des applications et des jeux mobiles. Nous pouvons maintenant créer. bibliothèque standard nette pouvant fonctionner sur le noyau .net, le framework, xmarin et Unity.
Meilleur moment pour les développeurs C #.
Plus rapide à coder
Je peux bien coder en C # ainsi qu'en js. Donc ce n'est pas un problème pour moi ...
Clarté du code
C'est un domaine important. Lorsque la base de code grandit, tout devient complexe en JavaScript. Le javascript d'une personne peut ne pas être lisible par une autre personne. De nombreux projets .net ont une grande base de code, mais ils sont facilement lisibles et déboggables. Une équipe qualifiée normale peut mieux gérer les codes C #. Pour le nœud js, l'équipe doit être hautement qualifiée en JS. Le programmeur moyen peut ne pas lire correctement JavaScript.
Simplicité
nodeJS est très simple, pas de DLL, pas de GAC, pas de classes. C'est un code minuscule, vraiment minuscule. Mais la "clarté du code" est plus importante pour moi que le nombre de lignes que j'écris. Pour moi, la simplicité signifie facile à lire, pas plus rapide à coder. Je pense que C # est plus simple que JS lorsque la base de code se développe.
Performance
C'est discutable. Je sens que je peux écrire de bonnes applications de performance en utilisant à la fois la technologie.
Bibliothèques Open Source
Nodejs gagne ici. Trop de colis, c'est comme des tonnes de variétés dans votre petit déjeuner. C'était difficile pour moi de choisir ce que je veux. J'ai passé une semaine sur les bibliothèques ORM pour NodeJS, j'ai regardé Sequlizer, Sails, Knex, toutes sont super. Mais il y a des gens qui ont complètement recodé leur application d'un framework à l'autre. Cela montre clairement que chaque cadre manque quelque chose. Cela ne m'est jamais arrivé dans le monde .net. Je suis satisfait de Dapper et du Service stack ORM lite.
Mais nous avons plus de choix dans le nœud js, donc si nous choisissons correctement tout ira bien.
Docker
Docker est cool. Qui dira "je n'en veux pas"? C'est la principale chose que je voulais pour Windows. J'ai entendu Microsoft faire déjà quelque chose. Nous devons attendre et voir…
Portabilité de la plateforme
Les nœuds js peuvent fonctionner sur presque tous les systèmes d'exploitation, alors quoi? Je vais utiliser un type de système d'exploitation. AWS fournit très peu de variantes de Linux. Pour moi, peu importe le système d'exploitation dont mon application a besoin, je m'inquiète de son coût. Dans ce cas, Windows et Linux sont presque au même prix que les fournisseurs de cloud. La seule raison pour laquelle j'aime Linux est qu'il a une très petite empreinte. Windows ne l'est pas. Comme je l'ai mentionné, Windows Nano va résoudre ce problème. Je suis donc Ok pour exécuter mon application sur le serveur Windows.
Maintenant, le noyau .Net fonctionne sur Linux, donc dans Docker.
Enfin, j'ai décidé d'utiliser C # et l'API Web. La raison principale est mon expérience actuelle à ce sujet. Cependant, je reviendrai sur le nœud js pour ma prochaine application.
Plus besoin de regarder en arrière. Continuera avec C # pour le côté serveur et réagira JS pour le côté client.
Les deux plateformes ont leurs avantages et leurs inconvénients et, en fin de compte, les deux feront le travail.
Cependant, après avoir utilisé les deux, Node.js gagnerait haut la main pour la simplicité, la vitesse de développement/déploiement et les performances que vous obtenez hors de la boîte - et si cela ne sort pas de la boîte, il y a très probablement un - package pour cela .
Le nœud existe depuis quelques années maintenant, cependant, il n'a commencé que récemment à devenir plus populaire - à tel point que Microsoft a considérablement amélioré le prise en charge de l'outillage dans VS .
Qu'en est-il du besoin de portabilité multiplateforme? Que se passe-t-il si le besoin est d'avoir des services web api/REST qui peuvent être déployés sur les serveurs Windows et Linux?
WCF - Je ne pense pas qu'il puisse aller à Linux (encore) (mongo ??) WebAPI - Impossible d'aller à Linux (je pense ??) NodeJS - Runtime multiplateforme disponible. Code une fois déployé n'importe où. xyz - Qu'avons-nous d'autre qui puisse fournir tout cela?
Au moins à cause de cela, je suggérerais l'op pour NodeJS