Discussion :

[SmallFitz]

Bonjour,

Je voudrais faire une application, dont la logique (calculs, vérifications) se trouve sur un serveur.
Je vois cela comme un "modèle".

J'aimerai y lier plusieurs "vues" pour pouvoir le piloter :
- Une appli android
- Un site WEB
- Un logiciel (appli IHM) à installer sur un ordinateur

De manière à ce qu'elles représentent toutes le même "modèle", à leur façon.

Je pensais coder le "modèle" en C++, c'est ce que je maîtrise le mieux.
Pour le site internet, Php ou JavaEE.
Pour l'appli IHM, le C++ ou le java.
Et pour l'appli android, le java.


Je connais peu les technos web, et ne sais pas trop quelle architecture adopter, ni quels protocoles de communication utiliser entre le modèle et les vues.
Auriez vous des conseils à me donner, des mots clefs sur lesquels je pourrai me documenter ?

Merci.

[Logan Mauzaize]

Je voudrais faire une application, dont la logique (calculs, vérifications) se trouve sur un serveur.

C'est plutôt vague comme description. Pour choisir une architecture, il faut penser aux flux de données. Cette logique répond à des messages (ex: queue), à des requêtes (ex: serveur Web), à des demandes asynchrone (ex: ordonnanceur), etc.

J'aimerai y lier plusieurs "vues" pour pouvoir le piloter :
- Une appli android
- Un site WEB
- Un logiciel (appli IHM) à installer sur un ordinateur

Si j'étais toi j’essaierai de me concentrer à fond sur la "vue" qui a le plus de valeur ajoutée. Cela pourra celle avec les fonctionnalités les plus avancées mais cela peut aussi être celle qui sera la plus utilisée diffusée.
Selon la complexité des "affichages", partir sur du full-Web peut-être envisageable.

Je connais peu les technos web, et ne sais pas trop quelle architecture adopter, ni quels protocoles de communication utiliser entre le modèle et les vues.
Auriez vous des conseils à me donner, des mots clefs sur lesquels je pourrai me documenter ?

A partir du moment ou tu as un client Web, tu dois considérer le protocole HTTP et le format JSON. Tu peux utiliser le format XML mais ce sera moins facile à manipuler et à intégrer avec les frameworks récents. Tu peux aussi partir sur de la génération HTML côté serveur mais moins "pratique", cela consomme de la ressource sur le(s) serveur(s) alors qu'il y en a suffisamment à disposition sur chaque poste client. Et cela permet de vraiment te focaliser sur la donnée.

Tu auras alors une architecture en services. Le style REST apporte pas mal de sémantique et le couple REST/JSON est largement supporté. Et en fonction de tes besoins, regarder également du côté de HATEOAS.

Si tu as besoin de faire de la communication asynchrone, je te conseille de regarder AMQP et WebSockets.

Je pensais coder le "modèle" en C++, c'est ce que je maîtrise le mieux.
Pour le site internet, Php ou JavaEE.
Pour l'appli IHM, le C++ ou le java.
Et pour l'appli android, le java.

Ne sachant pas bien le but de ton "modèle", difficile d'imaginer une architecture. Néanmoins, s'agit d'un backend j'opterai plutôt pour du Java, Python ou JavaScript. Le problème c'est que fatalement il faudra communiquer par le réseau et le C++ n'est pas réputé pour ces frameworks Web (mais ils ont le mérite d'exister !)

L'idéale étant d'avoir un seul serveur backend (moins d'artefact à gérer et moins d'inter-communication par le réseau). Du coup pour le "site Internet" ce sera ton "modèle".

Pour également limiter l'éparpillement des ressources, le seul langage commun c'est JavaScript (ou éventuellement des langages qui transpilent en JS). Tu peux par exemple réaliser la partie mobile avec Cordova et le client lourd avec Electron, NW.js, Chrome Apps, ...

Qt est également une option intéressante si le client lourd et le mobile sont tes cibles prioritaires. Qt permet d'exécuter un navigateur et donc une application écrite en HTML5/JavaScript/CSS3.

Voilà quelques pistes mais à affiner en fonction de tes contraintes fonctionnelles et non-fonctionnelles.

Par ailleurs quelle est la finalité du projet ? pour s'améliorer, pour s'amuser, pour implémenter une idée (side project), pour se vendre, pour vendre, etc.

[SmallFitz]

Tout d'abord un grand merci pour ta réponse détaillée, et tes nombreuses pistes. J'ai appris plein de choses.

C'est plutôt vague comme description.

C'est vrai. J'aimerai adapter un jeu de plateau récemment acquis (Risk : Game of Throne) en jeu jouable en ligne.

Par ailleurs quelle est la finalité du projet ? pour s'améliorer, pour s'amuser, pour implémenter une idée (side project), pour se vendre, pour vendre, etc.

J'ai fait des études en informatique, mais n'ai jamais travaillé dans cette branche.
Je cherche un emploi dans celle ci et pour me dérouiller j'aimerai travailler sur un projet concret.
Je voudrais pouvoir le présenter lors de mes futurs entretiens.
D'où l'idée initiale d'utiliser plusieurs "vues" codées dans des langages différents, pour démontrer que je suis capable de toucher à plusieurs choses.
Si j'arrive à le réaliser, et que ça plait, le "vendre" si c'est possible pourrait m'intéresser, oui.

C'est donc pour m'amuser, m'améliorer, implémenter cette idée (qui pourra être reprise pour tout autre projet ce qui doit être accessible en ligne, remplir mon portfolio et éventuellement le commercialiser.

Pour choisir une architecture, il faut penser aux flux de données.

Je pense qu'il s'agirait d'échanges de ce style :
- Client vers Serveur : Demander de faire telle action, ou demande de récupération d'information pour actualiser la vue
- Serveur vers client : Répondre par un code d'erreur, un code de Réussite, ou/et envoi de ou d'objets qui devront être actualisés sur la/les vues.

Selon la complexité des "affichages", partir sur du full-Web peut-être envisageable.

C'est vrai que ce concept est très très intéressant (plus besoin de coder plusieurs clients, de les mettre à jour séparément)...
Ca me donne envie de faire une croix sur l'idée des clients codés en plusieurs langages.

A partir du moment ou tu as un client Web, tu dois considérer le protocole HTTP et le format JSON. Tu peux utiliser le format XML mais ce sera moins facile à manipuler et à intégrer avec les frameworks récents. Tu peux aussi partir sur de la génération HTML côté serveur mais moins "pratique", cela consomme de la ressource sur le(s) serveur(s) alors qu'il y en a suffisamment à disposition sur chaque poste client. Et cela permet de vraiment te focaliser sur la donnée.

Tu auras alors une architecture en services. Le style REST apporte pas mal de sémantique et le couple REST/JSON est largement supporté. Et en fonction de tes besoins, regarder également du côté de HATEOAS.

Si tu as besoin de faire de la communication asynchrone, je te conseille de regarder AMQP et WebSockets.

Le format JSON a l'air pas mal, il permettrait à mon modèle de retourner des Objets.

Il faut que je me renseigne sur l'architecture en service.

L'idéale étant d'avoir un seul serveur backend (moins d'artefact à gérer et moins d'inter-communication par le réseau). Du coup pour le "site Internet" ce sera ton "modèle".

Un copain me conseille d'utiliser un CMS tel que Symphony pour la partie modèle, et de développer une API sur laquelle les clients viendront taper.
La génération HTML côté serveur pourrait être possible via Symphony...
Je ne suis pas assez calé pour savoir comment ça fonctionnerait, et si ça nécessiterait de passer par l'API comme pour les autres vues.
Faut que je me penche dessus.

Je crois qu'il serait bon que je fasse un diagramme représentant ces flux, pour savoir comment doit être "l'API" (si il y a).
Et avant il faudrait que je fasse une liste des actions que les clients peuvent faire, ce sont eux qui sont à l'origine des requêtes sur le serveur donc des flux.

[Logan Mauzaize]

Tout d'abord un grand merci pour ta réponse détaillée, et tes nombreuses pistes. J'ai appris plein de choses.

De rien c'est le but de ce forum

C'est vrai. J'aimerai adapter un jeu de plateau récemment acquis (Risk : Game of Throne) en jeu jouable en ligne.

Attention ! Si l'idée pour un projet perso est intéressante, prends garde aux droits. En effet, ce sujet est soumis à licence et certains éléments ne sont pas libres d'utilisations (y compris - peut-être - certains points de règles).
Tant que tu gardes tout pour toi (et éventuellement faire des démos), cela ne pose pas de problèmes. En revanche si tu dois rendre publique ton projet (ex: GitHub, Heroku, etc.) alors tu pourrais avoir des problèmes.

J'ai fait des études en informatique, mais n'ai jamais travaillé dans cette branche.
Je cherche un emploi dans celle ci et pour me dérouiller j'aimerai travailler sur un projet concret.
Je voudrais pouvoir le présenter lors de mes futurs entretiens.
D'où l'idée initiale d'utiliser plusieurs "vues" codées dans des langages différents, pour démontrer que je suis capable de toucher à plusieurs choses.

Donc mon conseil tient toujours : focalises toi sur une vue et une technologie. Il vaut mieux faire un truc bien au départ et ensuite voir pour l'améliorer ou l'étendre. Surtout si tu veux te dérouiller, il vaut mieux éviter de s'éparpiller.
La meilleure chose pour commencer (vu que le C++ semble avoir tes faveurs), c'est même peut-être un client lourd (par ex. avec Qt) en mode "local" uniquement, puis rajouter un module "réseau" en direct (peer-to-peer) et ensuite ajouter une partie centralisée.

En réalisant ton projet tu vas devoir avancer sur deux tableaux : l'apprentissage technique (comment utiliser les technologies) et celui dit "fonctionnel" (comment implémenter le jeu). Et cela représente déjà un sacré travail.

Sinon s'agissant d'un jeu, il existe également pas mal de framework/outils pour tous les langages. Je te conseille d'aller jeter un oeil et poser tes questions dans la section Développement 2D, 3D et Jeux.

Si j'arrive à le réaliser, et que ça plait, le "vendre" si c'est possible pourrait m'intéresser, oui.

A régler d'abord les problèmes de droit en fonction de ce que tu récupères de ta source d'inspiration. Autrement et si tu fais un truc purement Web, tu pourras te rapprocher du site Board Game Arena


C'est donc pour m'amuser, m'améliorer, implémenter cette idée (qui pourra être reprise pour tout autre projet ce qui doit être accessible en ligne, remplir mon portfolio et éventuellement le commercialiser.

Je pense qu'il s'agirait d'échanges de ce style :
- Client vers Serveur : Demander de faire telle action, ou demande de récupération d'information pour actualiser la vue
- Serveur vers client : Répondre par un code d'erreur, un code de Réussite, ou/et envoi de ou d'objets qui devront être actualisés sur la/les vues.

Ok, il s'agirait principalement d'un serveur "web". Même s'il ne rend pas de page Web à proprement parler.

C'est vrai que ce concept est très très intéressant (plus besoin de coder plusieurs clients, de les mettre à jour séparément)...
Ca me donne envie de faire une croix sur l'idée des clients codés en plusieurs langages.

Dans le cadre d'un projet comme le tiens, la multiplicité des technologies et implémentations peuvent se faire dans un deuxième temps. Montre d'abord que tu sais faire fonctionner quelque chose de simple. De toutes façons avec ton expérience, les gens ne vont pas s'attendre à ce que tu saches tout faire.

Le point principale c'est que tu auras fait l'effort de monter un projet qui tient la route. A la rigueur dans un premier temps, peu importe le contenu. Rien que sur le papier, tu passes en haut de la pile des CVs.

Le format JSON a l'air pas mal, il permettrait à mon modèle de retourner des Objets.

JSON est un format simple mais assez peu autodescriptif (il n'y a pas de typage par exemple). Etant simple, il est facile à générer côté serveur (émetteur) et pas trop complexe à parser côté client (récepteur), du coup tu trouves des bibliothèques pour toutes les plateformes.
Et sur navigateur c'est complétement natif.

Il faut que je me renseigne sur l'architecture en service.

Le grand principe c'est d'avoir des objets et leurs méthodes (servive) qui sont distribués. Il existe ensuite différentes manières de connecter les services et leurs appelants (XML-RPC, Corba, RMI, SOAP, REST, etc.). Souvent ces technologies traitent à la fois la diffusion et la sérialisation.

Un copain me conseille d'utiliser un CMS tel que Symphony pour la partie modèle, et de développer une API sur laquelle les clients viendront taper.
La génération HTML côté serveur pourrait être possible via Symphony...
Je ne suis pas assez calé pour savoir comment ça fonctionnerait, et si ça nécessiterait de passer par l'API comme pour les autres vues.

Je n'ai jamais travaillé avec des CMS donc je ne saurais te dire si c'est adapté ou non. Néanmoins le principe à la base d'un CMS c'est l'édition et la diffusion de contenu. Après ce sont devenus de véritables usines à gaz très ouvertes (on peut facilement yrajouter des fonctionnalités) et pleines de fonctionnalités

Je crois qu'il serait bon que je fasse un diagramme représentant ces flux, pour savoir comment doit être "l'API" (si il y a).
Et avant il faudrait que je fasse une liste des actions que les clients peuvent faire, ce sont eux qui sont à l'origine des requêtes sur le serveur donc des flux.

Dans un premier temps, focalises toi sur l'analyse du jeu. Les différentes phases pensent à ton système comme une sorte de boîte noire dont tu dois définir les entrées sorties. Ensuite tu pourras distinguer parmis les actions de ton système, lesquelles s'effectuent en locales et lesquelles s'effectuent sur un serveur.

[Lakhdr]

To cas de besoin n est pas unique :Une architecture multi tiers SOA fera l affaire
Oui tu peux simplement ecrire une application de services genre REST APi ou autre en (Java, node,Php,.Net....)
Et ecrire plusieurs clients (Web, mobile, Bureau...) avec la techno que tu aimes (Java, javascript, html5, .NET ...,C++) qui vont consommer ces services .
Et voila !