Avis Project Express / Vuejs Socket / route
Bonjour a tous,
Bon je vais etre un peu verbeux, car meme l'usage des frameworks ici nommé n'est pas encore statué donc tout avis est bon à prendre.
Pour l'instant le projet oscille entre
en back : Sails (tres tres bien mais too much pour de l'API REST) ,
Loopback ( Je le trouve super, juste peur du manque de communauté/interet autour),
ExpressJS (Les deux arugments ci-dessus m'ont fait partir sur express et j'ai deja un peu bossé dessus)
en front : Vuejs ( Decouvert ici, plus simple , plus rapide, plus leger, que demande le peuple),
React, Angular2 ( Alors je sais pas, ils ont l'avantage de pouvoir etre utilisé pour Ionic ou ReactNative , ce qui vu le temps qu'il faut pour bien maitrisé un framework n'est pas negligeable, mon hesistation porte plus sur le retour sur investissement
de mon apprentissage, pour de futur projets / emplois....)
Voila, j'avais prevenu que je serai un peu verbeux ^^ , des avis sont là bienvenus, mais je rentre dans le vif du sujet.
Je souhaiterais avoir un eclairage sur l'usage des sockets
Je suis parti sur un serv API REST avec express et un coté client avec vueJs.
Me voila parti avec les classics bodyparser, cookieparser etc...
et je fais mumuse avec mes sockets pour reprendre la main (je ne fais plus que du php depuis 6 mois)
et soudain Une question pourquoi BodyParser? pourquoi le Router d'Express?
Pourrais-je tout faire en Socket ?
Remplacer
routes
.post('/addProduct', ctrlData.addOriginalProduct)
et
ctrlData = {
addOriginalProduct: function (req, res) {
Ingredient.find({}, function (err, ingredients) {
res.status(200).json({
data: {
message: 'ingredients!',
ingredients: ingredients
},
});
});
}par
socket.on('list', function () {
Ingredient.find({}, function (err, ingredients) {
socket.emit('renderList', ingredients)
});
})Bon c'est la meme chose, mais du coup peut-on TOUT concevoir avec des sockets? Est-ce judicieux? Plus ou Moins Secure?
Bref j'ai sentiments de ne pas voir un truc important car là si je m'ecoute je recommence et conçois le tout en socket.
Et surtout comment peut organiser ses sockets sur des fichiers differents? genre des controllers (avec les namespaces ?)
Merci a vous
10 réponses
Ok , j'ai matière a reflexion, du coup et..... je sais plus.... ;)
Je vais tester / recommencer / tester, bref perdre un peu de temps pour me fixer.
Merci a vous
C'est une mauvaise idée de tout concevoir en socket.
Il ne faut pas oublier ce qu'est un socket. C'est avant tout une notion qui provient du réseau. Ça sert à réaliser des connexions bidirectionnelles, ni plus, ni moins.
Les sockets n'ont absolument pas été créé pour ta demande... Renseigne toi sur les sockets.
Pourquoi le Router d'express? Parce qu'une application web communique à travers le protocole HTTP.
Merci d'avoir repondu.
J'insiste un peu mais dans les faits en quoi est-ce mal / bloquant?
les requetes en POST, PUT etc... ne pourra-t-elle pas etre completement remplacé par les sockets?
En fait mon interrogation c'est pourquoi les sockets ne pourraient pas completement remplacer les requetes ajax?
Vuejs aura son router client et ferait des emit au server au lieu de faire des post ou autres.
Et donc dans ce cas plus besoin du router d'express...
Je ne compte pas réinventer la roue, mais plutot comprendre pourquoi ne pas utilisé l'avion ;) .
Merci
http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/
Tu as ta réponse vers la fin (à partir de "Together the graph also shows that WebSocket is a more efficient protocol than RESTful HTTP. But does that mean it will replace RESTful HTTP ?")
Alors avant tous, si tu compte utiliser vuejs, pourquoi ne pas faire du rendu server et utiliser le routeur de vuejs plutot que celui d´express? ca permet de tire avantage du routeur en ajax et couplé au rendu server avoir une app qui rox sa mere.
Salut,
Si tu es le seul à utiliser l'API (qu'elle n'est pas faite pour d'autres services), je ne vois pas le problème à utiliser des websockets. Aussi, si tu n'as pas besoin d'un support de navigateur vraiment large, les websockets suffisent, pas besoin de socket.io.
Bonsoir,
Merci Emix pour le lien certains arguments sont en effet pertinents, betement ce qui me derange le plus et de ne pas avoir de status en retour (en fait ça me plait carrement pas ).
Je vais quand meme poussé mes recherches, d'ailleurs sur ce meme lien on trouve en fin de commentaire http://highscalability.com/blog/2016/12/13/a-scalable-alternative-to-restful-communication-mimicking-go.html
Je pense, peut etre à tord que les choses vont peut-etre ce standardiser pour d'autres utilitées que le Chat ou les Notifs.
Defy, j'ai bien decoupé mon projet en deux partis distinct donc le router front c'est du vuejs , le router Express
ne prend en charge que les requete POST , DELETE etc...( Et les sockets ^^)
Je ne fais que rarement (jamais en fait) du rendu via le server, que du REST (habitube je pense, et surtout mon backend reste utilisable voir réutilsable par n'importe qu'elle framework front ) , d'ou d'ailleurs mon interrogation avec React & Angular pour toucher la parti Mobile d'ailleurs si vous avez des retours, faciltées d'apprentissages / efficacitées sur ces frameworks , je suis prenneur car le seul framework front que je connais pour l'heure c'est angularJS.
Vuejs c'est un peu too much de dire que je le connais, c'est plutot du speeddating ^^.
C'est pour ça, le front sera forcement douloureux car nouveau, et je ne suis pas bloqué sur une idée bien precise pour l'heure.
Et du coup , oui j'en reviens a ma petite gene sur Sails car une framework MVC sans vu a gerer bah ... c'est bizarre non ? ;).
Mais bon, merci a vous pour la discussion , je suis toujours pas fixé mais j'avance.. ou pas .. (j'avais prevenu que j'étais verbeux ^^)
Merci
Bonjour Tleb,
Peux tu developper cette parti
"Si tu es le seul à utiliser l'API (qu'elle n'est pas faite pour d'autres services)"
En quoi une Api multiUtilisateur pourrais me poser probleme ?
Je sens que c'est peut etre ça que j'ai loupé ^^
Merci
Je travaille avec react depuis 1 an, et franchement, c'est vraiment une lib top, très simple a prendre en main, mais très verbeuse comparé autre framework (react est bien une lib et non un framewok) couplé a redux, nodejs pour le rendu serveur ça envoie du steak.
Pour info actuellement je bosse sur un projet avec une API REST nodejs / express et react sur un serveur nodejs distinct pour avoir le rendu serveur donc mon service REST est découpé du front et je profite du rendu serveur quand même.
Je suis aussi en train de me former a angular2, et je dois dire que typescript ça solidifie l'architecture de l'application de ouf quand même, avec les interfaces et le typage.
Le problèmes avec le websocket, c'est qu'il n'y a pas de convention de communication comme il peut y avoir avec l'HTTP et la méthode REST. Les websockets c'est bien, mais si tu veux ouvrir ton API au monde (pas juste l'utiliser sur ton site), il te faut une API REST et non du websocket.