search

guilima / financial-back

Node API structure connection to postgreSQL / redis
MIT License
4 stars 0 forks source link

Queries #6

Closed wagnerssouza closed 4 years ago

wagnerssouza commented 5 years ago

Não sei se deixar todas as queries no mesmo lugar é interessante, eu acho que se o projeto crescer isso poderia virar um problema. Acho que separar as queries seria uma saída.

Talvez usar um ORM possa tirar essa burocracia na escrita, e te da liberdade, caso queira trocar de banco, uma "mudança" menos dolorida. Fora que orm facilita bastante o dia-a-dia.

Esses aqui são bons exemplos de orm:

O que acham? @guilima e @diogosalmeida

https://github.com/guilima/financial-back/blob/14714cbf4e423c9070cfdd7c406cb328d1f7bcea/query.js#L1

guilima commented 5 years ago

Nunca fiz uso de ORM. Com toda certeza vou estudar um pouco para colocar. Desses que comentou tenho referencia do mongoose. Vou adicionar no roadmap da aplicação.

guilima commented 4 years ago

Removi o mongo e resolvi usar o postgres. Nessa versão inclui o knex como query builder e melhorou bastante a padronização e transposição das minhas queries caso resolva utilizar outro banco. Exemplo:

await psqlKnex.select('PAY.id', 'PAY.date', 'PAY.price', 'PAY.installment', 'TRA.type_id', psqlKnex.raw('to_json(PRO.name) as product'), psqlKnex.raw('to_json(CAT.name) as category'), psqlKnex.raw('to_json(MAN.name) as manufacturer'))
      .from('payments AS PAY')
      .innerJoin('transactions AS TRA', 'TRA.id', '=', 'PAY.id')
      .innerJoin('products_manufacturers AS PROMAN', 'PROMAN.id', '=', 'PAY.product_manufacturer_id')
      .innerJoin('products AS PRO', 'PRO.id', '=', 'PROMAN.product_id')
      .innerJoin('manufacturers AS MAN', 'MAN.id', '=', 'PROMAN.manufacturer_id')
      .leftJoin('categories AS CAT', 'CAT.id', '=', 'PAY.category_id')
      .where('PAY.wallet_id', '=', id)
      .orderBy('PAY.date', 'asc');

Acredito que um ORM seria um passo a mais, porém o projeto é pequeno e não senti a necessidade de engessar essa camada ainda.