Conexão com o banco & Migrations #61
Comments
|
Massa, @huogerac! Das opções que você trouxe eu já utilizei o TypeORM, sempre com TypeScript. Porém, é possível utilizá-lo com JavaScript também, tanto puro quanto utilizando Babel para utilizar recursos experimentais da linguagem. Exemplos na documentação do TypeORM: O mesmo serve para o Prisma. Aqui na documentação tem o getting started com JS: Esse último eu nunca cheguei a utilizar. Mas dei uma olhada na documentação e me pareceu interessante. Gostei da forma como é feita a configuração, me parece mais simples de entender. Além disso, tem também o famoso Sequelize, opção madura também. Confesso que fiquei um pouco animado para testar o Prisma, mas não tenho experiência para dizer se é uma opção segura, sendo que acredito ser o mais novo dos aqui citados. Quem conhecer o funcionamento dessas bibliotecas especificamente com o Next.js, caso exista alguma diferença significativa, pode contestar haha |
|
A grande desvantagem que eu vejo em não usar um ORM é se precisar migrar o banco de dados. Já tive que fazer isso no passado e foi um trampo gigante, pois era tudo na mão e existiam comandos que não eram compatíveis entre os bancos. Na minha opinião o ORM ajuda nisso, e caso precisar fazer alguma query mais complexa que o ORM complique ou não de suporte, essas sim seriam feitas em SQL puro. Acredito que aqui também entraria aquela questão que o @filipedeschamps pontuou, no qual o MySQL está mais preparado para um ambiente serveless do que o Postgres, por exemplo. Se quisermos começar com um e depois mudar para outro poderíamos ter um grande retrabalho. |
|
Opa pessoal, tudo certo? Um exemplo de aplicação que usa o que o projeto já tem especificado está nesse post: |
cezarmezzalira
modified the milestones:
Milestone 1: Fundação,
Milestone 2: Auth, Usuários e Notícias
|
Pessoal ficou definido se vamos de MySQL 🎉️ ou PostgreSQL 🚀️ ? |
|
O @filipedeschamps tinha comentado sobre usar Postgres (PG), pois já era um banco que ele tinha usado na pagar.me com um ótimo desempenho. Ele também pontuou a questão de que gostaria de explorar o máximo do PG. |
Vocês topam sofrer comigo? 😂Vamos implementar na raça nossas entidades e escrever na unha o SQL? De ORM eu já usei o Sequelize e adoro ele, de fato fazer todo o CRUD sai de graça, e como apontado pelo @rhandrade na hora de mudar de banco de dados, um ORM facilita bastante. E sempre dá para fugir dele escrevendo as queries de forma Mas novamente eu pergunto, vocês topam sofrer comigo? Vamos para esse projeto fazer as coisas na mão, para realmente aprender um pouco mais sobre modelagem e principalmente SQL? Eu me sinto muito mais future proof ou a prova de balas dando um upgrade nas minhas habilidades sobre isso. Claro que a gente não precisa tirar todas as abstrações ao ponto de implementar nosso próprio conector 😂 mas sugiro usar algo como o módulo pg. E eu vejo que independente do vai e volta de ORMs ou Query Builders, a base fica ali sólida, nesse caso o conector com o banco de dados, e dá pra ver no número de downloads desse módulo. E é super simples usar ele, olha só um trecho de código (simplificado, tinha mais coisas) que fiz em outro projeto: // database.js
import { Pool } from "pg";
const pool = new Pool();
async function query(query) {
const results = await pool.query(query);
return results;
}
export default {
query
};Ele usa o // qualquer-dado.js
import database from "database.js";
async function QualquerDado(request, response) {
const query = {
text: `
select *
from tabela
where coluna = $1;
`,
values: ["turma"],
};
const result = await database.query(query);
return response.json({
count: result.rows.length,
dados: result.rows,
});
}
export default QualquerDado;Quanto a MigrationTem um módulo chamado node-pg-migrate que é muito simples de usar, e aceita o Client criado pelo Conclusão?Como estamos em um ambiente novo, super serveless eu diria 😂 , me sinto muito mais seguro ter um pouco mais controle nessa camada. Não que isso vá nos dar menos problemas, iclusive deveríamos colocar nossa expectativa que inicialmente teremos mais problemas, mas também mais conhecimentos sobre o que está acontecendo, e pra mim isso tem valor infinito. Fora que, novamente, independente das novas abstrações que criarem, a nossa base vai continuar sólida. Topam? |
|
Sobre esse tema, já utilizei o Sequelize também, minha experiência com essa lib foi das melhores 😄. Acredito que SQL não é um assunto trivial, e utilizando um ORM, perdemos um pouco dessa essência de entender a fundo o comportamento de cada comando e o quanto isso pode refletir possitivamente / negativamente em nossa aplicação. @filipedeschamps , analisei sua sugestão, acredito que podemos ter uma grande evolução nesse quesito. A única coisa que ainda eu me perguntaria é: Será que devemos nos preocupar nesse momento com a possibilidade de mudar o banco de dados? Porque se esse for o caso, vamos ter que ficar cientes que futuramente teremos um "trabalho" maior ao realizar a migração ( coloquei em aspas porque tudo coopera para nosso crescimento ). |
Excelente pergunta @brunofamiliar pensando aqui, sempre existe essa possibilidade e se ela vier a se tornar realidade, o que prevejo de impacto tirando a parte de infraestrutura é o seguinte:
E como qualquer previsão em tecnologia, o que realmente vai acabar acontecendo é a soma dos problemas previstos vezes 10 😂 mas é o que é 👍 |
|
Show! Eu topo encarar esse desafio 😄 |
|
Vou contar uma coisa caras: sou viciado em escrever queries SQL 🤣🤣 CHALLENGE ACCEPTED😎 |
|
Show @filipedeschamps seguindo essa linha de raciocínio faz sentido seguir com algo mais mão na massa. Topo encarar esse desafio. 😄 |
|
Super apoio a escolha de usar SQL! Inclusive, dando preferência para SQL Standard sempre que possível. Uma coisa que pode ajudar na transição para outro banco de dados é documentar quais queries utilizam funções específicas do banco de dados atual. Quanto ao futuro, que é serverless, vocêm sabem né? 😆 acredito que os serverless databases irão evoluir para suportar SQL direto no Edge (possivelmente a partir do SQLite, que até já é possível executá-lo em Lambda ou Worker). Então, usando SQL, estaremos sempre bem preparados 😉 |
|
SELECT * FROM membros-da-turma WHERE challenge LIKE "ACCEPTED" Bora!!! |
|
Sensacionaaaal turma 😍 Então sobre onde hospedar o banco de dados, lendo uma discussion lá no repo da Vercel, o Digital Ocean se demonstrou uma excelente solução para um banco Postgres, pois com um clique você consegue colocar na frente da instância o Porém vocês aceitaram sofrer junto comigo 😂 e o que acham de subir uma instância primeiro sem o E isso me fez entender que teremos que configurar um ótimo Log Drain e configurar algum tipo de alerta em algum lugar. Acham válido adicionarmos isso na próxima Milestone? Não temos nada sobre logs em nenhum lugar. |
|
Pessoal, uma das minhas principais preocupações sobre usar SQL diretamente é o SQL Injection, que é algo que foi levantado nessa thread aqui. const database = require('../infra/database');
exports.getPosts = function () {
return database.query('select * from blog.post');
};
exports.getPost = function (id) {
return database.oneOrNone('select * from blog.post where id = $1', [id]);
};
exports.getPostByTitle = function (title) {
return database.oneOrNone('select * from blog.post where title = $1', [title]);
};
exports.savePost = function (post) {
return database.one('insert into blog.post (title, content) values ($1, $2) returning *', [post.title, post.content]);
};
exports.updatePost = function (id, post) {
return database.none('update blog.post set title = $1, content = $2 where id = $3', [post.title, post.content, id]);
};
exports.deletePost = function (id) {
return database.none('delete from blog.post where id = $1', [id]);
};Talvez seja por ai que a gente deve começar :) |
|
Sobre onde hospedar, a Amazon possui um banco de dados SQL voltado para serverless, é o Amazon Aurora Serverless. Na prática, é um MySQL otimizado para trabalhar com um número grande de conexões e com recursos auto escaláveis. Existe o V1 e o V2 (que em breve deve sair do Preview). Uma vantagem que vejo, é o back-end estar mais próximo ao banco de dados (assumindo que a estrutura de back-end da Vercel esteja na AWS). Outra vantagem é o custo, que deve ser menor quando o projeto ganhar proporções maiores (mas talvez não agora no início, onde um custo mínimo fica por volta de R$ 300 por mês). Existe ainda um outro serviço, chamado AWS RDS Proxy, que serve justamente para intermediar as conexões entre o back-end serverless e o banco de dados. |
|
Ahhh que massa @boemekeld eu lembro que tinha visto isso no passado, achei fantástico, mas acabei não me aprofundando por ser MySQL (e mais uma vez, MySQL na frente no mundo serverless, interessante né?) e também vi que não era possível expor ele para o mundo (pelo menos na época), a conexão tinha que ser por dentro de uma VPC, daí o backend da Vercel não vai conseguir entrar. Mas talvez daria para expor o Proxy? E usar a AWS facilitaria o billing aqui do meu lado, ficaria tudo num único lugar, porque já uso o Glacier para fazer backup dos vídeos. E sobre custo, me surpreendeu esses R$ 300 por mês mínimos, dado que eles batem bastante na tecla do custo 👍 Bom, de qualquer forma, sugiro continuar no caminho da gente presenciar o comportamento das conexões estourando 😂 |
|
@filipedeschamps sim, eles prometem compatibilidade com PostgreSQL, mas na prática o MySQL está na frente! Sobre a conectividade com mundo externo, sim, você precisa usar uma VPC, porém, sua VPC pode ter conexão externa, para isso ela precisará de um Internet Gateway configurado (a desvantagem é que o VPC também terá um custo, #malditos). No caso do RDS proxy, acredito que seja possível conectar de fora sem VPC. De qualquer maneira, também apoio a ideia de testar o limite das conexões 😉 |
|
Tenho um servidor (host) na AWS, é possivel criar um banco de dados a partir de $15, Não utilizo o plano de banco de dados, pois tenho um host lá já com banco. Mas parece ser legal.
|
|
Hey pessoal, O que voces acham desta ideia aqui: Usar um droplet de $5 na Digital Ocean e instalar o Postgres. Eu fiz isto algumas vezes, teve projeto que decolou e migramos para a AWS com backup e tudo mais, o serviço RDS da AWS é fantástico. Sem palavras. MAS, mas para início, e digo mais, da para aguentar muita coisa com este droplet de 5 doletas. E na linha do @filipedeschamps de ver os problemas acontecerem... Enfim, se gostarem desta ideia, consigo fazer instalação automatizada via ansible (para facilitar replicação) e deixar um postgres rodando na D.O. de forma que fica fácil migrar, seja para outro droplet com mais memória ou outro servidor em outra cloud. |
|
@huogerac eu uso DO e acho muito barato para começar. |
|
@huogerac detona!!! Vai ser muito massa ter essa automação! |
|
Eu não entendo muito bem sobre parte de infra pessoal, mas está sendo muito massa aprender com vocês 😄. Sobre o DO droplets, até onde eu li, eles ainda não fornece CDN e o backup de banco é algo cobrado a parte. Mas acredito que nesse momento deve ser uma boa opção a ser adota pelo projeto visto que, conforme mencionado pelo @huogerac; a transição para outra base no futuro pode acontecer de forma fluída, e os recursos existentes vão comportar muito bem a aplicação. |
Resumo:Temos um postgres 11 rodando e aberto para o mundo (MEDO), instalei para validar em um servidorzinho que tenho na D.O. (chamei de ambiente dev).
Notas:
Qual a ideia:
Passo a Passo para instalação
Como ver o arquivo de configuração?
Próximos passos
Pessoal, acho que é isto, espero que não tenha ficado complicado demais. Tem meu email ai no post, se tiver algo que não esteja muito claro. Todos arquivos do ansible estão na branch: Não abri PR ainda, para esperar avaliação de voces. |
|
Show de bola @huogerac! Muito obrigado por colocar a mão na massa dessa forma!!!! Então ultra-resumão foi subir um droplet de Ubuntu, configurar ele, e daí instalar e configurar o Postgres. Como efeito colateral, é preciso gerenciar as chaves, segredos e manter o OS atualizado (e o banco). Você já testou o Postgres gerenciado da DigitalOcean? Eu nunca testei, só usei o Postgres no RDS na AWS e era muito bom. Vou fazer um teste aqui para sentir se ele abstrair parte desse trabalho, e ver se talvez ele consegue nos entregar na mão a url de conexão e credenciais, porque daí é só questão de cadastrar isso nas variáveis de ambiente da Vercel e a aplicação em prod ou staging podem usar diretamente. Acredito que vai ser mais caro que um droplet, mas o tradeoff é que não iremos precisar nos preocupar com os patches de segurança da máquina. Vou fazer uma conta aqui e assim que fizer retorno aqui com os resultados. PS: Desculpa a demora para interagir com as issues, essa semana o Oliver pegou pesado aqui em casa 😂 |
Turma, esse foi o resultadoDepois de configurar o billing da nova conta que criei (acabei ganhando $100 dólares de crédito), escolhi a opção de criar um banco de dados gerenciado e essa tela abaixo é basicamente o que se precisa escolher pra criar o banco, e como vocês podem ver, a instância mínima é mais cara e custa $15 dólares.
ConfigDepois ele ajuda você a fazer algumas configurações, onde o segundo passo é ele pedindo para você fechar o banco de dados para internet, e deixar disponível só pra rede interna.
CredenciaisPulei essa etapa, pois precisamos expor ele pros servidores da Vercel, e ele já retorna url de acesso e credenciais (eu alterei antes do print):
Pool e Patches de SegurançaO legal é que ele já fornece uma opção para você configurar o
BackupsNão encontrei onde ficam os backups, só encontrei isso (e to confuso):
Tela do PoolO que achei legal é que ele mostra que nossa atual instância só suporta 22 conexões simultâneas, mas já oferece uma forma fácil de configurar o pool. Eu não vou fazer agora, para realmente enfrentarmos esse problema e deixar nossa aplicação mais robusta, mas achei bem legal a interface.
ConclusãoAchei bem interessante, foi um pouquinho mais caro que pensei que seria para a instância mínima, mas bastante conveniente, principalmente para não se preocupar com patches de segurança do OS (que é transparente) e minors do Postgres e imagino que fazer upgrade major do Postgres ou aumentar a instância imagino ser fácil também. Por outro lado, o que fiz não é Devops, porque foi tudo no braço 😂 Talvez o que podemos fazer é começar assim, e depois quando o projeto estiver parando em pé economicamente falando, fazer todo esse setup de novo na AWS e usando um Terraform da vida (porque eu acho que eventualmente a gente vai usar outros serviços de lá como S3). E essa migração também vai gerar bastante conhecimento. Qual a impressão de vocês? |
|
Massa que $15 doletas da para ser uma opção já para este projeto! Tem varias vantagens sim!
Enfim, se $15 conto não é problema! Massa! este serviço da D.O. é bom sim! e o backup/restore é tranquilo, tenho ansible pra isto, a gente faz em outra issue na hora q precisar |
|
Show @huogerac bom ponto sobre os dois ambientes e de fato eles gerenciados ficarão bem mais caros que em 1 droplet. Mas dois cuidados que eu tomaria em unir esses dois ambientes é em disponibilidade (por exemplo o banco dev consumir todo recurso da máquina por um erro, afetando o banco de prod), e segurança, pois fica fácil escalar acesso de dev para prod 👍 Bom, eu to colocando a mão na massa aqui para fazer essas coisas rodarem em ambiente local com |
|
Bem legal o banco de dados gerenciado, você consegue abstrair todos os possíveis problemas de OS, com uma diferença bem baixa no valor. Acabou que ficou o mesmo preço do Banco gerenciado na AWS ambos são $ 15,00. Digital Ocean AWS Sobre o bkp achei esse link informando que não existe um custo adicional para o mesmo, e o bkp é diário. |
|
Pessoal, Apenas para referencia e para complementar a branch que instala um Postgres na D.O usando Ansible. |
|
Hey @filipedeschamps https://github.com/huogerac/devops-tools/tree/main/devops/terraform/aws/rds |
|
@huogerac show!! Como preciso deixar o banco público para a Vercel conseguir se conectar, tive que dar um balão maior, olha só: terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 3.0"
}
}
}
provider "aws" {
region = "us-east-1"
profile = "tabnews"
}
# Criar uma nova VPC que resolva DNS
# e consiga fazer acesso a internet.
# Esse recurso vai ser usado por:
# 1. Internet Gateway
resource "aws_vpc" "staging" {
cidr_block = "10.0.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
tags = {
Name = "staging"
}
}
# Criar um internet gateway que se
# conecta com a VPC ali de cima.
resource "aws_internet_gateway" "staging" {
vpc_id = aws_vpc.staging.id
tags = {
Name = "staging"
}
}
# Pega todas as Availability Zones que estão
# disponíveis na "region" declarado no provider "aws"
data "aws_availability_zones" "available" {
state = "available"
}
# Faz um loop para criar um subnet por cada
# availability zone. O RDS tem um requisito
# de ter no mínimo 2 subnets. Que nesse caso,
# vai ser criado 2 subnets públicas.
resource "aws_subnet" "database_staging_public" {
count = 2
vpc_id = aws_vpc.staging.id
cidr_block = cidrsubnet(aws_vpc.staging.cidr_block, 8, count.index)
availability_zone = data.aws_availability_zones.available.names[count.index]
map_public_ip_on_launch = true
tags = {
Name = "database_staging_public"
}
}
# O RDS também tem um requisito de ter um
# subnet group, que nesse caso vai pegar dinamicamente
# todos os subnets criados acima.
resource "aws_db_subnet_group" "staging_public" {
name = "database_staging_public"
subnet_ids = aws_subnet.database_staging_public.*.id
tags = {
Name = "database_staging_public"
}
}
# Como vamos expor o banco de dados de forma pública
# eu precisei criar um Route Table que mapeia o caminho
# entre a VPC e o Internet Gateway e que vai ser
# usado por todas as subnets logo ali em baixo.
resource "aws_route_table" "staging_public" {
vpc_id = aws_vpc.staging.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.staging.id
}
tags = {
Name = "staging_public"
}
}
# Nesse ponto a gente faz a associação entre o Route Table
# criado acima e todas as subnets públicas disponíveis.
# Assim elas conseguem acessar a internet.
resource "aws_route_table_association" "staging_public" {
count = length(aws_subnet.database_staging_public)
subnet_id = aws_subnet.database_staging_public[count.index].id
route_table_id = aws_route_table.staging_public.id
}
# Pelo que lembro, esse não foi um ponto necessário para dar
# acesso público ao RDS, mas quando ele era criado sem definir
# um Security Group, ele usava um padrão disponível na conta
# e que liberava tudo. Preferi criar um específico para o
# tipo de acesso e porta do banco.
resource "aws_security_group" "postgres_staging" {
name = "postgres-staging"
vpc_id = aws_vpc.staging.id
ingress {
from_port = 3297
to_port = 3297
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
ipv6_cidr_blocks = ["::/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
ipv6_cidr_blocks = ["::/0"]
}
}
# Isso gera uma nova senha randômica, e que vai
# ser usada no banco de dados.
# ATENÇÃO: por enquanto não estou utilizando,
# mas é só para facilitar nos testes.
resource "random_password" "password" {
length = 32
special = true
override_special = "!#$%&*()-_=+[]{}<>:?"
}
# Criar um RDS de PostgreSQL.
# Tem vários parâmetros comentados e hardcoded, porque
# estou estudando e testando tudo ainda. E a ideia é exportar
# vários desses valores para algo como um Secret Manager da AWS.
# Eu quero fazer o commit desse arquivo aqui no repositório
# do TabNews e não quero expor nada, nem a porta que foi utilizada.
resource "aws_db_instance" "postgres_staging" {
identifier = "postgres-staging"
storage_type = "gp2"
allocated_storage = 20
engine = "postgres"
engine_version = "13.3"
# engine_version = "14.1"
instance_class = "db.t4g.micro"
name = "test1234"
username = "test1234"
password = "test1234"
# password = random_password.password.result
port = 3297
publicly_accessible = true
multi_az = false
max_allocated_storage = 20
allow_major_version_upgrade = false
auto_minor_version_upgrade = true
db_subnet_group_name = aws_db_subnet_group.staging_public.name
vpc_security_group_ids = [aws_security_group.postgres_staging.id]
apply_immediately = true
backup_retention_period = 0
skip_final_snapshot = true
# final_snapshot_identifier = "test" # Não vou usar, pois faço skip_final_snapshot = true
# timezone = "" # Preciso disso?
# backup_window = "03:00-04:00" # Em qual timezone isso funciona?
# delete_automated_backups = true # Pesquisar mais sobre isso.
# maintenance_window = "wed:03:00-wed:04:00" # Em qual timezone isso funciona?
# availability_zone # Preciso definir isso?
# license_model = "license-included" # O que é isso?
# monitoring_interval = "5" # O que isso faz?
# performance_insights_enabled = true # O que isso faz?
# replicas = 1 # Vamos precisar? Muito caro?
tags = {
Name = "postgres_staging"
}
}
output "postgres_staging_username" {
value = aws_db_instance.postgres_staging.username
}
output "postgres_staging_password" {
value = aws_db_instance.postgres_staging.password
sensitive = true
}
output "postgres_staging_endpoint" {
value = aws_db_instance.postgres_staging.endpoint
} |
|
Que massa, vou olhar com calma mais tarde! massa que tem tudo comentado! |
|
Oi @filipedeschamps, chegou a dar uma olhada no PlanetScale? é uma opção interessante, tenho escolhido ele ao invés do RDS. Fica tudo muito mais simples, sem a necessidade de configurar RDS e VPC. E tem uma funcionalidade de branch e pull request em alterações do banco de dados, delicinha! 😆 |
|
@huogerac show! Fiz alguns ajustes legais (principalmente pra ficar tudo 100% na hora do destroy) e agora estou modularizando para conseguirmos ter a infra de staging e production "iguais", e por iguais eu digo que a topologia vai ser a mesma, mas é importante ter a flexibilidade de na de staging poder escolher um banco mais fraco, sem backup e em @boemekeld show! Cheguei a avaliar o PlanetScale e é uma solução sensacional. A escolha de usar o Postgres foi literalmente para se ferrar. E eu não digo isso brincando não, era realmente pra conseguir se virar e aprender mais a respeito. Incluindo não usar ORM e fazer as queries na unha. Não está sendo nada produtivo no quesito velocidade de desenvolvimento, mas está sendo muito proveitoso no quesito conhecimento 🤝 |
|
Hey pessoal! Mas olha o que apareceu na minha timeline! achei legal compartilhar! me pareceu um negócio legal de fazer uma POC. Abraço |
|
Que massa essa solução @huogerac 😍 topa fazer um post lá no TabNews para turma conhecer? |
Olá pessoal,
Acredito que a fundação deste tema está dividido em 3 partes:
Me parece que no Next.js tem o https://www.prisma.io/ e https://github.com/typeorm/typeorm.
Aparentemente resolvem os 3 pontos acima. Talvez uma desvantagens é ter que instalar typescript (já que o projeto inicialmente não vai usá-lo)
Uma alternativa que acredito interessante e não sei se no NodeJS/Javascript tem, é algo que já utilizei no Python, algo nesta linha aqui: https://nackjicholson.github.io/aiosql/
É bem minimalista, ou seja, temos que resolver a conexão e migrations com outras bibliotecas,
mas é muito mais simples, não tem um ORM (e definições de Models)
Obs: ORM é bem legal, tem diversas vantagens, mas a maior desvantagem pode ser que quando voce precisa fazer uma consulta um pouquinho mais complicada, coisa q no SQL puro é bem simples e direto, no ORM pode ser dificil
Tem isto em varias linguagens, onde temos o SQL puro, mas ainda separado e com uma abstração bem pequena
Bom, o que voces já trabalharam para resolver isto no nodejs/next.js?
Abraço
The text was updated successfully, but these errors were encountered: