Il existe actuellement plusieurs approches pour créer des applications Web:

1. Côté serveur uniquement

Il s'agit d'une approche classique où vous affichez des pages sur le serveur par un framework Web comme Ruby on Rails, Django, Express, Play! Cadre et etc.

Flux de travail typique : créez toute votre logique métier, vos modèles et vos modèles de vue sur le serveur dans le cadre de votre choix.

2. Côté client + API REST

Il n'y a pas si longtemps, la communauté Web dans son ensemble a commencé à créer des applications côté client dans Angular, Backbone, Ember et quelques dizaines d'autres frameworks JavaScript MV *. Et maintenant, nous avons également React.js rejoindre le parti.

MISE À JOUR : Il n'y a pas de malentendu. Ce que je voulais dire par côté client uniquement, c'est une séparation complète des préoccupations. Vous disposez d'un serveur API REST et d'une application côté client qui communique avec ce serveur. Selon votre cas d'utilisation, il est probable que vous n'aurez jamais une véritable application côté client uniquement qui ne se connecte pas à un serveur principal pour l'authentification ou la persistance des données.

Flux de travail typique : passez des heures à décider entre Angular vs Backbone vs Ember vs X. Ensuite, vous créez vos itinéraires, modèles, vues, contrôleurs sur le client. Une fois que vous avez terminé, créez maintenant des modèles, des contrôleurs et des itinéraires sur le serveur. D'une certaine manière, vous faites deux fois plus de travail.

3. Hybride

Je ne sais pas grand-chose sur l'utilisation de cette approche, mais si je devais deviner, vous restituez vos vues (Vue du framework MVC) sur le serveur. En conséquence, vous bénéficiez d'un support SEO et de chargements de page plus rapides.

Sur le front hybride, il y a le rendu d' Airbnb qui combine soi-disant épine dorsale et exprime ensemble.

Eric Florenzo a posté sur son blog aujourd'hui: React: Enfin, une super pile web serveur / client .

La quantité de façons de créer des applications Web est tout simplement écrasante. Et pour quelqu'un qui apprend le développement Web, cela peut devenir un problème. Comment décide-t-on de l'approche à utiliser pour construire sa prochaine application?

Je pense que vous avez totalement mal compris le "côté client uniquement".

Tout d'abord, il doit être étiqueté "Client Centric". Ce point de frameworks comme Angular est que les parties "VC" de MVC sont implémentées entièrement dans le navigateur en Javascript. La logique de niveau supérieur "M" de la partie "M" - le modèle - est implémentée dans le navigateur et la logique "CRUD" de niveau inférieur est implémentée sur le serveur.

La logique métier est développée une seule fois. La logique de vue est développée une fois. La logique de contrôle est développée une fois pour toutes dans le cadre Javascript de choix. La logique d'accès aux données n'est également développée qu'une seule fois mais cette fois sur le framework RESTy ou SOAPy que vous choisissez côté serveur.

Dans les cas extrêmes, vous pouvez implémenter le modèle entièrement dans le client, s'il est acceptable d'accéder aux données à partir d'un seul navigateur sur une seule machine, et de mettre les données à la poubelle à chaque fois que l'option "Effacer les cookies" est sélectionnée.

La réponse à la question est que cela dépend des exigences. Un regard au moins superficiel sur l'histoire du développement "web" indique en quelque sorte une culture cowboy où parler aux parties prenantes, aux clients, à la collecte des exigences, est souvent négligé.

J'ai eu la chance d'assister à une conférence il y a quelques années où j'ai entendu quelque chose qui m'a vraiment marqué: "vous choisissez le design pour répondre aux exigences, pas les exigences pour répondre au design". Donc, face à une question comme celle-ci, vous devez découvrir ce dont les personnes qui vous demandent de créer ce logiciel ont réellement besoin.

Votre travail consiste à expliquer les avantages et les inconvénients de chaque approche.

Je pense que l'un des points clés des nouvelles approches et cadres est qu'il y a moins de couplage entre les technologies frontales et les technologies back end.

L'idée est que vous pouvez utiliser n'importe quel framework sur le client et extraire des données et / ou des vues de n'importe quel nombre de sources, quel que soit le framework côté serveur.

Cela nous permet de choisir les meilleurs outils pour faire le travail et nos choix peuvent évoluer indépendamment.

Certes, je n'ai pas utilisé Angular ou Backbone donc je ne peux faire aucune recommandation expérimentée. Ma pile de base actuelle se compose du mvc côté serveur le plus mince ou des services reposants que je puisse trouver. Fournit principalement des modèles et des données. Les données sont restituées et / ou les données ultérieures récupérées côté client en utilisant principalement simplement javascript, jquery et css.

Je commence ici et je m'appuie sur ce dont j'avais besoin. Les avantages de cette approche sont évidents lorsque vous envisagez de prendre en charge plusieurs plates-formes clientes - navigateur, mobile, etc. Si vous avez besoin d'un rendu spécifique au client, vous ne devriez pas avoir à effectuer de modifications massives côté serveur.