Como estruturar e manter seguro meus dados no Firebase?

Transcript

1. Como estruturar e manter seguro meus dados no Firebase?
2. Olá! Eu sou Ana Coimbra Desenvolvedora @ Kobe #Android #Web #IxD Redes sociais: @anacoimbrag 2
4. “ "Já usei firebase uma vez, mas tive que mudar para o [insira qualquer banco de dados não relacional aqui] porque ..." 4
5. Limites de cota atingidos muito rápido 5
6. Falhas de Segurança 6
7. Escalonamento dos dados 7
8. Não era pra me ajudar? O Firebase possui ótimas ferramentas para desenvolvimento de produtos digitais, mas é necessário planejamento e estruturação. 8
9. Banco de dados SQL 9 Usuários id nome email 1 "Ada Lovelace" "ada@email.com" 2 "Alan Turing" "alan@email.com" Transações id valor data tipo usr_fr_key 1 50.00 20-11-2018 "despesa" 2 2 10.00 23-11-2018 "receita" 1
10. Banco de dados SQL 10 Usuários id nome email 1 "Ada Lovelace" "ada@email.com" 2 "Alan Turing" "alan@email.com" Transações id valor data tipo usr_fr_key 1 50.00 20-11-2018 "despesa" 2 2 10.00 23-11-2018 "receita" 1 3 5 24-11-2018 1 1
11. Banco de dados SQL 11 Usuários id nome email 1 "Ada Lovelace" "ada@email.com" 2 "Alan Turing" "alan@email.com" Transações id valor data tipo usr_fr_key 1 50.00 20-11-2018 "despesa" 2 2 10.00 23-11-2018 "receita" 1 Select * FROM Usuários, Transações WHERE User.id = 1 AND Transações.usr_fr_key = User.id
12. Banco de dados NoSQL id: 1 valor: 50.00 data: 20-11-2018 tipo: "despesa" id_usuário: 1 id: 2 valor: 10.00 data: 23-11-2018 tipo: "receita" id_usuário: 1 12
13. Banco de dados NoSQL id: 1 valor: 50.00 data: 20-11-2018 tipo: "despesa" id_usuário: 1 observações: "Tive que pagar o táxi." id: 2 valor: 10.00 data: 23-11-2018 tipo: "receita" id_usuário: 1 13
14. Banco de dados NoSQL id: 1 valor: 50.00 data: 20-11-2018 tipo: "despesa" id_usuário: 1 id: 2 valor: 10.00 data: 23-11-2018 tipo: "receita" id_usuário: 2 14 transações_do_dia_20 = collection('Transacao').where('data', '==', 20-11-2018).get() Para cada transacoes_do_dia_20: collection.('Usuarios').doc(transacao.id_usuário).get()
15. Banco de dados NoSQL id: 1 valor: 50.00 data: 20-11-2018 tipo: "despesa" usuário: { nome: "Ada Lovelace" } id: 2 valor: 10.00 data: 23-11-2018 tipo: "receita" usuário: { nome: "Alan Turing" } 15 Ainda existe na raiz, os dados completos de Usuários
16. Banco de Dados NoSQL ◂ Manter consistência ◂ Número de leituras é muito maior que o número de atualizações nos dados ◂ É fácil distribuir os dados entre servidores diferentes. ◂ Duplicar apenas dados estritamente necessários para a leitura. 16
17. Firestore Banco de dados NoSQL, escalável, serverless
18. Firestore (NoSQL) ◂ Altamente distribuído ◂ Queries de filtro e ordenação (limitações) ◂ Sincronização em tempo real ◂ Não possui backup nativo ◂ Beta 18
19. Modelo de dados ◂ Os dados são documentos organizados dentro de coleções ◂ Otimizado para guardar uma grande quantidade de pequenos documentos 19
20. Documentos ◂ Um registro simples que possuem chaves que apontam para um valor ◂ Todo documento possui um identificador único ◂ Pode ter uma sub coleção ◂ Pode ter no máximo 1MB ▪ 1 ◂ nome: "Ada Lovelace" ◂ email: "ada@email.com" 20
21. Coleções ◂ Container para os documentos ◂ Contém apenas documentos ◂ Os identificadores dos documentos devem ser únicos dentro da coleção ☰ Users ▪ 1 ◂ nome: "Ada Lovelace" ◂ email: "ada@email.com" ▪ 2 ◂ nome: "Alan Turing" ◂ email: "alan@email.com" 21
22. Referências ◂ Ponteiros para uma localização no banco de dados ◂ Todos os documentos podem ser acessados com seus identificadores através de referências. ◂ É possível referenciar também coleções 22 collections/Usuários/1/Transações/1
23. Estruturação dos dados Existem 3 formas padrões de estruturar os dados: Dados aninhados em documentos, subcoleções e coleções na raiz
24. Dados em documentos Usuários: [ 1: { nome: "Ada Lovalace", email: "ada@email.com", Transações: [ 1: { valor: 50.00, data: 20-11-2018, tipo: "despesa" } ] } ] 24
25. Dados em documentos Usuários: [ 1: { nome: "Ada Lovalace", email: "ada@email.com", Transações: [ 1: { valor: 50.00, data: 20-11-2018, tipo: "despesa" } ] } ] 25 ◂ Máx 1MB ◂ Máx 1 escrita/ doc / segundo ◂ Não suporta queries ◂ Pouco escalável ◂ Retorna muitos dados e as vezes não são necessários
26. Sub coleções ☰ Users ▪ 1 ◂ nome: "Ada Lovelace" ◂ email: "ada@email.com" ☰ Transações ▪ 1 ◂ valor: 50.00 ◂ data: 20-11-2018 ◂ tipo: "despesa" 26
27. Sub coleções ☰ Users ▪ 1 ◂ nome: "Ada Lovelace" ◂ email: "ada@email.com" ☰ Transações ▪ 1 ◂ valor: 50.00 ◂ data: 20-11-2018 ◂ tipo: "despesa" 27 ◂ Consegue otimizar queries dentro da sub coleção ◂ Mais escalável ◂ Não é tão simples deletar sub coleções ◂ Não é possível fazer queries entre coleções diferentes
28. Coleções na raiz ☰ Users ▪ 1 ◂ nome: "Ada Lovelace" ◂ email: "ada@email.com" ☰ Transações ▪ 1 ◂ valor: 50.00 ◂ data: 20-11-2018 ◂ tipo: "despesa" ◂ usuário: 1 28
29. Coleções na raiz ☰ Users ▪ 1 ◂ nome: "Ada Lovelace" ◂ email: "ada@email.com" ☰ Transações ▪ 1 ◂ valor: 50.00 ◂ data: 20-11-2018 ◂ tipo: "despesa" ◂ usuário: 1 29 ◂ Altamente escalável ◂ Possibilidade de fazer buscas mais elaboradas dentro das coleções ◂ Complexidade para trabalhar com dados hierárquicos
30. Já está na hora de surtar? Está na hora de respirar e avaliar como será o projeto 30
31. Sugestão de estrutura ☰ Users ▪ 1 ◂ nome: "Ada Lovelace" ◂ email: "ada@email.com" ☰ Transações ▪ 1 ◂ valor: 50.00 ◂ data: 20-11-2018 ◂ tipo: "despesa" ☰ Transações ▪ 1 ◂ valor: 50.00 ◂ data: 20-11-2018 ◂ tipo: "despesa" ◂ usuário: { nome: "Ada Lovelace" } 31
32. 32 Opa, e essa duplicação de dados aí? Está tudo bem, temos tudo planejado
38. Cloud Functions To the rescue!
39. Firebase Cloud Functions ◂ Possibilidade de executar códigos de back end de forma fácil e rápida ◂ Triggers de eventos de outras funcionalidades do Firebase (autenticação, banco de dados, armazenamento, etc) ◂ Chamadas Http 39
40. 40 exports const copyTransaction = functions.firestore .document('transactions/{id}').onWrite((change, context) => { // ... Copiar/Atualizar transação na sub coleção do usuário. }); Firebase Cloud Functions Mantém consistência exports const updateUserOnTransaction = functions.firestore .document('user/{id}').onUpdate((change, context) => { // ... Atualizar user.name nas transações desse usuário. (Usar batches) });
41. Mas e a segurança? Não queremos que outra pessoa tenha acesso as minhas transações, certo? 41
42. Segurança de dados Controle de Acesso e Identidade (IAM) Controla quem pode acessar quais informações de qual recurso Regras de Segurança Documento que define as regras de acesso do lado do cliente, independente de servidor 42
44. Regras de segurança ◂ Nenhum usuário deve pode ler ou atualizar alguma transação que não tenha sido criada por ele mesmo, dentro da sua própria coleção. ◂ Ao criar uma transação, nenhuma data deve ser maior que a data de criação. ◂ Apenas administradores podem ler as transações na raiz. ◂ Nenhum usuário pode criar ou atualizar transações na raiz. 44
45. 45 service cloud.firestore { match /databases/{database}/documents { match /users/{userId} { allow read: if isAuthenticated(); allow write: if isUser(userId); match /transactions/{transactionId} { allow create, update: if isAuthenticated() && incomingData().date is timestamp && incomingData().date <= request.time.date(); allow read, delete: if isUser(userId); } } match /transactions/{transactionId} { allow read: if isAdmin(); } } }
46. 46 function isAuthenticated() { return request.auth != null; } function isUser(userId) { return request.auth.uid == userId; } function existingData() { return resource.data; } function incomingData() { return request.resource.data; } function getUser() { return get(/databases/$(database)/documents/users/$(request.auth.uid)); } function isAdmin() { return getUser().data.admin == true; }
47. Limitações ◂ Máx 10 chamadas single-doc ◂ Máx 20 chamadas multi-doc (batch) ◂ Profundidade máxima de chamadas de função: 20 ◂ Não permite chamadas recursivas ◂ Número máximo de expressões: 10.000 ◂ Tamanho máximo: 46KB 47
48. Isso tudo parece bem caro ... O Firebase oferece utilizações gratuita e planos de pagamento sob demanda. 48
49. Definir limites É possível definir um limite diário de gastos. ◂ Após atingir o limite, os acessos param de funcionar Atribuir um orçamento mensal para os gastos com Google Cloud ◂ É possível configurar alertas para saber quando seu gasto está no limite do orçamento 49
50. Formas de cobrança 50 1. Número de leituras, escritas e exclusões 2. Tamanho dos dados armazenados 3. Largura de banda utilizada Será cobrado pelo menos 1 leitura, mesmo que a chamada não retorne nenhum documento
51. Formas de Cobrança - Escritas e Leituras Leituras em tempo real Cobrado unitariamente para cada documento que é alterado Queries Cobrado uma leitura para cada documento recuperado Soluções: Cursores, paginação, limites e offsets Functions e Regras de segurança Cada chamada no functions é contada assim como get() e exists() no documento de regras Solução: muitas chamadas são cacheadas 51
52. Formas de Cobrança - Tamanho dos dados ◂ Inclui a quantidade dos dados, junto com seus meta dados e índices compostos e automáticos 52
53. Forma de Cobrança - Largura de Banda ◂ Depende de: ◂ Tamanho da resposta ◂ Localização do banco de dados ◂ Destino da resposta 53
54. “ "Ok, agora posso manter meus dados no Firestore tranquilamente." 54
55. 55 Links ◂ Documentação oficial: https://firebase.google.com/docs/firestore/ ◂ Vídeos sobre Firestore: https://www.youtube.com/playlist?list=PLl-K7zZEsYLluG5MC VEzXAQ7ACZBCuZgZ ◂ Plug-in para Visual Studio Code: https://marketplace.visualstudio.com/items?itemName=tob a.vsfire
56. 56 Thanks! Dúvidas? Pode enviar também pelas redes ou por email: ◂ @anacoimbrag ◂ ana.coimbra.gomes@gmail.com