Requêtes php dans une application pour mon site web

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 ? :)

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.

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é.

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 ?

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 ?!

Citation:

---

Envoyé par Coussati

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.

Citation:

---

Envoyé par Coussati

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).

Citation:

---

Envoyé par 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 ?!

---

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

Ok, c'est bien ce que je pensais donc.

Faut que tu blindes le truc au niveau du serveur si tu restes dans ce mode de fonctionnement : c'est l'envoi de messages qui met à jour un truc que les clients connectés iront interroger, pas la requête d'info qui ira générer à chaque fois la liste des messages susceptibles d'être récupérés, sinon ça coincera sur ton serveur web et sur ta base de données lorsque tu grossiras.

Mets en place des caches, pas d'interrogation de la base de données si ce n'est pas nécessaire. L'existence et l'ouverture de fichiers locaux est souvent moins consommatrice (mais pareil, ça dépend de l'espace disque alloué). Tu peux t'en servir pour flaguer le fait que quelqu'un ait des messages en attente et n'interroger la DB qu'à ce moment là.

Pour le reste, à toi de tester les montées en charge. L'avantage c'est que ça se simule assez facilement.

Et c'est marrant car je viens d'avoir une notification concernant ce projet justement : https://github.com/LeoUpperThrower4/ChatApp

J'ignore ce qu'il vaut, mais peut-être que tu peux y trouver des idées à adapter dans ton code ?

@pprem dsl mais je n'ai pas compris tes idées
qu'entends tu part "blinder" le serveur ?

Citation:

---

Envoyé par pprem

Mets en place des caches, pas d'interrogation de la base de données si ce n'est pas nécessaire.

---

le problème qui se pose c'est qu'un client ne saura jamaiss'il y a eu une entrée dans la BDD s'il n'interroge pas le serveur !
selon toi à quel moment doit il interroger la bdd ?

en fait je crois qu'on a un peu fait le tour de la question.

soit tu fais du pool, donc les clients, qu'ils soient Web ou FMX viennent demander périodiquement les nouveaux messages avec une requête de type https://server/queryMessages.php?last_id=XXX, c'est à dire quels sont les nouveaux messages depuis le dernier, tu retournes ça en JSON par exemple.

soit tu utilises un serveur capable de faire des WebSocket et tu peux alors faire une connexion persistante entre ton client et le serveur, et du coup dès qu'un client envoie un message, le serveur peut envoyer directement le message à tous les clients connectés en temps réel.

j'ai fait un exemple sommaire de la partie serveur https://github.com/tothpaul/Delphi/t...er/idWebSocket

il ne comprend pas la partie client des WebSocket mais ce n'est pas très compliqué à implémenter, j'en ai déjà parlé ici même quelque part.

je vois que tu utilise un serveur windows, l'application serveur en PHP,!!!!!!?

Citation:

---

Envoyé par Paul TOTH

en fait je crois qu'on a un peu fait le tour de la question.

soit tu fais du pool, donc les clients, qu'ils soient Web ou FMX viennent demander périodiquement les nouveaux messages avec une requête de type https://server/queryMessages.php?last_id=XXX, c'est à dire quels sont les nouveaux messages depuis le dernier, tu retournes ça en JSON par exemple.

soit tu utilises un serveur capable de faire des WebSocket et tu peux alors faire une connexion persistante entre ton client et le serveur, et du coup dès qu'un client envoie un message, le serveur peut envoyer directement le message à tous les clients connectés en temps réel.

---

c'est hors sujet; mais :aie::oops:
soit tu crée ton serveur en delphi, (unigui par ex), et là tu as tout le control,
si non , si to interface client en firemonkey, voir FireBase :aie:

Citation:

---

Envoyé par edam

je vois que tu utilise un serveur windows, l'application serveur en PHP,!!!!!!?


c'est hors sujet; mais :aie::oops:
soit tu crée ton serveur en delphi, (unigui par ex), et là tu as tout le control,
si non , si to interface client en firemonkey, voir FireBase :aie:

---

que le serveur soit sous Delphi ou non ne change pas grand chose...

PHP, outre répondre à des requêtes Apache, permet aussi de lancer un process sur le serveur, et donc il est possible de faire un serveur WebSocket en PHP...mais c'est au même titre qu'on peut le faire sous Delphi.
Comme expliqué dans l'article, on utilise Apache pour faire du reverse proxy vers le serveur

Code:

---

1 2 3 4 5

<Location "/ws/monappli"> ProxyPass ws://localhost:8080 ProxyPassReverse ws://localhost:8080 </Location>

---

et donc le serveur 8080 il est en PHP dans l'article, mais il peut aussi être fait avec Delphi...tout comme le serveur Web avec TidHTTPServer au besoin....C'est le cas dans mon exemple WebSocket sous Delphi

@Paul TOTH tu as très bien cerné ce que je veux faire

Citation:

---

Envoyé par Paul TOTH

soit tu fais du pool, donc les clients, qu'ils soient Web ou FMX viennent demander périodiquement les nouveaux messages avec une requête de type https://server/queryMessages.php?last_id=XXX, c'est à dire quels sont les nouveaux messages depuis le dernier, tu retournes ça en JSON par exemple.

---

c'est exactement ce que je veux faire, pas de websocket ou autres, mais uniquement des requêtes http : tous les scripts php seront sur le même serveur que ma bdd, permettront en autres d'ajouter des entrées ou de lire les nouvelles entrées

@les_autres, maintenant, je n'aurais peut être pas du décrire tout mon environnement (windows, ect) afin de ne pas vous embrouiller

j'ai précisé firemonkey, parce qu'il faut que l'application soit compatible smartphone, et je suppose que sur firemonkey il y a des compo qu'il n'y a pas en vlc (et vice versa)

@Paul TOTH maintenant mon problème est simple : est ce une bonne technique, mon idée de faire une requête http toute les 1 seconde afin de vérifier s'il y a de nouvelles entrée dans la table ?

en local sa fonctionne, avec quelques clients ça fonctionne : mais ce qui m'intéresse, c'est est ce que ce sera efficace avec de vrais utilisateurs ? est ce que le serveur ne laguera pas à un moment donné ? ce genre de ptite chose que je ne peux pas anticiper à l'avance ...

tout dépend de la puissance du serveur et du nombre de clients simultanés

mais il est déjà possible de faire des tests en laçant quelques centaines de thread qui demandent tous la mise à jour...tu verras bien ce qu'en pense ton serveur.

ça veux dire aussi autant de requête SQL sur ta base

c'est pour cela que les WebSocket sont moins lourds, une fois la connexion établie, il ne se passe plus rien tant qu'il n'y a pas un nouveau message, quelque soit le nombre de clients, et le broadcast du message ne demande pas d'accès BDD, c'est le même message qui est envoyé vers tous les clients actifs.

je vais essayer de regarder du côté des websockets, même si je voulais éviter cette piste

il y a quelques mois, je suis tombé sur un tuto qui expliquait 3 notions en php pour "avertir" le navigateur du changement de valeur d'une variable (ou autre)
mais je n'arrive plus à m'en souvenir, ça vous dit quelque chose ?

sinon ? savez vous quelle technologie est utilisé par whatsapp ? car vu le nombre de contact, et la fréquence d'envoie des messages, ça na ressemble pas à une connexion persistante
pourtant les messages sont très bien reçu et pratiquement au même moment entre un smartphone, le navigateur web et l'application windows également

les grosses messageries ne passent pas (rarement) par des serveurs web pour fonctionner, mais des serveurs tout courts

Citation:

---

Envoyé par pprem

les grosses messageries ne passent pas (rarement) par des serveurs web pour fonctionner, mais des serveurs tout courts

---

peux tu développer stp ?
il faut bien un moyen de communication et de stockage ?

Un programme serveur qui écoute sur un port avec des sockets.

Des clients qui s'y connectent.

Un fonctionnement "à l'ancienne" en fait, ça fonctionne depuis les premiers réseaux IP.

Le seul avantage de passer par des trucs liés au web, c'est de bénéficier du protocole http/s qui est déjà embarqué dans les logiciels qu'on utilise (et passer les proxy et autres firewalls). En dehors de ça, ça ne fait qu'ajouter du bla bla sur les réseaux pour un truc qui n'affiche pas de pages web.

je viens de me rappeler de la technologie que j'ai une fois utilisé qui permet au serveur d'envoyer une notification au client, qui donc réclame le nouveau contenu, et n'est plus obligé d'interroger constament le serveur

il s'agit de : Server-Sent Events (SSE)

mais tout bizarrement, peu ou personne n'en parle, sur le forum php non plus ...

on peut le mettre en place je suppose avec un compo idhttp ?

Citation:

---

Envoyé par Coussati

je viens de me rappeler de la technologie que j'ai une fois utilisé qui permet au serveur d'envoyer une notification au client, qui donc réclame le nouveau contenu, et n'est plus obligé d'interroger constament le serveur

il s'agit de : Server-Sent Events (SSE)

mais tout bizarrement, peu ou personne n'en parle, sur le forum php non plus ...

on peut le mettre en place je suppose avec un compo idhttp ?

---

je ne connaissais pas SSE, mais en fait c'est aussi une connexion persistante comme les WS, sauf que seul le serveur peut envoyer des données, et uniquement en texte, alors que les WS peuvent envoyer des données binaires et dans les deux sens.

tu as ici un exemple PHP, tout comme les WS il faut une application serveur (PHP, Delphi...peu importe)

tu pourrais aussi ruser...mais je suppose que cela présente des limitations. dans une requête HTTP classique il est possible de répondre par Chunks, c'est utilisé quand tu dois produire des données dont tu ne connais pas la taille finale à l'avance...du coup tu les envoies par paquets
https://fr.wikipedia.org/wiki/Chunked_transfer_encoding

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

HTTP/1.1 200 OK\r\n Content-Type: text/plain\r\n Transfer-Encoding: chunked\r\n \r\n 26\r\n Voici les données du premier morceau\r\n\r\n 1C\r\n et voici un second morceau\r\n\r\n 20\r\n et voici deux derniers morceaux \r\n 12\r\n sans saut de ligne\r\n 0\r\n \r\n

---

dans l'exemple ci-dessus, la réponse "Tranfer-Encoding: chunked" active ce mode, et tu as la taille des données en hexa suivi des données...donc tu pourrais imaginer conserver la connexion active et envoyer les nouveaux messages au fur et à mesure avec des flush()...mais je ne suis pas certain qu'il soit possible en Javascript de lire les données au fur et à mesure...voici quelques échanges sur le sujet https://stackoverflow.com/questions/...ked-response-i

sous Delphi, il me semble que Indy possède un évènement OnWork ou un truc comme ça qui permet peut-être de choper les infos au fur et à mesure.

mais je suppose qu'à un moment donné ou à un autre la connexion va sauter (timeout PHP ou timeout du navigateur)...à tester