Devez-vous toujours programmer côté serveur pour un site Web?

38

Je suis sur le point de commencer à créer un site Web de projet musical pour un ami. Cela devrait être assez simple pour le moment: pas de contenu dynamique (dates de tournée, etc.), et rien de plus que quelques exemples de chansons ou liens SoundCloud intégrés. Je ne m'attends pas à utiliser autre chose que JavaScript et Bootstrap ou Foundation vanilla pour une grille réactive.

Est-ce suffisant cependant? Puis-je simplement télécharger des fichiers HTML, CSS et JS sur un hôte et en finir, ou dois-je prendre le temps de programmer un serveur dorsal en nœud ou en PHP?

— Deegriz
source

54

Est-ce suffisant? Quel problème avez-vous que le fait d'avoir un back-end dynamique résoudrait le problème? Restez simple jusqu'à ce que vous ne puissiez pas.

— RubberDuck

25

Maximiser le travail non effectué. YAGNI.

— RubberDuck

9

Vous ferez probablement mieux d'installer un CMS prêt à l'emploi si vous ne faites qu'écrire du texte, télécharger des images et quelques fichiers de musique / intégrer des fichiers vidéo / YouTubes ... WordPress, etc. être idéal et la plupart des sociétés d’hébergement proposent des installateurs en un clic pour vous permettre de démarrer en quelques minutes ... il existe de nombreux CMS.

— Kinnectus

11

Je me demande pourquoi une question comme celle-ci a eu autant de votes positifs? C'est comme si je demandais "dois-je créer une base de données pour mon logiciel même s'il n'a pas besoin de stocker de données?". Cela ne me surprendrait pas si c'était une question de débutant, mais pas lorsque vous êtes assez habile pour créer un projet bootstrap / foundation.

— Mahdi

14

@Mahdi, c'est un vote populaire parce que tout le monde se demande depuis 5 ans exactement cette fichue chose et que personne n'a eu le courage de le lui demander.

— djechlin

86

Si vous ne savez pas si vous avez besoin d'un code côté serveur, vous n'avez probablement pas *

* Avertissement : le code côté serveur est essentiel pour la sécurité lorsque vous souhaitez contrôler en interne l'accès au contenu, aux données ou aux fonctionnalités. (Il n'est pas nécessaire que ce soit votre serveur, voir le dernier paragraphe.)

Demandez-vous quel problème utiliserait les technologies côté serveur. Si vous ne pouvez en penser à aucune (et dans votre cas, je ne peux pas non plus), vous n'en avez pas besoin.

Sachez qu’il est beaucoup plus possible que vous ne le pensez possible d’utiliser un code côté client. Les infrastructures JavaScript telles qu'AngularJS ou ReactJS peuvent vous permettre d'intégrer du contenu dynamique tiers via des API utilisant Ajax. (Cela inclut la connexion à une API capable de gérer sa propre sécurité.)

— Tim Grant
source

17

Je pense que c’est une déclaration dangereuse à faire. Les technologies côté serveur sont souvent utilisées quand vous «pouvez le faire côté client»: la décision de transférer des éléments sur un serveur relève de la sécurité, et non nécessairement de la fonctionnalité. - En tant que tel, promouvoir une attitude de «non-savoir» est préoccupant: les programmeurs doivent toujours considérer la sécurité dans toutes les applications, même les plus simples qui soient . Toute la solution doit être pensée: voulez-vous une zone de contenu 'sécurisée', obligeant les utilisateurs à s'inscrire ou à ressembler à FB avant de leur donner un mp3? (Cependant, dans ce cas, un site statique semble

— correct

3

Il y a également quelque chose à dire sur les avantages en termes de sécurité des générateurs de sites statiques. Pour de nombreuses applications, les sites statiques constituent le nec plus ultra en matière de sécurité car il n’ya littéralement rien à pirater.

— Nathan GoFundMonica Arthur

1

Server-side code is essential for securityDe nombreux développeurs n'accordent pas beaucoup d'importance à la sécurité. Pas avant d'avoir jeté leur visage dans leur ... bordel. Ma ligne est que si vous avez besoin d'authentification, vous avez besoin d'un back office. Si vous avez besoin de stocker des données, vous avez besoin d'un backoffice où les données seront vérifiées une deuxième fois après avoir été vérifiées par le client.

— Walfrat

1

@Walfrat Si vous avez juste besoin d'une authentification, vous pouvez la décharger sur un nombre quelconque de services d'authentification ouverts et ne pas utiliser de moteur du tout. Si vous avez besoin d'une autorisation, par contre, vous aurez peut-être besoin de certains éléments du backend.

— CorsiKa

56

Lisez à propos des générateurs de sites statiques. Celles-ci vous permettent de créer un site de manière programmatique (à l'aide de modèles, de données, etc.) et non de manière manuelle. Le résultat est un ensemble de HTML et de CSS statiques ne nécessitant aucun back-end.

https://www.staticgen.com/ répertorie et classe un certain nombre de ces générateurs à source ouverte; des offres fermées existent probablement aussi.

— 9000
source

3

+1, cela fonctionne toujours pour des sites dynamiques un peu dans le temps (comme des blogs et des itinéraires de tournée). Tant que le contenu ne dépend pas de l'utilisateur qui regarde la page, c'est souvent suffisant.

— RemcoGerlich

1

+1 Les dates de la tournée et des exemples de chansons devront être mis à jour par le client plus ou moins souvent. Un générateur de site statique lui évite de toucher à HTML, ce qui est beaucoup plus simple et sécurisé qu'un CMS (mal entretenu).

— Bergi

3

Bien que je convienne que c’est une bonne suggestion pour OP, tente-t-il vraiment de répondre à la question telle que posée?

— Woodrow Barlow

La réponse marquée était plus générale et correspondait à la question telle que posée par Woodrow Barlow. Cependant, j'ai fait +1 pour avoir présélectionné une solution intéressante pour moi et beaucoup d'autres pourraient aller de l'avant

— Deegriz

2

@WoodrowBarlow: Je dirais que

Can I simply upload HTML, CSS, and JS files to a host and be done with it, or should I take the time to program a backend server in Node or PHP?

cela appelle à souligner qu'il existe une 3ème option intéressante, dans le cas de OP, à

— mon humble avis

6

Vous pouvez et devez utiliser uniquement un site statique si cela est suffisant, ou utilisez un générateur de site statique . Pourquoi? Maintenabilité. Le code a des bugs. Toutes les quelques semaines, un autre trou de sécurité WordPress est trouvé. Si vous utilisez un CMS commun, vous devrez le corriger constamment. Sinon, le site Web de vos amis contiendra bientôt une publicité pour des drogues illicites, la propagande ISIS, des logiciels malveillants installés sur les ordinateurs des visiteurs ou pire. Même si vous le corrigez régulièrement, il se peut que vous soyez trop en retard, vous devez donc rechercher en permanence des piratages. Il existe des moyens de sécuriser ce CMS. Installez des "plug-ins de sécurité", configurez un pare-feu pour une application Web tel que mod_security, etc. Ils doivent également être tenus à jour. Parfois, vos règles mod_security vont casser un plugin pour WordPress, vous devez l’analyser et le corriger. Plus de travail.

Vous pourriez penser que personne ne voudra pirater ce site. Mais en ce qui concerne les failles de sécurité communes aux systèmes de CMS communs, il existe bientôt des robots automatiques qui explorent / recherchent sur le Web et piratent TOUS les sites utilisant ce CMS. Ils veulent juste diffuser leurs liens / malware / propagande.

Avec un site statique (créé manuellement ou avec un générateur), vous n'avez pas ce problème.

Si vous implémentez votre propre back-end, il comportera également des failles de sécurité (personne n’est parfait), mais il est fort probable que personne ne les exploitera pour ce petit site Web. Mais que voulez-vous mettre en œuvre? Si vous souhaitez créer un éditeur où votre ami peut modifier lui-même les dates de la tournée, pensez au temps qu'il faudra jusqu'à ce qu'il soit assez facile pour lui de l'utiliser sans votre aide. Combien de fois pouvez-vous simplement changer rapidement les dates pour lui avec ce budget de temps?

À mon avis, beaucoup trop de gens aujourd'hui n'utilisent que les systèmes CMS pour chaque site, car le HTML statique est "ancien". Si vous n'avez besoin de rien qui ne soit pas possible avec HTML5, utilisez le code côté serveur. Mais si vous n'en avez pas besoin, vous gagnez beaucoup de temps sans cela.

— Josef
source

Toutes les quelques semaines? Hah, si seulement! Plus comme des jours

— Courses de légèreté avec Monica

3

Vous n'avez besoin de faire de la programmation backend que lorsque vous en avez besoin.

Cependant, même les fonctionnalités de base telles que les formulaires de messagerie électronique nécessitent généralement une programmation de base. Si c'est juste un site d'affichage, alors oui, c'est bien.

— Deek
source

1

S'il ne s'agit que d'une simple fonctionnalité, vous pouvez souvent utiliser un service SaaS pour le remplacer. Par exemple, un formulaire d'inscription peut être créé gratuitement sur Google Forms , puis lié au site.

— André Paramés

2

Pas nécessairement, mais vous rencontrerez probablement des problèmes si vous créez l'ensemble du site en HTML.

De nombreux sites ont les mêmes éléments de menu, en-tête et pied de page sur plusieurs pages. Si vous copiez et collez simplement ceux-ci d'une page à une autre, cela peut devenir fastidieux et sujet aux erreurs lorsque le site s'agrandit et que vous devez continuer à apporter des modifications dans ces domaines.

Auparavant, la programmation côté serveur était si courante. Une façon habituelle de résoudre ce problème consistait à utiliser des cadres pour intégrer ces zones à chaque page. Cela est tombé en disgrâce il y a plusieurs années, donc je ne recommande pas de le faire maintenant. Vous pouvez écrire un simple code côté serveur à la place pour afficher ces éléments communs sur chaque page.

Je suis d’accord avec d’autres ici qui ont recommandé l’utilisation d’un CMS standard.

— bdsl
source

1

Une alternative au "copier-coller" consiste à utiliser un générateur de site statique; cela devrait s'occuper des éléments menu / header / footer pour vous, vous permettant de vous soucier du contenu.

— Doktor J