Discussion :

[Squadzz]

Bonjour !

J'ai comme projet perso de créer un site d'annonces immobilères (pour un pays étranger)

J'essaye de trouver le language le plus approprié, mais j'ai un peu de mal à faire la part des choses.

Il y a 7ans j'ai appris le java en cours, mais je suis rapidement passé vers python pour sa communauté et pour son coté productif...

Cependant je préférais repartir vers un language typé, et crossplat form. (Je pense partir sur un serveur Apache sous Centos avec une BDD de type PostgreSQL ou MySQL)

J'ai essayé de me documenter en lisant les articles ci-dessous :

- https://en.wikipedia.org/wiki/Progra...pular_websites

- https://www.toptal.com/back-end/serv...de-php-java-go

J'ai trouvé le choix de LeBonCoin (language C couplé au php pour les forms) vraiment intéressant.. D'avoir un language bas level, pour maîtriser au mieux les performances I/O..

A coté j'ai vu que Craiglist était partit sur du Perl/CGI sûrement pour des raisons similaires à LeBonCoin.


Quel serait le language le plus intéressant d'un point de vue :

- Maîtrise des performances, pour avoir un site qui s'affiche et execute les requêtes rapidement ?

- Dans l'évolution du site, et de sa scalabilité

Je n'ai pas dev depuis un moment, mais j'ai déjà touché au C, C#, Python, Java.. avec des connaissances plus théoriques que pratique.

J'aimerais avoir un peu votre avis sur ce sujet, sans partir sur le débat "prend celui où t'es à l'aise" si possible

C# .net Core on Linux ? Go ? C ? Java ?

C'est un projet perso, mais c'est surtout une grande curiosité sur leurs choix de language backend.. si vous avez des liens intéressants, n'hésitez pas !

Cordialement,

[mathieu]

un point à aussi prendre en compte est le budget annuel que vous avez prévu pour ce site.
pour 30 € par an vous trouverez des hébergements de base qui supportent PHP, Ruby ou Python. Alors que si vous utilisez un autre langage, vous aurez besoin d'un serveur dédié qui est plutôt autour de 600 € par an.

[Squadzz]

Hello Mathieu,

Je pensais lancer le site à partir de mon serveur dédié kimsufi, après à voir en fonction de son évolution

J'ai surtout du mal à savoir quel language choisir par rapport à l'évolution du site et traffic que pourra engendrer le site :-/

Cordialement,

[Marco46]

Quel serait le language le plus intéressant d'un point de vue :

- Maîtrise des performances, pour avoir un site qui s'affiche et execute les requêtes rapidement ?

- Dans l'évolution du site, et de sa scalabilité

JavaScript et donc Node.js.

C'est la plateforme qui avale le plus de requêtes par seconde et qui démarre le plus vite. A voir après si tu pars sur une archi monolithique ou en micro services.

Je t'invite à regarder cette présentation :

[Squadzz]

Salut Marco,

J'avais commencé à regarder un peu Nodejs, ça semble plutôt intéressant ! Par contre je le vois souvent couplé à du mongodb que postgre, ça pourrait être intéressant d'un point de vu perf ?

Et par rapport au client side.. j'ai vu qu'il y a un paquet de frameworks.. t'aurais quelque chose à me conseiller ? Angular, Backbone, React, Vue, Ember... ?

Merci pour ton aide,

Cordialement,

[psychadelic]

JavaScript et donc Node.js.

C'est la plateforme qui avale le plus de requêtes par seconde et qui démarre le plus vite. A voir après si tu pars sur une archi monolithique ou en micro services.

Je t'invite à regarder cette présentation :

Géniale la présentation!
J'ai pas osé encore poster sur ce sujet, car ça me semble tellement évident que la seule techno ayant de l'avenir ça passe par JavaScript / nodeJs...

Pour moi le for dvp devrait créer une section techno pourries amenées à disparaître avec dedans Java, PHP, Python...

[Marco46]

Par contre je le vois souvent couplé à du mongodb que postgre, ça pourrait être intéressant d'un point de vu perf ?

Le choix de la persistance dépend de ce que tu veux y stocker des volumes en cause. Des annonces ça ressemble quand même beaucoup à des documents, donc du Mongo pourquoi pas. C'est souvent couplé avec Mongo parce que le format dans Mongo c'est du json et donc les opérations de sérialisation / désérialisation d'objets sont ultra faciles : Front en js <--> transport en json sur http <--> backend en js <--> db en json. Voilà quoi

Angular, Backbone, React, Vue, Ember... ?

J'ai fait beaucoup beaucoup de AngularJS, c'était pas mal mais la techno va mourir bientôt, je trouve que Angular est une daube (trop complexe, c'est vraiment n'imp on dirait du J2EE côté client), backbone trop vieux, React je déteste le JSX j'ai l'impression de faire du php côté client ça me rend dingue, j'ai trouvé Vue super pour le peu que j'ai fait avec et Ember connait pas assez pour répondre. React est manifestement le framework le plus utilisé dans le monde. Facebook l'utilise à fond donc il est pas prêt de mourir.

J'ai pas osé encore poster sur ce sujet, car ça me semble tellement évident que la seule techno ayant de l'avenir ça passe par JavaScript / nodeJs...

Perso j'avais remarqué l'énorme explosion de paquets sous npm mais je pensais pas que ça avait percé à ce point là. La première fois que j'ai jeté un gros oeil sur node pour faire du backend ça devait être fin 2013 et yavait pas grand chose d'accessible. Par exemple impossible de trouver une implémentation correcte pour taper sur du MySQL. Et l'an dernier j'ai remis un gros oeil et là boum C'est fou l'évolution en si peu de temps.

Ça commence tout doucement à arriver en France, ça se voit sur les offres d'emplois mais ça concerne surtout les startups. Aux US manifestement la migration J2EE vers Node est massive. Quand t'en parle à des Javaistes ils ne te croient tout simplement pas c'est assez marrant le déni

[psychadelic]

J'ai fait beaucoup beaucoup de AngularJS, c'était pas mal mais la techno va mourir bientôt, je trouve que Angular est une daube (trop complexe, c'est vraiment n'imp on dirait du J2EE côté client), backbone trop vieux, React je déteste le JSX j'ai l'impression de faire du php côté client ça me rend dingue, j'ai trouvé Vue super pour le peu que j'ai fait avec et Ember connait pas assez pour répondre. React est manifestement le framework le plus utilisé dans le monde. Facebook l'utilise à fond donc il est pas prêt de mourir.

D'autres arrivent comme Preact, je ne sais pas trop ce que ça vaut, mais il faut bien démarer quelque part pour s'habituer à cet environnement.

[Squadzz]

En rebondissant sur la réponse de de psychadelic, je me posais 2 questions :

Dans ma compréhension général ça serait :

- Nodejs coté backend (server-side), et Reactjs coté frontend (client-side)
Je vais lire cet article, ça va sûrement confirmer mon idée : https://hackernoon.com/how-to-combin...p-ea9b24715032

- J'ai plus un doute du coté du framework JS : J'ai l'impression que ça bouge énormément, mais quelles en sont les conséquences ?


- Les utilisateurs d'un framework "obsolète" comme backbonejs, vont ils passer sur un autre framework ? (dans le cas où le framework n'est plus mis à jour ?)

- Idem pour le changement de version d'un framework, est-il vraiment nécessaire de faire l'update ? (ex: react 2 vers 5)

Désolé si ces questions peuvent paraître bête, mais je n'ai jamais eu ce type "d'occasion"..

Je me rappel que pour Python du passage de sa version 2 vers 3 c'était le bordel... après il s'agit d'un language et non pas d'un framework, donc la difficulté doit être complètement différente ?

[psychadelic]

Aujourd'hui il y a presque 2 fois plus d'internautes sur systemes mobiles (smartphone et tablettes) que sur Pc/Mac

donc il faut mieux prévoir des le départ des Apps pour Mobile, en cohérence avec celle pour le web.

[Marco46]

- Nodejs coté backend (server-side), et Reactjs coté frontend (client-side)

C'est en effet une stack très classique.

- J'ai plus un doute du coté du framework JS : J'ai l'impression que ça bouge énormément, mais quelles en sont les conséquences ?

Ben que si tu suis pas les montées de version en 2 ans tu as une stack obsolète. La dette technique s'accumule beaucoup plus vite dans le monde JavaScript, et en particulier sur le front.

Le vrai gros problème de ces frameworks js c'est qu'ils sont trop invasifs avec ton architecture logicielle (surtout AngularJS et Angular). Donc quand tu développes avec un framework ou une lib de type React / Vue, sauf à vraiment faire très attention dans ta conception, tu crées mécaniquement une adhérence très forte avec ce framework et il est très difficile d'en sortir sans tout réécrire pratiquement de A à Z.

La source de ce problème IMHO c'est que les géants derrière ces frameworks les écrivent pour leurs propres besoins internes, et les opensources pour attirer des bons profils (le côté hype). Ils ne cherchent pas une solution universelle.

Par exemple entre AngularJS/Angular, React et Vue.js, je trouve que Vue.js est le seul outil véritablement respectueux du web. Pas d'archi imposée, pas de DSL débile comme JSX. Et curieusement c'est le seul qui est véritablement développé par une communauté au lieu d'une entreprise.

Et comble du malheur, comme les entreprises qui ont besoin d'outils font plus confiance à d'autres entreprises qu'à une communauté opensource, leurs DSI choisissent d'utiliser du React (Facebook) ou de l'Angular (Google) plutôt que de contribuer à un vrai projet opensource (Vue.js).

Résultat, quand Google annonce le drop du support de AngularJS je t'explique pas les montagnes de sel que ça va générer dans les années qui viennent dans les DSI qui auront investi des millions d'euros sur des applis métiers toutes neuves qui deviendront subitement obsolètes techniquement.

- Les utilisateurs d'un framework "obsolète" comme backbonejs, vont ils passer sur un autre framework ? (dans le cas où le framework n'est plus mis à jour ?)

Tout dépend de leur code mais c'est difficile de ne pas se faire prendre par le framework. Généralement il y a réécriture sinon maintenir du legacy avec tous les problèmes que ça pose, surtout pour les boites qui sont passées par des prestas pour leurs devs (va recruter un développeur pour faire du AngularJS 1.2 aujourd'hui ... Bon courage )

- Idem pour le changement de version d'un framework, est-il vraiment nécessaire de faire l'update ? (ex: react 2 vers 5)

[...]

Je me rappel que pour Python du passage de sa version 2 vers 3 c'était le bordel... après il s'agit d'un language et non pas d'un framework, donc la difficulté doit être complètement différente ?

Ce n'est pas du tout comparable. Les packages JavaScript gérés par le registry npm, c'est à dire pratiquement 100% de l'écosystème, utilisent le système de versioning semver. Une montée de version majeure signifie qu'il y a un breaking change, c'est à dire un changement dans le contrat d'interface du package. Tu peux avoir un changement de version majeure pour une nouvelle version qui contient 10 lignes de codes et aucune nouvelle feature et tu peux avoir 12 versions majeures en 1 mois ça ne pose aucun problème (si ce n'est que les auteurs changent beaucoup trop d'avis sur leur contrat d'interface :p ).

Oui il est nécessaire de faire les montées de version.

Désolé si ces questions peuvent paraître bête, mais je n'ai jamais eu ce type "d'occasion"..

Il n'y a pas de question bête et on est tous le débutant de quelqu'un d'autre.

[Squadzz]

Merci Marco, tu confirmes mes doutes par rapport aux frameworks frontend JS.

Par rapport à l'évolution des frameworks JS, il pourrait être donc judicieux d'avoir en backend nodejs et pour du frontend un autre langage ?

Je pensais à Django, malgré que ça soit aussi du backend, il peut tout de même être coupler avec Nodejs... mais je suis pas certains au niveau des perfs du coup ? :

- How to use both Django & NodeJS as backend for your application (2014) : http://www.cuelogic.com/blog/how-to-...r-application/

Aurais tu une idée/solution à proposer pour un bon matchup entre nodejs / frontend ? en évitant le problème que tu as soulevé ?

Actuellement coté immobilier dans le pays où je réside, la demande est beaucoup plus forte que l'offre... Ce qui implique énormément de vues des annonces que de créations... il n'y a qu'un site en place dans le pays, et il est totalement buggé ou rempli de scam/phishing :-/

[Marco46]

Côté front pas le choix c'est forcément du JavaScript. Django ça s'exécute côté serveur, au mieux ça va générer du JS. Je sais pas trop comment ça marche je connais pas Django mais ce qui s'exécute côté front ça ne peut être que du js.

[Squadzz]

Cool, Merci pour tes réponses Marco.

J'avais lu dans l'article la mise en place de Django et Nodejs, mais j'ai un sérieux doute sur le coté performance.

Je vais partir sur du nodejs et vue qui me semble être le plus stable, et facile à prendre en main de ce que j'ai pu comprendre.

Bon bah... j'ai du boulot