Retour d'expérience sur une PWA

WRInaute passionné
Voilà, les app natives resteront dans l'histoire comme un incident industriel, qui n'aura heureusement pas duré longtemps.
 
WRInaute accro
L'application que je suis en train de développer a besoin d’accéder à un scanner de code barres, à la carte SD. Pas le choix, le PWA ne convient pas (encore).
 
WRInaute accro
Mais le pwa a ses limites.
Dans le cas d'un site dynamique qui plus est e-commerce, je ne vois pas comment une pwa puisse être utile. En cas de offline, tu ne devrais pas accéder au processus panier > commande. Lorsque l'acheteur retrouve une connexion et que le site fasse sa maj, le vendeur pourrait se retrouver avec X commandes pour un seul produit, non ?
 
WRInaute passionné
Mais le pwa a ses limites.
Dans le cas d'un site dynamique qui plus est e-commerce, je ne vois pas comment une pwa puisse être utile. En cas de offline, tu ne devrais pas accéder au processus panier > commande. Lorsque l'acheteur retrouve une connexion et que le site fasse sa maj, le vendeur pourrait se retrouver avec X commandes pour un seul produit, non ?

L'article qu'il a partagé parle justement de e-commerce : Etam et Rue du Commerce.

Je ne comprends pas exactement ce que tu veux dire, une PWA peut faire en offline la même chose qu'une app classique. Le code est en JS, côté client. Ce qui est mis en cache local est comme l'a choisi le développeur de la PWA (petit à petit, par exemple mettre en cache ce qu'on a déjà visité, on charger tout un tas de choses dans une base locale au moment de "l'installation", ou rien du tout comme un site web...).
Et quand on retrouve une connexion, on s'occupe de synchroniser, en fonction des dates de connexion. La problématique est la même sur une app classique... Pas simple dans les 2 cas celà-ci.

L'application que je suis en train de développer a besoin d’accéder à un scanner de code barres, à la carte SD. Pas le choix, le PWA ne convient pas (encore).

Ca viendra, j'ai parlé du "futur" :D Mais "globalement", on passe d'une époque où chaque petit site sans moyen voulait développer ses apps Android, iPhone, Windows... à une époque où la majorité des sites préfèreront améliorer leur site pour en faire une PWA que de s'embarquer dans des devs lourds.

Et je mets de côté aussi Google et Apple qui pré-installent ce qu'ils veulent sur leurs systèmes, eux sont des cas à part.
 
WRInaute accro
Je ne comprends pas exactement ce que tu veux dire, une PWA peut faire en offline la même chose qu'une app classique. Le code est en JS, côté client. Ce qui est mis en cache local est comme l'a choisi le développeur de la PWA (petit à petit, par exemple mettre en cache ce qu'on a déjà visité, on charger tout un tas de choses dans une base locale au moment de "l'installation", ou rien du tout comme un site web...).
Oui c'est le principe même d'une pwa
Et quand on retrouve une connexion, on s'occupe de synchroniser, en fonction des dates de connexion.
Et voilà, tu fais référence à ce que tu n'as pas compris dans mon dernier message.
La synchro !

Imaginons, je vais en pleine campagne y passer le WE. Pas de connexion (comme bien souvent malheureusement). J'utilise la pwa pour faire un achat samedi.
Je rentre à la maison dimanche soir. Lorsque je vais retrouver du réseau, la pwa va donc faire sa synchro.
Et là.... qu'est-ce qu'il se passe si X personnes a fait l'achat du même produit pendant le WE ? Je n'ai pas pu le savoir puisque la pwa ne pouvait pas faire de syncro ?!
Non seulement je paye un produit inexistant mais en plus, le vendeur se retrouve avec X commandes pour un produit unique !

Mais en écrivant ses lignes, je me rends compte qu'il ne pourrait pas payer puisqu'il n'aurait pas de réseau.

Dois-je en conclure que durant du offline, le site stocke des demandes d'achat mais ça en reste là? Lorsque le réseau revient, les demandes d'achat sont traitées en fonction des stocks disponibles et lui transmettre un lien de paiement pour finaliser la commande ?
Bah si c'est ça... c'est beaucoup de paramètres à prendre en compte. Et plutôt galère à mettre en place...
 
WRInaute passionné
Dois-je en conclure que durant du offline, le site stocke des demandes d'achat mais ça en reste là? Lorsque le réseau revient, les demandes d'achat sont traitées en fonction des stocks disponibles et lui transmettre un lien de paiement pour finaliser la commande ?
Bah si c'est ça... c'est beaucoup de paramètres à prendre en compte. Et plutôt galère à mettre en place...

Ben oui (enfin stocké sur le mobile, pas sur le site, puisque pas de connexion...), et quand la connexion revient, on peut lui dire "trop tard, stock épuisé". Un panier n'est pas une commande, la commande est en attente.
Mais tout ce que tu dis est vrai, seulement quelle différence avec une "app classique" Android/iPhone ? Aucune. Les gens téléchargent l'app sur leur mobile, et quand ils n'ont plus de connexion, elle ne sait pas plus qu'une PWA où en sont les stocks !
 
WRInaute accro
@rick38 merci pour ces précisions. J'ai eu l'occasion de mettre en place des pwa mais pas pour du ecommerce, pour les raisons plus haut. Je comprends mieux, merci.
Mais cela reste effectivement un drôle de merdier car premier arrivé, premier servi. Si X commandes sont en attente, le 1er utilisateur à avoir du réseau, la pwa pourra traiter sa commande et les autres, ils l'auront dans l'os.
Je ne pense pas que cela soit très "vendeur" pour un site qui accepte en offline de faire des promesses de vente puis l'acheteur reçoit un message en lui disant : "Ah bah nan... tu peux pas acheter ce produit.... il est épuisé !" alors que la veille, le même site a accepté de le mettre en panier.
ça fait pas très pro, AMHA. L'acheteur s'en fout de savoir s'il a du réseau ou pas quand il est sur le site. Dès lors que le site est disponible pour lui, c'est du cas réel. Il considère sa connexion au site comme opérationnelle. A moins de lui notifier qu'il est en offline et que sa commande sera traitée selon les disponibilités du stock.
Bref... un drôle de merdier ;)
 
Discussions similaires
Haut