Pourquoi pas, mais je trouve que c'est encore trop de travail.
Pour un système de billeterie avec point de vente, on codait les services REST en Java et le client en JS/Angular.
Pour une communication supplémentaire (dans le sens, introduite après architecture) entre l'interface "vendeur" et une tablette d'affichage et de saisie destinée au "client", on a vite fait le choix du WebSocket avec un protocole d'échange de messages texte très simple.
On avait déjà ActiveMQ pour assurer du traitement asynchrone en JMS, alors ajouter le support WebSocket s'est limité à créer une queue par POS dans ActiveMQ... le plus long a été de passer en SSL à travers un reverse-proxy. Quantité de code spécifique ajouté au projet, proche de zéro. On a juste sélectionné un client WebSocket en JS.
Évidemment ce n'est pas comparable en terme de performance, tout dépend des objectifs - mais je pense que la conclusion est la même: répondre le plus rapidement possible au besoin avec les compétences de l'équipe.
Et je pense malheureusement que le C++ n'offre pas le cadre initial qui permet de le faire.
Dans ma boîte, on fait essentiellement du Java et du C# mais l'incontournable JS et son écosystème "mouvant" nous pose un problème d'efficacité, de rentabilité et de maintenance à long terme - dans notre contexte de développement sur-mesure (durée de vie > 5 ans), il est difficile de financer à nouveau une "mise à jour" (par exemple après 2 ans) de frontend JS (en général de complexité moyenne à élevée) quasiment au même prix que sa conception initiale... Bref si possible, on préfère fournir une application de bureau en JavaFX ou WPF.
[^] # Re: Java et Maven
Posté par Yves Martin . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 1.
Pourquoi pas, mais je trouve que c'est encore trop de travail.
Pour un système de billeterie avec point de vente, on codait les services REST en Java et le client en JS/Angular.
Pour une communication supplémentaire (dans le sens, introduite après architecture) entre l'interface "vendeur" et une tablette d'affichage et de saisie destinée au "client", on a vite fait le choix du WebSocket avec un protocole d'échange de messages texte très simple.
On avait déjà ActiveMQ pour assurer du traitement asynchrone en JMS, alors ajouter le support WebSocket s'est limité à créer une queue par POS dans ActiveMQ... le plus long a été de passer en SSL à travers un reverse-proxy. Quantité de code spécifique ajouté au projet, proche de zéro. On a juste sélectionné un client WebSocket en JS.
Évidemment ce n'est pas comparable en terme de performance, tout dépend des objectifs - mais je pense que la conclusion est la même: répondre le plus rapidement possible au besoin avec les compétences de l'équipe.
Et je pense malheureusement que le C++ n'offre pas le cadre initial qui permet de le faire.
Dans ma boîte, on fait essentiellement du Java et du C# mais l'incontournable JS et son écosystème "mouvant" nous pose un problème d'efficacité, de rentabilité et de maintenance à long terme - dans notre contexte de développement sur-mesure (durée de vie > 5 ans), il est difficile de financer à nouveau une "mise à jour" (par exemple après 2 ans) de frontend JS (en général de complexité moyenne à élevée) quasiment au même prix que sa conception initiale... Bref si possible, on préfère fournir une application de bureau en JavaFX ou WPF.