Informatique

Je suis perdu, auparavant j'ai fait du css3/html5/Jquery/Ajax et un framework php (symfony) en back
mais mantenant y'a beaucoup trop de technologie et je m'y retrouve plus
pour faire simple, qu'est ce que je dois connaitre absolument pour réaliser un site "moderne" ?

Le web s'est énormément complexifié en effet, et il est rare de nos jours de maîtriser toute la chaîne (la notion de fullstack est utopique). Je vais faire une réponse relativement exhaustive, qui te permettra d'avoir la réponse souhaitée selon tes appétences et qui te donnera des pistes pour compléter tes connaissances en backend ou frontend.

Tu comprendras rapidement qu'au vu de la complexité, tu te spécialiseras forcément par la force des choses soit en backend, soit en frontend, et soit en déploiement (devOps)

Il faut déjà savoir sur quel type d'architecture web tu souhaites travailler.

I/ Site moderne vu par une startup
Je pense que c'est cette réponse qui t'intéresse essentiellement.
Généralement une startup va développer un MVP sur une architecture "simple" qui lui permettra de réaliser un produit dans des délais raisonnables tout en maîtrisant son coût.

C'est souvent architecturé de la sorte :
- monolithe backend basé sur du REST (et si possible hateoas). Côté techno ça peut être du javascript (nodeJS), du PHP (Laravel/Symfony), du ruby (ruby on rails) ou encore python (django)
- monolithe frontend en composants web, basé sur un framework à la mode (vue, react ou angular). Côté CSS tu peux te renseigner sur les précompilateurs css (SCSS) ainsi que sur les frameworks de bootstrapping (bootstrap, bulma ou autre..).
Côté JS, renseigne-toi sur l'EcmaScript 7 et TypeScript.
- packagé via docker et déployé dans kubernetes. La mode est d'ailleurs aux services managés dans GCP/AWS/Azure

Pour moi il s'agit là d'une architecture classique, mais ça n'a rien de moderne.

II/ Site moderne vu par une entreprise qui connait un trafic important
Un site "moderne" est designé pour scaler, et se décompose en général d'une architecture avec 3 briques principales :
1- un backend architecturé en microservices, qui exécute les traitements métier et expose des services (la plupart du temps en REST hateoas, mais ça peut être via un message broker (souvent kafka)
2- un middleware qui aggrege les données (simple brique technique), qui sera consommé par les différents front/mobile. C'est ce qu'on appelle le Backend For Frontend (BFF), et un serveur GraphQL/Apollo est clairement une bonne option
3- un front web bâti sur la notion de web composants. Parfois même découpé en microfrontends.

Côté techno, ça donnerait à peu près la même chose que précédemment, en privilégiant en backend plutôt une technologie qui scale, même si le temps de démarrage peut être important.
Ce qui va nous intéresser c'est le temps de réponse une fois le serveur "chaud". Il faut pour cela que la technologie permette la programmation réactive (et soit compilée et statiquement typée idéalement). Clairement du typescript (nodeJS) ou Java/Kotlin.

III/ Site moderne
On va maintenant dans le côté expérimental, où peu d'entreprises en France ont sauté le pas.
Le problème des architectures précédentes est que le coût de l'infrastructure n'est pas négligeable, sachant qu'un serveur n'est utilisé que 20% de son temps. On le paie donc 80% de son temps pour rien, et on peut optimiser cela.

C'est la notion de service on demand. On parle de server as a function ou de serverless.
On va privilégié en backend des technologies qui démarrent rapidement (en quelques milliseconds), qui vont répondre à la demande et s'éteindre dès qu'ils ont fini l'exécution demandée. La durée de vie est donc très courte.

C'est le type d'architecture serverless (qui induit d'ailleurs en erreur, il y a bien un server... mais on demand).
Côté techno, au vu des problématiques de démarrage et de performance évoquées, on va clairement éviter tout ce qui est technologies qui nécessitent le démarrage d'une VM lourde et qui fait de l'optimisation à la volée (JIT - Just In Time compiler). Adieu Java et .NET.

Ce qui marche bien aujourd'hui c'est nodejs, python ou encore go sur ce type d'architecture ultra moderne.

Sachant que côté Java ils travaillent à améliorer le démarrage en compilant tout en code machine. Le projet GraalVM et le framework Quarkus sont très intéressants, mais c'est encore expérimental.

L'avantage de ce type d'architecture est que, comme le coût de l'infra est liée à l'exécution du code (vu qu'on ne paie que lorsque la fonction est consommée), c'est directement lié à la qualité du code produit par le développeur.
On peut ainsi refactorer du code, améliorer ses performances... et directement impacter les coûts pour l'entreprise.

Côté frontend, une nouvelle notion est arrivée avec les web assembly. Je trouve cela très intéressant, mais malheureusement trop peu (voire pas du tout) utilisé en France

Je m'attendais pas à une réponse de qualité ! Merci.
Après je vois beaucoup de librairies/framework/préprocesseur comme redux express babel la liste est encore longue, comment on fait le choix de ce qu'on doit maîtriser ?
Et dernière question peut-être un peu idiote, mais est-ce que le dev mobile se rapproche du dev web en terme de codage ? est-ce qu'ils partagent les même outils ou ce sont deux technologies différentes ?

Réponse très instructive, pense tu qu'à terme le serverless sera utilisé en majorité ?

Le 21 juillet 2019 à 12:36:44 NoLoveLost a écrit :
Je m'attendais pas à une réponse de qualité ! Merci.
Après je vois beaucoup de librairies/framework/préprocesseur comme redux express babel la liste est encore longue, comment on fait le choix de ce qu'on doit maîtriser ?

Ici tu parles de technologies front, et ça va dépendre surtout du langage/framework utilisé.
- Redux c'est une brique technique utilisé en combinaison de react pour avoir un store centralisé (en vue c'est vuex par ex),
- babel permet de transpiler le code en js
- express c'est un framework pour node js

Le premier choix à faire est celui du framework : react vs angular vs vue (personnellement je choisirais plutôt react ou vue), et ensuite du langage dans lequel tu vas coder (typescript ou ecmascript7).

Malheureusement il n'y a pas de réponse unique.... c'est le problème de l'écosystème front qui évolue sans cesse.

Et dernière question peut-être un peu idiote, mais est-ce que le dev mobile se rapproche du dev web en terme de codage ? est-ce qu'ils partagent les même outils ou ce sont deux technologies différentes ?

Ca peut se rapprocher en effet, ça a été avec cette démarche qu'on été faits react native ou ionic.
Maintenant, je pense que d'un point de vue performance il faut utiliser un outil vraiment conçu pour ça et éviter tout ce qui nécessitera un moteur js à l'exécution.

Je partirais plutôt sur le framework flutter en 2019 pour du développement mobile

Le 21 juillet 2019 à 12:49:41 Not_me a écrit :
Réponse très instructive, pense tu qu'à terme le serverless sera utilisé en majorité ?

Oui c'est indéniable vu le coût que représente aujourd'hui l'infrastructure. Je pense que l'avenir est au cloud (public ou privé), et que toute la partie infra sera gérée par le provider de cloud, le développeur ne se souciant plus que de son code et des problématiques métier.

C'est d'ailleurs pas plus mal, vu que comme expliqué sa qualité de code impactera directement les coûts de l'entreprise : j'espère que les entreprises se mettront à payer correctement les très bons développeurs, et qu'elles ne verront plus le développeur comme un simple ouvrier.

Merci khey

Sinon on a surtout parlé d'architecture SI, mais pour compléter mes éléments de réponse avec un point de vue plus centré sur le code et l'architecture logicielle, je conseillerais de s'intéresser à :
- la programmation asynchrone non bloquante et réactive
- la programmation fonctionnelle

En terme de design de code, certains utilisent le Domain-Design Driven, l'hexagonal architecture ou encore l'onion architecture..... mais ça ferait un sujet à part entière

Le web aujourd'hui c'est un grand bordel rempli de technologies

A l’heure actuelle coté front des technos comme react/angular/vue son très demandé et en backend je dirai nodejs/php/java/.net, si tu maitrises une de ses technos côté front et 1 côté back, si t’es dans une grande ville tu devrais pas galerer à trouver du taf

Comme ça parle programmation fonctionnelle je conseille de jeter un oeil à ELM , y a même des conf en français sur youtube (ELM Paris par exemple) pour en savoir plus.

Comme ça parle programmation fonctionnelle je conseille de jeter un oeil à ELM , y a même des conf en français sur youtube (ELM Paris par exemple) pour en savoir plus.

J'adore et je plussoie

https://www.youtube.com/watch?v=RFrKffrKCeU C'est le risque

Excellente contribution de LambdaFunction !...

Je ne fais pas de web à proprement parler, mais je délivre pas mal de progiciels en SaaS... Autant dire que je bouffe pas mal de JS sous toutes ses formes quand vient le moment de coder l'IHM.

Mon architecture type est certainement différente de celle d'un vrai dev web, mais je constate dans la majorité des cas une très mauvaise utilisation des frameworks ; adoptés un peu par effet de mode.

Personnellement, je n'ai pas peur du désormais classique combo NodeJS-Express/Angular-TypeScript, mais si j'ai le choix de pouvoir faire la même chose sous PHP-Slim/VueJS (ce qui est souvent le cas), je n'hésiterais pas une seconde. Alors que je pense être meilleur codeur JS que PHP. Je crois surtout que rien ne sert de courir tous les lièvres à la fois, il faut simplement être à l'aise dans ses technos de prédilection... En prenant garde à ne pas prendre racine non plus !