Passez de JSON à Protobuf. Est-ce que ça vaut le coup?
Nous avons REST webservices qui peuvent servir XML ou JSON (WCF). Je joue avec l'idée d'implémenter Protobufs. Pourquoi?
AVANTAGES
- Moins de charge sur les serveurs.
- Taille de message plus petite - moins de trafic.
- Il est plus facile de changer maintenant que plus tard.
LES INCONVÉNIENTS
- Besoin d'être mis en œuvre
- Ça va être plus difficile de dépanner/renifler les messages pour le débogage.
- Je peux activer GZip sur le serveur et JSON consommera autant de trafic
Quelle est votre suggestion et/ou expérience à ce sujet?
La valeur commerciale de leur mise en œuvre dépasse-t-elle le coût?
Si vous implémentez, vous devez changer non seulement votre serveur, mais tous les clients (bien que vous puissiez prendre en charge les deux formats et ne changer les clients que si nécessaire). Cela prendra du temps et des tests, ce qui est un coût direct. Et ne sous-estimez pas le temps nécessaire pour vraiment comprendre les tampons de protocole (en particulier les raisons de rendre le champ obligatoire ou facultatif), ni le temps nécessaire pour intégrer le compilateur protobuf dans votre processus de génération.
La valeur dépasse-t-elle donc cela? Êtes-vous confronté à un choix de "nos coûts de bande passante représentent X% de nos revenus et nous ne pouvons pas le supporter"? Ou même "nous devons dépenser 20 000 $ pour ajouter des serveurs pour prendre en charge JSON"?
À moins que vous n'ayez un besoin commercial pressant, vos "pros" ne sont pas vraiment des pros, juste une optimisation prématurée.
je maintiens apis et quelqu'un avant moi a ajouté protobuf (parce que c'était "plus rapide"). La seule chose plus rapide est RTT en raison de la charge utile plus petite, et cela peut être corrigé avec JSON gzippé.
La partie qui me déplaît est le travail relatif pour maintenir protobuf (par rapport à JSON). J'utilise Java donc nous utilisons le mappage d'objets Jackson pour JSON. Ajouter à une réponse signifie ajouter un champ à un POJO. Mais pour protobuf je dois modifier le fichier .proto, puis mettre à jour la sérialisation et logique de désérialisation qui déplace les données dans/hors des tampons de protocole et dans les POJO. Il s'est produit plus d'une fois qu'une version s'est produite où quelqu'un a ajouté un champ et a oublié de mettre le code de sérialisation ou de désérialisation pour les tampons de protocole.
Maintenant que les clients ont implémenté les tampons de protocole, il est presque impossible de s'en éloigner.
Vous pouvez probablement deviner à partir de cela, mon conseil est de ne pas le faire.