Je m'attendais au LoC...
Mais la complication de KissCache est dans ses dépendances : django, celery, postgres, redis. Et autant de containers lancés. Ah oui et donc docker aussi comme dépendance.
Malgré cela, je pense que ce projet est un très bon démonstrateur pour cette stack. D'ailleurs je m'en sers pour déclencher des chaînes de traitements en self-service.
Mais justement, dans mon cas d'usage il s'agit d'un traitement qui se fera plus tard alors que dans le cas d'un cache, il s'agit d'un traitement qui doit se faire pendant la durée de la requête client.
Autrement dit, le client d'un cache n'attend pas un 'ok je m'en occupe, reviens plus tard' (=http 202) mais un 'ok, voici le résultat de ta demande' (=http 200).
Cela ne justifie pas l'utilisation de celery. Pour moi, l'utilisation de python-request aurait suffit.
Tout ça pour dire que se revandiquer du KISS est toujours casse-gueule.
[^] # Re: vraiment ?
Posté par steph1978 . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 4.
Je m'attendais au LoC...
Mais la complication de KissCache est dans ses dépendances : django, celery, postgres, redis. Et autant de containers lancés. Ah oui et donc docker aussi comme dépendance.
Malgré cela, je pense que ce projet est un très bon démonstrateur pour cette stack. D'ailleurs je m'en sers pour déclencher des chaînes de traitements en self-service.
Mais justement, dans mon cas d'usage il s'agit d'un traitement qui se fera plus tard alors que dans le cas d'un cache, il s'agit d'un traitement qui doit se faire pendant la durée de la requête client.
Autrement dit, le client d'un cache n'attend pas un 'ok je m'en occupe, reviens plus tard' (=http 202) mais un 'ok, voici le résultat de ta demande' (=http 200).
Cela ne justifie pas l'utilisation de celery. Pour moi, l'utilisation de python-request aurait suffit.
Tout ça pour dire que se revandiquer du KISS est toujours casse-gueule.