Uma das decis\u00f5es que tomamos<\/a> ao definir o padr\u00e3o para nossas APIs \u00e9 que usar\u00edamos JSON com snake_case <\/strong>pois consideramos que para a leitura de logs por humanos, esse formato \u00e9 mais leg\u00edvel do que camelCase<\/strong>. No nosso Back-end, feito em Kotlin<\/a>, utilizamos a biblioteca em java, GSON<\/a>. Ela transforma os objetos JAVA em uma representa\u00e7\u00e3o em JSON e vice-versa. Para que a serializa\u00e7\u00e3o\/deserializa\u00e7\u00e3o funcionasse com snake_case<\/strong> foi necess\u00e1rio passar o par\u00e2metro FieldNamingPolicy<\/em> com o valor LOWER_CASE_WITH_UNDERSCORES <\/em>na configura\u00e7\u00e3o do client do GSON. (Imagem\u00a0abaixo)<\/p>\n Dessa forma ficamos com o padr\u00e3o snake_case<\/strong> no Back-end em todas as nossas APIs e camelCase<\/strong> em todos os projetos de Front-end, ou seja, o corpo de nossas requisi\u00e7\u00f5es e respostas HTTP s\u00e3o formados por um JSON com padr\u00e3o snake_case<\/strong>.<\/p>\n Com isso temos o seguinte problema: Como utilizar camelCase<\/strong> no Front-end, sendo que todas as solicita\u00e7\u00e3o para as nossas APIs HTTP teriam que ser feitas com snake_case<\/strong>?<\/p>\n Para realizar nossas chamadas HTTP no Front-end, utilizamos a biblioteca ky<\/a> ( ), que adiciona algumas funcionalidades da fetch API<\/a>, entre elas, os hooks<\/a> que permitem modifica\u00e7\u00f5es da requisi\u00e7\u00e3o e de seu payload<\/em> durante o ciclo de vida dessa\u00a0chamada.<\/p>\n Conseguimos ent\u00e3o, resolver esse problema criando um conversor, antes das requisi\u00e7\u00f5es e ap\u00f3s as respostas, utilizando os hooks beforeRequest<\/strong> (que permite modificar a requisi\u00e7\u00e3o antes dela ser enviada) e afterResponse <\/strong>(que permite alterar a resposta da requisi\u00e7\u00e3o):<\/p>\n O c\u00f3digo JS ficaria da seguinte\u00a0forma:<\/p>\n![\"\"](\"https:\/\/cdn-images-1.medium.com\/max\/840\/1*8xkzcdPXNLHMqnJOgwI2dw.png\")
<\/figure>\nA Solu\u00e7\u00e3o<\/h3>\n
\n