Refactor/project

[MatheusHAS]

Foi um refactor na aplicação como um todo visando melhorar algumas coisas (que podem ser melhoradas ainda mais)

Algumas atualizações explicadas:

Melhorias aplicadas

Algumas funções como arquivos da pasta Crypto possuiam um conteudo bem parecido, mudando poucos dados, por exemplo:

// ./Crypto/DES/decryptAES.js
const decryptAES = ((decryptMessage, secretKey) => {
  let decrypted = CryptoJS.AES.decrypt(decryptMessage, secretKey).toString(CryptoJS.enc.Utf8);
  return decrypted;
});

// ./Crypto/DES/decryptDES.js
const decryptDES = ((decryptMessage, secretKey) => {
  let decrypted = CryptoJS.DES.decrypt(decryptMessage, secretKey).toString(CryptoJS.enc.Utf8);
  return decrypted;
});

Nos 2 arquivos acima por exemplo, a estrutura é a mesma, alterando apenas qual a função, como CryptoJS.DES ou CryptoJS.AES e boa parte dos outros arquivos seguiam o mesmo exemplo.

Dessa forma resolvi criar o cipher.service.js com intuito de ele lidar apenas com as criptografias em comuns, que usam dos metodos .encrypt, .decrypt ou mesmo os que usam eles mesmos, como é o caso por exemplo do SHA1, que é chamado assim CryptoJS.SHA1(encryptMessage).

Então esse arquivo tem a responsabilidade de lidar com os métodos e boa parte das criptografias do CryptoJS.

Para ser utilizado basta você instanciar falando qual a criptografia a ser utilizada, por exemplo:

const service = new CipherService("AES"); // pode ser alterado para outro método existente no CryptoJS
// Caso a criptografia fornecida não seja existente ou válida, é retornado um throw Error.

const data = "oie";
const secretKeyHere = '123';

const encrypted = service.encrypt({
  message: data,
  secretKey: secretKeyHere,
});

const decrypted = service.decrypt({
  message: encrypted,
  secretKey: secretKeyHere
});

---

Ainda no mesmo arquivo, existiam alguns arquivos nomeados encrypting que também tinham sempre comportamentos bem parecidos, exemplo:

// ./src/Crypto/AES/encryptingAES.js
const encryptingAES = (({pathIn, pathOut, secretKey}) => {
  fs.createReadStream(pathIn)
  .pipe(parse({ delimiter: ",", from_line: 1 }))
  .on("data", (line) => {
    const encrypt = encryptAES( line[0], secretKey);
    writeFile(pathOut, encrypt);
  });
});

esse arquivo tinha responsabilidade de lidar de lidar com o fator de criar um readStream, fazer o parse dos dados de um CSV usando o metodo parse do csv-parse, e também escrevia os dados no path especificado
Para tornar isso mais reutilizavel, criei o read-stream-from-csv.service.js.

Ele tem uma responsabilidade um pouco menor, lidando com 2 coisas comuns em todos arquivos de encrypting, o fs.createReadStream e o parse dos dados CSV. Então ele só faz isso e retorna o ReadStream para quem for consumir, usar os eventos que forem necessários, como por exemplo o .on('data', () => {}).

---

Os arquivos da pasta Files que já tinha uma boa responsabilidade, foram apenas refatorados como uma classe usando metodos estáticos e agora chamados de file.service.js, possuindo 2 metodos FileService.read(filePath) e FileService.write({ path, data }).

---

As rotas foram separadas em um arquivo chamado routes.js, que possui apenas o vinculo entre qual a rota e qual função será chamada para essa rota.

Na parte das rotas agora existe uma rota com /:cryptography/encrypting ou /:cryptography/decrypting, que basicamente é um parametro dinamico que vai ser recebido na função através do const { cryptography } = req.params no código e dessa forma podemos tratar para poder usar do cipher.service.js para ter mais re-uso de código

---

Todas as responsabilidades de cada rota, foi extraia para pasta src/handlers, então todas rotas estão lá, de forma isolada e separadas.

Cada handler, usa os recursos necessários e emite uma resposta.
As respostas emitidas através do res.json() foram padronizadas usando uma classe chamada http-response.js localizada na pasta ./src/utils/http-response.js.

Basicamente foram separados em algusn métodos estáticos, que tem como função, retornar uma instancia da propria classe HttpResponse atribuindo alguns dados, exemplo:

// Resposta de 200 ok
res.json(HttpResponse.ok("Deu certo!", { wordlistEncrypted }));

vai retornar alguns dados seguindo o padrões de alguns campos existentes no HttpResponse, então a resposta seria:

{
  "code": 200,
  "message": "Deu certo!",
  "data": {
    "wordlistEncrypted": []
  },
  "error": false
}

apenas para garantir uma consistencia de padrões de resposta. Também existem alguns outros métodos como HttpResponse.error e HttpResponse.created.

E foi criado também um handler para exibição de erros usando o mesmo HttpResponse, chamado errorHandler, que apenas vai garantir uma visualização dos erros na API de forma que o servidor continue de pé, e exista alguma informação retornada na API.

E é isso, existem muito mais melhorias que podem ser aplicadas, tentei deixar um pouco do que pensei pra fazer esse refactor, e independente do mesmo for aceito ou não, a idéia é que ajude alguem! hehe. é isso é noix!