Discussion :

[Snurpsss]

Bonjour,

Résumé: Ma question est de savoir si mon idée de tendre vers Spring et Rest pour l'évolution de mon application est pertinante.

Situation actuelle:
Actuellement mon application (utilisant uniquement Javafx & Maven) fonctionne en mode standalone : pas de serveurs, l'application est déployée directement sur le poste utilisateur.
Basiquement, cette application interroge un serveur sur le web tier toute les minutes et si le fichier qui m'intéresse a été mis à jour, l'application affiche ces données à l'utilisateur.

Problèmes:
- J'ai de plus en plus d'utilisateurs et j'ai peur que le serveur web tier ne 'sature' à un moment (ou qu'il voit trop de requête dans la même minute et ne bloque l'IP derrière laquelle se situent tout mes clients)
- Je souhaite optimiser l'architecture: centraliser l'identification des updates, les clients discutants avec ce "noeud central" (mon propre serveur) pour savoir si les informations ont été mises à jour. Avoir un serveur central permettra aussi des développements futurs.

Mon idée:
Utiliser une application java Spring sur mon serveur (Spring facilitant la mise en place de l'API Rest), qui se chargerait d'interroger toute les minutes le site web et de répondre, via Rest donc, aux demandes d'update des clients.

Problèmes identifiés (pour l'instant):
Je ne sais pas si sur mon "noeud central" (serveur), une seule application suffira (en charge de l'interrogation du site web tiers et de répondre aux requêtes Rest des frontend utilisateurs) ou s'il vaut mieux 2 applications distinctes (une appli java pour rechercher les mises à jour et une autre pour répondre aux requêtes Rest).

Au dela du processus demandant si oui ou non il y a une update, est-il pertinant d'utiliser Rest pour transmettre les updates (un fichier CSV allant de 1 à 30 ko en fin de journée), ou ne vaut-il mieux pas laisser le client accéders en Http au fichier (ce dernier ayant été récupéré lors de la détection de la mise a jour par le processus en charge de la surveillance) ?

Question subsidiaire : quelle est la meilleure solution pour que ma vérification d'update soit faite toute les minutes (dois-je lancer un thread de vérification toute les minutes après que le précédant ai rendu la main ou y a t-il une meilleure solution sous Spring ?)

PS: vous l'aurez surrement compris, je suis un débutant (autodidacte en java, ça sera ma 1ère fois avec Spring, même si j'ai déjà lus quelques tuto)

Merci d'avance pour vos conseils

[gervais.b]

Utiliser une application java Spring sur mon serveur (Spring facilitant la mise en place de l'API Rest), qui se chargerait d'interroger toute les minutes le site web et de répondre, via Rest donc, aux demandes d'update des clients.

Ca me semble effectivement être une bonne idée. Vous déplacez la charge vers votre serveur mais la charge reste la. Si vous avez de plus en plus de client qui font une demande régulière sur votre serveur il faudrait peut-être voir le nombre de "hit" (il y à une modification) et de "miss" (il n'y à pas de modification, le demande est faite pour rien). Si vous avez un gros ratio de "miss" il faudrait peut-être voir à implémenter un protocole qui permettrait a votre backend (noeud central) de notifier les clients quand il y à eu un changement.

Je ne sais pas si sur mon "noeud central" (serveur), une seule application suffira (en charge de l'interrogation du site web tiers et de répondre aux requêtes Rest des frontend utilisateurs) ou s'il vaut mieux 2 applications distinctes

Si vous partez dans cette direction, vous devrez gèrer deux systèmes, ça n'est pas beaucoup mais ça reste peut-être trop pour ce que vous voulez faire. Faites un bonne architecture interne, avec un découpage maximal entre les deux composants pour pouvoir facilement les séparer et les déployer séparément plus tard si le besoin est la. Mais, dans un premier temps, je resterais avec un seul serveur/service/noeud.

Au dela du processus demandant si oui ou non il y a une update, est-il pertinant d'utiliser Rest pour transmettre les updates (un fichier CSV allant de 1 à 30 ko en fin de journée), ou ne vaut-il mieux pas laisser le client accéders en Http au fichier (ce dernier ayant été récupéré lors de la détection de la mise a jour par le processus en charge de la surveillance) ?

C'est à vous seul de répondre à cette question car nous ne maitrisons pas les besoins. Mais si ça s'avère utile, oui c'est pertinant. Vous pourriez avoir deux point d'entrées dans votre API, un pour vérifier les updates et un autre pour obtenir le CSV dans l'état actuel.

Question subsidiaire : quelle est la meilleure solution pour que ma vérification d'update soit faite toute les minutes (dois-je lancer un thread de vérification toute les minutes après que le précédant ai rendu la main ou y a t-il une meilleure solution sous Spring ?)

Spring à tout ce qu'il faut pour planifier, exécuter et observer un batch à intervalles régulières. Malheureusement je ne suis plus assez à jour su ce framework pour vous donner les détails.

[Snurpsss]

Merci pour votre réponse gervais.

Ca me semble effectivement être une bonne idée. Vous déplacez la charge vers votre serveur mais la charge reste la. Si vous avez de plus en plus de client qui font une demande régulière sur votre serveur il faudrait peut-être voir le nombre de "hit" (il y à une modification) et de "miss" (il n'y à pas de modification, le demande est faite pour rien). Si vous avez un gros ratio de "miss" il faudrait peut-être voir à implémenter un protocole qui permettrait a votre backend (noeud central) de notifier les clients quand il y à eu un changement.

J'y ai songé, mais comme je passe au travers de firewall (pour les clients) et ne connaissant que les message de type broadcast/multicast, ce n'est pas à l'ordre du jour. Si vraiment le nombre de miss devient un problème, c est que mon appli se sera envolé et je passerai le flambeau à une vrai équipe de dev (et étant sous spring, un passage en spring cloud pourrait alors être envisagé).

Si vous partez dans cette direction, vous devrez gèrer deux systèmes, ça n'est pas beaucoup mais ça reste peut-être trop pour ce que vous voulez faire. Faites un bonne architecture interne, avec un découpage maximal entre les deux composants pour pouvoir facilement les séparer et les déployer séparément plus tard si le besoin est la. Mais, dans un premier temps, je resterais avec un seul serveur/service/noeud.

Bien noté. Je pars donc sur une implémentation côté serveur avec un seul service. Je vais séparer les taches dans des packages (une partie est déjà dans un package du front end existant). Si le besoin s'en fait sentir, je basculerai la récupération du CSV toute les minutes dans un 2nd service.

C'est à vous seul de répondre à cette question car nous ne maitrisons pas les besoins. Mais si ça s'avère utile, oui c'est pertinant. Vous pourriez avoir deux point d'entrées dans votre API, un pour vérifier les updates et un autre pour obtenir le CSV dans l'état actuel.

Je pense que je vais essayer cela (envoyer le contenu du CSV en Rest), l'implémentation d'autre endpoint Rest étant déjà au programme.

Spring à tout ce qu'il faut pour planifier, exécuter et observer un batch à intervalles régulières. Malheureusement je ne suis plus assez à jour su ce framework pour vous donner les détails.

Je vais chercher.

Encore merci pour votre aide

[gervais.b]

Heureux d'avoir pu vous aider.

N'oubliez pas de marquer votre question comme résolue si vous considérez que c'est le cas.