Développer une application GoogleMap

Salut,

Meteor 1.3 (utilisable en beta) intègre(ra) mieux NPM, donc il sera utilisable correctement, avec import/require, package.json, 'npm install', etc..
Personnellement ce qui me gêne le plus avec meteor c'est le fait qu'il soit encore sous la v0.10.x, donc après build le mettre en production quand on a d'autres Apps à jour, pas pratique : Deux serveurs mini (ou virtualisation). Et les solutions de deploy proposées ne m'ont pas convaincu (puis je veux mes serveurs, surtout).
Sinon il m'a semblé que la communauté est quand même plus penchée sur React, personnellement c'est le choix que j'ai fait.

Je n'ai jamais touché googlemap, du coup je veux pas te dire de bêtises. Juste pour angular, j'utilise React en attendant de pouvoir bien tester angular 2 (mais je pense rester sur React quand même, ça me convient vraiment, et je préfère l'approche javascript/jsx). Ceci dit je ne l'ai pas encore tout à fait compris, j'imagine qu'il me réserve pas mal de surprises, je dois également tester redux. Finalement c'est un écosystème, react, une approche intéressante, mais plutôt complexe je trouve.

Une fois node installé sur ton serveur, il te faut un reverse proxy, personnellement j'utilise nginx. Il te faut le configurer en rajoutant une règle pour un domain/subdomain, qu'il écoute le port utilisé par ton app node (ici ton app meteor buildé). Tu trouveras des tutos dessus facilement sur google : 'reverse proxy nodejs nginx' par exemple.
Tu devrais utiliser pm2 également pour gérer la persistance des apps, leur lancement après un reboot serveur, crash d'une app, si tu veux les watcher, les logs, etc. Sa documentation est bien fournie. Un petit 'nginx pm2 node' t'amène rapidement ici : https://doesnotscale.com/deploying-node-js-with-pm2-and-nginx/

La base de données relationnelle est une bonne solution logique à ce projet.
Avec MongoDB (que j'utilise massivement), j'aurais fait une collection 'projects', chacun intégrant l'auteur en sous-document (avec le minimum d'information nécessaire), et une autre collection 'authors/members', avec beaucoup plus de données sur eux, la liste (aperçu très succinct) de leurs projets, etc. et ainsi faire une page auteur/membre dédiée.

Pour l'api entre react et googlemap, ceci ne peut pas t'être utile ?
https://github.com/tomchentw/react-google-maps

J'espère que ça t'a déjà aiguillé un peu :)
Bon courage !

Merci pour les conseils et pistes ! Ca m'aide bien.

c'est le fait qu'il soit encore sous la v0.10.x, donc après build le mettre en production quand on a d'autres Apps à jour, pas pratique : Deux serveurs mini (ou virtualisation)

Tu peux développer ? Je ne suis pas sûr d'avoir compris.

L'installation de Node sur un VPS me semble beaucoup plus simple, c'est peut-être que je n'ai pas entièrement compris la manière de faire avec Meteor... En tous cas, plus j'avance, et plus je suis géné par cette "surcouche" meteor.
Merci pour la piste pm2, c'est ce que je cherchais !

Concernant React, je vais réfléchir. Sur le papier cette approche me semble sympa, mais concrètement quand je regarde des morceaux de code je trouve ça un peu obscur... Pour faire une API qui communique avec googlemap, je pense ne pas pouvoir me passer de React ou Angular. J'avais déjà regardé la page Github react-google-maps, c'est un bon début. J'ai besoin d'afficher des markers à partir d'une liste de projet qui ont des coordonnées GPS, du geocoding, des infobulles, de contrôller l'affichage des projets avec un slider du type noUiSlider...

Pour la base de donnée, ok, je vais voir. Je suis déjà repassé à Node+Ghost+MySQL pour un petit site, je vais sans doute repasser à MySQL pour cette application voire PostgresSQL (si j'abandonne meteor).

Perso je conseille plus d'utilisé Totaljs que Meteor

Au final est-ce vraiment utile d'ajouter une surcouche à Node ?
Le principal avantage de Meteor est le temps réel... mais concrètement peu d'applications en ont vraiment besoin. Et on peut toujours s'en sortir avec Node+Socket.io voire Node tout seul si on se sent d'explorer Node un peu plus en profondeur.

Il se base sur la version 0.10.42 de nodejs pour la prochaine version meteor 1.3 (il est actuellement sur nodejs v0.10.40 actuellement me semble), et quand tu build ton app (t'as ton .tar.gz), tu l'envoie sur ton serveur (avec nodejs d'installé dessus), tu le dézippe, là il faut entrer dans le dossier et y faire un npm install pour installer ses modules, normal. Sauf que, par exemple, dans les dépendances tu as fibers, qui foire sur les versions récentes. Les app Meteor ne peuvent pas profiter de l'évolution de node.js pour le moment du fait qu'elles se basent sur la 0.10.
Donc si tu as node v4 ou v5 d'installé sur ton serveur (surtout si tu n'en a qu'un) ça pose problème vu qu'il lui faut la v0.10.x. Quand tu fais un "meteor deploy myapp.meteor.com", c'est sur un serveur utilisant nodejs v0.10 qu'il est déployé.

D'ailleurs c'est pourquoi tu es obligé de toute façon d'installer nodejs (et npm) sur ton serveur, tu n'utilise pas meteor sur un serveur de production, tu deploy ton app (build >> envoie sur serveur >> extraction/installation >> lancement).
Meteor reste interessant, mais pas encore assez mature. Il lui manque à minima de se baser sur une version récente de nodejs (voir d'avoir le choix), en découlerait déjà un système de deployement plus accessible pour les serveurs perso, qu'il soit intégré avec les autres app se basant sur une version récente. C'est également une bonne source d'inspiration pour faire évoluer ton framework maison.
Je n'ai fait que le tester car je n'utilise que des modules spécifiques, tu as une meilleure prise sur chaque détail, tu sais ce qu'il se passe, est capable de bien comprendre les erreurs derrière tout ça ("Meteor, it's magic"... sauf qu'un developpeur est un technicien, pas un apprenti magicien), apprends plus de choses (, te prend plus la tête), tu peux changer de modules si tu as une préférence ou si quelque chose est plus adapté à ton app, tu gère les versions, etc.

Pour react en fait je trouve qu'il gère pas mal ce qui m'attirait sur meteor. L'isomorphisme par exemple, car un composant react peut être utilisé côté client comme serveur (composant partagés donc), et ainsi rendre le contenu dès la connexion du client (donc pas juste le html sans l'injection js, ce qui augmente la perf puisque le build est envoyé après le rendu, react reprend ensuite la main pour revenir sur du SPA), et ainsi profiter du SEO (puisque le contenu y est pour le petit robot google), par la même occasion. react-router pour les routers, etc.
Tu peux utiliser socket.io pour le temps réel effectivement, et t'amuser avec webpack (+babel : ES6/JSX) pour le build.

Pour googlemap je regarderai à l'occasion.
Je regarderai totaljs par curiosité :)

ben react routeur est la pour router le front-end, si tu utilise node en tant qu'api les route que tu fait ne sont pas les routes de ton application, mais les routes qui donnent la data a ton app.

Ok merci, je comprends mieux comment déployer une app Meteor, et j'avais oublié qu'il se basait sur une vieille version de Node...
Sinon react-router ne s'utilise que quand on a pas de router côté serveur j'imagine ? (pas avec node par exemple)

J'ai pas souvent entendu parler de l'utilisation de node comme une API. Mais j'avoue que je ne vois pas exactement l'intérêt de ne pas profiter du router de Node (surtout quand on utilise express) pour l'App. Node ne renverrait que des tableaux Json ?
Si tu as un exemple github je suis preneur. C'est vrai que cette approche pourrait être assez adaptée à ce projet qui a une dimension "culturelle". Une API ne serait pas forcément une mauvaise idée. Mais router côté client... ça m'évoque des problèmes avec google...

J'ai pas souvent entendu parler de l'utilisation de node comme une API

serieusement?

Mais j'avoue que je ne vois pas exactement l'intérêt de ne pas profiter du router de Node

le router de node te recharge la page a chaque fois, les routeur des framework js ne recharge jamais la page et fonctionne en ajax.

Mais router côté client... ça m'évoque des problèmes avec google...

angular= google = ng-route / ui-router

Si tu as un exemple github je suis preneur

mean stack

fonctionne en ajax

Perso, je trouve sa dommage. On a une stack full JS, donc basé sur les events, et on utilise des requêtes HTTP, alors que notre stack nous met dans la main les websockets.

Bon c'est vrai qu'en Ajax on ne charge que le contenu... mais avec un bon système de cache...
Pour moi c'était un avantage d'utiliser le router de Node côté serveur, mais peut-être que je me trompe. J'ai essayé de faire une application avec Angular et des URL du style #!page... ça pose malgré tout pas mal de problèmes de référencement.

@tleb : donc pour toi l'ideal serait une app batie en deux parties client/server avec Socket.io ? Le client demande une page en émettant un évènement, le serveur répond et transmet du Json ?

Le problème c'est que je cherche aussi à trouver des exemples solides pour m'éviter de partir dans tous les sens. J'ai besoin de modèles pour m'aider à organiser mon code.

@tleb : donc pour toi l'ideal serait une app batie en deux parties client/server avec Socket.io ? Le client demande une page en émettant un évènement, le serveur répond et transmet du Json ?

Le client demande la page avec une requête HTTP, il recoit la page, mais qui ne possède pas de contenu. La page contient un script qui demande les infos au serveur à travers des WS. Le contenu peut aussi être fourni avec la page, si tu le souhaite.

C'est juste que je comprend pas pourquoi on utilise encore tant AJAX alors que les Websockets sont plus légères, fourni sur tout les navigateurs récents et optimisés pour le temps réel.

Après, ce n'est pas utile pour tout les sites.

Oui par websockets.
Perso j'ai fait un système avec promises, mais je vais te filer une version callback pour se focaliser sur le principe :

Client-side : Tu envoies un emit avec ton nom d'event, tes données et ta callback (ce qui doit se passer quand il reçoit les données)

Server-side : tu reçois les données nécessaires (ici pas besoin en faite, on veux juste récupérer la liste des membres, point), tu fais ce qu'il faut (ici check dans la BDD), puis tu envoies les données au client par la callback

J'utilise ça d'une manière différente, notamment pour éviter d'avoir une liste de socket.on de l'infini, pour organiser mon code et mes fichiers, etc. Mais je ne peux pas développer ici et maintenant, ça prendrait un tuto :s

Ok, c'est une bonne piste. J'ignore si cette méthode est particulièrement adaptée à mon application googleMap, mais au fond je cherche à faire des choix pour développer des applications en découvrant des nouvelles technos. Donc pourquoi pas.
Si je fais le point, je pourrais donc utiliser Socket.io pour envoyer des données au client après récupération dans la base Mysql ou autre. Puis React prend le relais côté client pour afficher ces listes. Il me faudrait donc également utiliser une API qui fait le lien entre React et Googlemap. Le plan vous paraît absurde ? :)

j'ai fait une app avec react express et les socket, j'ai utilisé le router d'express pour géré l'auth de mon application, donc du coup 2 url (login et app ) et toute l'application géré en socket est géré par le routeur de react avec une implémentation de flux, reflux exactement, comme architecture de l'application. ca marche super bien

Pour un petit projet comme ça, je vois pas l'interet utilisé React

Je ne suis pas sûr de voir l'intérêt non plus, c'est un choix qui dirige entièrement le code de l'app... C'est aussi ce qui me demande le plus d'efforts, j'ai déjà pas mal expérimenté Node express et un peu Socket.io, mais je ne connais rien à React ni à l'architecture Flux.

Si je n'utilise pas React : j'ai donc un router côté serveur, et mon code sera probablement moins organisé pour communiquer avec googleMap. Quelle serait la bonne alternative ?

Pour la taille du projet... le but est quand même de répertorier une multitude de projets d'architectes à travers le monde, on travaille sur une base de donnée depuis plusieurs mois. Donc il y aura du travail côté vues... la logique des composants me paraît assez intéressante pour ce projet.

A toi de choisir, sur quelle techno tu es à l'aise, aujourd'hui beaucoup de gens vont te dirigé sur React, alors que tu peux très bien faire ça comme tu le veux

A toi de choisir, sur quelle techno tu es à l'aise, aujourd'hui beaucoup de gens vont te dirigé sur React, alors que tu peux très bien faire ça comme tu le veux

absolument d'accord, il faut tester les tecnos se faire un avis perso et trouver la quel correspond le mieux, mais pas par rapport a une mode.
par exemple je deteste angular comme framework, mais pour l'appli que l'on developpe a mon taf, il n'y as rien de mieux que ce framework. On as une multitude de formulaire, avec des grosse validations de données, des tries dans des tableaux, du coup angular il a plein de truc deja present pour faire ca et pas react ( dommage d'ailleur ^^) faut choisir ta techno en focntion de ton projet et pas ton envie aussi.

Bien d'accord avec vous ! Mais je ne travaille pas dans le milieu pro du web : ayant moins d'exemples à disposition et ayant moins d'échanges avec des pros ou pationnés, je mets donc plus de temps à me faire une idée sur ces nouvelles technos et la façon dont elles doivent être utilisées. Donc merci pour vos conseils ça m'a permis de comprendre des choses importantes !

J'ai commencé les tutos React et je me pose encore une question :
Je constate que certains utilisent react côté client, en utilisant webpack-server pour créer un serveur de dev, ainsi que babel pour convertir la syntaxe JSX. Pour suivre ces tutos je n'ai pas utilisé webpack server mais le serveur http de Node, et je chargeais React et Babel côté client avec mes composants. En locurence, je suis parti d'un petit projet socket.io avec un client.html, sur lequel j'ai placé des script src="" pour charger React et Babel.

Mais d'autres semblent utiliser React côté serveur avec Node : ce qui permettrait apparement de se passer de babel, mais change le fonctionnement de l'application ?

Le code react semble rendu côté serveur avant d'être envoyé au client. J'ai un peu plus de mal à comprendre comment utiliser React côté serveur et quel intérêt ça peut avoir ?
Par exemple ce paquet npm :
https://github.com/mhart/react-server-example

Pour utiliser React côté client, même si j'utilise Node, suis-je sur la bonne piste ? (charger React directement sur les templates ou pages hmtl).

alors non, je t'arrete dessuite, le require n'est pas coté server forcément. j'utilise babe webpackl et react coté clientet j'utilise le require dans mes fichier, c'est juste que babel t'apporte la souplesse d'utiliser le require dans le front et donc de faire du dev plus propre de la meme facon que browserify.

apres si tu utilise node et le rendu server c'est different, ca te permet d'avoir une appli qui rox, du faite que le server envoie la vue deja créer avec les donnée deja chargé, mais dans se cas tu devrais utiliser une implementation un peut plus complexe de react qui est flux, avec notament reudx ou reflux pour gérer les actions de tes composant, les stores et le refresh de tes datas.

Ok, merci je vais expérimenter !
Apparement les API googlemap sur npm peuvent rendre côté client ou serveur.
https://github.com/istarkov/google-map-react
Dommage ça m'a l'air difficile de trouver des choses plus simples. Mon but est d'expérimenter React côté client. Premièrement d'afficher une liste, puis d'afficher une liste de markers sur une carte (level supérieur...)

Chaque tutoriel présente une façon différente de charger/utiliser React avec telle ou telle dépendance supplémentaire... babel-core fait tourner React mais uniquement la version 5.8.23... bref c'est pas encore ultra limpide je trouve. Je vais me taper la doc officielle... A+

J'ai pu mettre en place une bonne base avec Node, Socket et React côté client.
Mais le référencement m'inquiète de plus en plus.

et ainsi profiter du SEO (puisque le contenu y est pour le petit robot google

J'ai pas l'impression que react-router soit fait pour le référencement, au contraire... Bon ok on a des éléments html, mais on a pas des vraies URL. Je peux voir si Google a évolué de ce côté là, mais pas pour React à mon avis ! :)

Du coup, si cela ne me convient pas, je vais être obligé de "pré-rendre" côté serveur. Ce qui remet un peu en question React au final... Si j'ai bien compris, le choix au fond est de choisir entre React avec l'architecture Flux ou un système plus classique MVC ?

Bon, cette fois j'arrête ! Merci à tous, déjà la petite app que j'ai pu mettre en place avec socket.io et React me laisse imaginer plein de nouvelles solutions...

Je disais que ses composants étaient utilisés, pour le rendu serveur (rendu initial), mais react-router en lui-même ne suffit pas :)
Il faut utiliser notamment, comme l'a indiqué Defy, redux (pour ma part, avec react-redux : http://redux.js.org/docs/recipes/ServerRendering.html).

Bon courage en tout cas !