Discussion :

[Coussati]

salut,

j'ai décidé de créer une application (firemonkey) pour mon site web qui, je précise est pour le moment en http (pas https)
habituellement pour faire de simples requêtes j'utilisais le compo indy Idhttpclient (depuis delphi 7)

maintenant il y a plusieurs possibilités, j'aimerais savoir laquelle correspond à mes besoins sachant que je dois constamment interroger la bdd (depuis un script php) afin de savoir s'il y a de nouvelles entrées
rester sur Idhttpclient ? utiliser httpResquest que je ne connais pas, mais que j'ai entendu parlé ? ou un autre ?
d'ailleurs pour Idhttpclient je fais généralement une requête .get ou .post, qui me renvoie la réponse sous la forme string
je n'ai jamais utilisé un autre compo, mais il me semble que pour l'autre que j'ai cité, le résultat est envoyé depuis un évènement ?

après le choix du composant, j'aimerais avoir votre avis sur la méthode à utiliser ? les visiteurs interagissent avec le site web c'est pourquoi je dois mettre à jour l'application assez rapidement, au maximum toute les 1 seconde (moins m'arrangerais)
dans ce cas créer un thread qui lance une requête toutes les secondes est ce une bonne méthode (du côté de notre application, comme tu côté du serveur php) ?
sinon, il me semble qu'il y a une technologie en php, ou on met un script en "écoute", qui renvoie une requête à chaque nouvelle entrée dans la bdd ?

qu'en pensez vous de tout ça mes amis ?

[Paul TOTH]

dans l'unité System.Net.HTTPClient tu as un object THTTPClient qui est plus ou moins similaire à idHTTP...ce n'est pas exactement le même mais il est très semblable. Celui qui utilise des events c'est ICS de F.Piette

après toutes les solutions font du HTTP, c'est juste une question de goût et de couleur.

l'info qu'il manque c'est la nature de ton serveur PHP. En pure PHP hébergé (façon OVH mutualisé) tu ne peux rien avoir de persistant...mais tu peux invoquer un serveur externe (ton Firemonkey s'il est joignable, un VPS...) pour déclencher un traitement.

[pprem]

Pour l'accès web, sans hésitation le "natif" qui se base officiellement sur le plus proche de l'OS : unité System.Net.HTTPClient, classe HTTPClient.

Des exemples en pagaille sur mes dépôts Github dont le récent Planning API : https://github.com/DeveloppeurPascal/Planning-API

Pour les requêtes en boucle, effectivement, si tu as du monde sur le site, le solliciter par des appels réguliers n'est pas la méthode la plus adaptée (selon l'hébergement). Regarde plutôt du côté des WebSockets ou des système SubUnsub comme MQTT. Il existe des implémentations pour Delphi, par contre il faut voir s'il y a ce qu'il faut sur ton hébergement. C'est le serveur ou d'autres clients qui informeront les clients des choses qu'ils ont demandé.

[Coussati]

alors la connexion n'est pas persistante, du coup un serveur comme ovh peut faire l'affaire
actuellement j'utilise wamp installé sur serveur dédié windows, mais je ne serai pas contre la migration sur quelque chose de plus puissant, surtout si je dois solliciter le serveur toute les secondes
mais ... d'après vos dires, vous n'avez pas l'air convaincu par ce principe ? faut il vraiment du persistant ? c'est un peu ce que je voulais éviter en passant par une BDD : mais comme on ne peut pas deviner à quel moment un client interagis, je suis obligé de vérifier l'existence de nouvelles données toutes les secondes afin qu'il n'y ait pas trop de décalage

après j'avais encore une autre idée, que j'avais testé il y a quelques mois depuis une page web (mais que je n'ai pas encore retrouvé)
une fois sur la page, à chaque nouvelle entrée dans la BDD, le serveur envoyait les données
je me disais que ça pourrait fonctionner avec un compo httpclient ?

[Paul TOTH]

avant de chercher quel composant utiliser, commence par mettre au point ton architecture. Je ne la comprend pas d'ailleurs.

Tu as donc des clients Web qui interrogent un WAMP...que vient faire Firemonkey là dedans ? WAMP c'est du Windows, donc ton traitement FMX, pourquoi n'est-il pas directement sur le serveur ?!

[Coussati]

avant de chercher quel composant utiliser, commence par mettre au point ton architecture. Je ne la comprend pas d'ailleurs.

Tu as donc des clients Web qui interrogent un WAMP...que vient faire Firemonkey là dedans ? WAMP c'est du Windows, donc ton traitement FMX, pourquoi n'est-il pas directement sur le serveur ?!

j'ai expliqué ce que j'avais pour le moment, à savoir un serveur web installé depuis wamp sur un windows dédié, mais en fait ce n'est pas vraiment important car je peux le changer par la suite
le principal dans mon projet est de pouvoir communiquer avec une BDD mysql depuis un script php

pourquoi je parle de firemonkey ? parce que j'aimerais que le client puisse être multiplateforme (utilisable depuis windows, comme depuis android ou apple)

pour t'expliquer mon architecture, prenons l'exemple simple d'un tchat :
j'aurais plusieurs clients firemonkey (et donc windows, android, ect)
ils s'authentifient grâce à des requêtes http pour avoir accès à la zone de tchat
une fois sur le tchat, ils envoient du texte à la bdd toujours avec des requêtes http
maintenant comme les autres clients affichent chez eux le texte envoyé par tous les clients ?
grâce à une requête http, celle qui sera exécuté toutes les secondes, qui vérifie s'il y a eu de nouvelles entrées dans la bdd

@pprem pour le moment je n'ai pas beaucoup de client, environ 500 par jours, pour une moyenne de 80 connexions simultanées
mais j'ai pour ambition de les faire monter d'avantage grâce au multiplateforme
concernant la nature des requêtes, c'est la récupération des phrases de tchat envoyées par chaque client

[pprem]

alors la connexion n'est pas persistante, du coup un serveur comme ovh peut faire l'affaire

il y a des tas d'offres chez OVH : du mutu (qui passe bien sur un truc qui interroge toutes les secondes jusqu'à une certaine limite du nombre d'accès concurrents.

surtout si je dois solliciter le serveur toute les secondes

Le problème c'est le volume d'interrogations, pas le fait d'interroger.

Si tu as 10 utilisateurs qui font une interrogation d'un script (qui ne fait pas des requêtes délirantes), ça ne pose pas de soucis quel que soit l'hébergement.

Si tu as 100 000 utilisateurs qui font une requête chaque seconde, il te faudra un serveur dédié ou un VPS avec du Nginx ou NodeJS car Apache aura beaucoup de mal à cause de son architecture. Et le mutu, bien entendu, faut pas y compter même chez du O2Switch qui propose de l'illimité en tout (quoiqu'un test serait amusant à faire pour voir jusqu'à quel point ils sont limités sur leur seule et unique offre d'hébergement).

Si tu es sur un petit projet, peu d'utilisateurs, tu peux rester dans ce mode qui était celui qu'on utilisait dans le temps pour les programmes de messagerie. Si tu as du monde il faut revoir le système ou avoir de quoi assumer la grappe de serveurs qu'il te faudra pour que ça tourne selon ce que tu fais derrière (ou juste pour pouvoir accepter les accès venant de tes clients).