Conseils sur le design technique général d'une nouvelle application

a marqué ce sujet comme résolu.

Bonjour bonjour,

J’ai un projet de site que j’aimerais créer en 2024. Je n’en suis encore qu’à la réflexion préalable : design général, fonctionnalités de base ou poussées, sécurité, etc. Ce qui est certain, c’est que j’aurai forcément d’un côté une grosse base de données qui sera remplie uniquement par un administrateur authentifié via un espace d’administration sécurisé, et de l’autre une interface graphique plaisante, optimisée pour le mobile, et la plus efficace possible en termes de chargement, avec la possibilité de s’identifier pour interagir avec le site (commentaires, favoris, etc.).

Mon souci, c’est l’embarras du choix technologique. Je saurais me débrouiller avec Symfony, API Platform, javascript, le php en général, Vue, jQuery, le CSS et plusieurs de ses variantes. Sur mes derniers projets, j’ai utilisé le couple API Platform/Symfony pour le backend, et Vue/Vuetify pour le frontend via webpack encore. Je trouve personnellement que Symfony - jusqu’au 6 inclus, pas encore testé le 7 - est médiocre quand on veut n’utiliser que Vue pour la partie front ; webpack encore une sacrée calamité à configurer, et tout l’aspect sécurité mal pensé, voire carrément bricolé. L’ensemble fait chaotique, ça ne parait pas pensé pour fonctionner ensemble.

J’ai commencé à regarder Symfony 7, qui continue à pousser vers leur système Stimulus pour le JS, Twig pour le design, et la génération de pages PHP par le serveur plutôt que faire du "tout JS SPA". Je n’ai pas encore commencé à apprendre comment tout ça marchait, et à quel point c’est efficace, ou au contraire, une usine à gaz de plus.

Je n’ai pas réellement la possibilité de faire 50 tests différents, ça me prendrait beaucoup trop de temps.

Est-ce que des gens expérimentés pourraient me donner leur avis ? Est-ce que j’ai intérêt à partir sur un frontend complètement indépendant en Vue/Vuetify/etc. et des JWT pour la sécurité, et qui ferait des appels à un backend complètement indépendant fait avec Symfony et Api Platform ? Ou est-ce que ça vaut le coup de suivre l’ecosystème Symfony et utiliser Twig, Stimulus, PHP, et leur système de sécurité ? Ou carrément autre chose qui ne me prendrait pas des années à apprendre ?

Merci pour vos avis.

Edit : le site serait un catalogue, en gros. Tu as plein de résultats, filtrés et ordonnés différemment. Tu cliques sur un élément pour en avoir le détail et éventuellement y laisser des commentaires.

+0 -0

Hello,

Si c’est une première version du projet je dirais : fais avec ce que tu connais.

Le but d’un prototype est pas forcément de faire un truc parfait mais de tester le concept.

Il vaut donc mieux faire simple mais être sûr de pouvoir sortir quelque chose que de t’engager dans un projet trop gros au risque de jamais finir. Tu pourras toujours re-commencer plus tard si besoin, une fois que tu auras affiné le besoin et que tu maîtriseras mieux tes contraintes.

En somme… construire un MVP ;)

En l’état il nous est difficile de te répondre simplement sur la base de quelques phrases : une bonne architecture technique ça se construit sur le temps, et ça s’affine au fur et à mesure que le projet se construit car les besoins et contraintes évoluent (ou la direction change carrément).

Le retour du topic ^^

Bon cette année je n’ai pas eu le temps de monter ça, mais en contre-partie j’ai eu le temps de progresser pas mal sur certains autres points. J’ai encore de sérieuses lacunes bien navrantes côté serveur. Hum. Merci Viki ^^

Donc je me permets de relancer ce topic, côté serveur et organisation générale :

Est-ce que c’est bien techniquement possible d’avoir un sous-domaine admin.mondomaine.fr qui serait entièrement fait avec Symfony, pas ou très peu de JS, ayant pour seul but de gé(né)rer des "consommables" pour un front, via sans doute API Platform ? Le front serait lui totalement indépendant de Symfony, fait probablement avec Nuxt.js. Je commence à me débrouiller plutôt pas mal sur Vue, et le côté SSR de Nuxt pour un meilleur SEO me tente bien. Ce serait important d’être bien référencé sur ce projet. Niveau sécurité, le back utiliserait le security provider par défaut de Symfony quand on est sur l’espace d’administration, et LexikJWT pour sécuriser les appels à l’API.

Voilà l’idée. C’est possible ça ? Et plus important : c’est bien comme idée ?

Si je tiens à réfléchir d’une façon plus organisée pour ce projet, c’est que je suis assez convaincu par son potentiel public. Faire une maquette fonctionnelle de ce truc, utilisant des organisations que je connais déjà - et dont je vois les limites - me semble être une perte de temps. J’aimerais faire mieux que ce que je fais d’habitude, parce que de toute façon je serai seul sur ce projet pendant trèèès longtemps. Alors autant partir directement sur un modèle moderne et performant.

Hello,

Oui c’est bien possible et même assez courant de dissocier back et front.

Par contre ça implique quelques inconvénients dont il faut être au courant, notamment :

  • ça implique de maintenir deux applications au lieu d’une (y compris les dépendances et l’infra), ici avec deux stacks et langages différents
  • il faudra mettre à jour les formats de données des deux côtés à chaque évolution des entités
  • il faut s’assurer que les données exposées par le back puissent être consommées de façon sécurisées (pour ne pas se retrouver à faire de l’open-data par inadvertance, par exemple)
  • ça augmente les coûts d’infras/hébergement, vu qu’il faut faire tourner deux applications en parallèle au lieu d’une
  • attention à l’expérience utilisateur : le front peut pas faire de rendu sans avoir chargé les données du back. En cas de mauvais débit ça rend certaines applis mal optimisées inutilisables

"il faut s’assurer que les données exposées par le back puissent être consommées de façon sécurisées (pour ne pas se retrouver à faire de l’open-data par inadvertance, par exemple)"

Oui c’est surtout ça qui me fait peur dans tout ce que tu listes. C’est notamment pour ça que pour l’instant j’ai quasiment toujours utilisé Symfony comme ossature. C’est lourd mais il y a un côté réconfortant et sérieux niveau sécurité, que j’apprécie beaucoup.

Mais dès qu’on veut quelque chose d’un peu plus réactif et moderne que Twig, Symfony devient une plaie à configurer et utiliser. D’où ma volonté de découpler les deux pour ce projet, et mon appréhension sur la gestion de la sécurité sur ce projet. Pas fan du tout des identifications JWT.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte