felipehuggler.com

Esse post aqui, é mais para eu desabafar a minha relação de amor e ódio com o firebase.

Estou em um projeto grande e decidi usa-lo como banco de dados do sistema. A principio pra desenvolver é muuuuuuuito rapido cara, esse lance de não ter que ficar criando Model é do caraleo!

Mas a medida que os dados foram crescendo, o firebase começou a revelar outra cara.

Vou logo nos pontos negativos, porque se caso, alguém pensar em implementar, já pense 2 vezes antes disso.

1) Não tem um select decente!

O firebase não tem um select confiavel e decente, do tipo select nome * from cliente where idade = 15 and sexo = 'M', que no caso, seria o básico do básico!

Ou você procura por 1 campo, ou você faz uma puta gambiarra pra amenizar os dados, que é fazer 1 request pra uma URL usando shallow=true, que devolve só as KEYS dos registros ou você se fode mesmo!

2) Não tem populate ou groupBy....

Nem preciso explicar neh!

3) Pra trabalhar com geolocation

RISOS ALTOS!!!

Então, basicamente, quem for trabalhar com firebase, eu indico MODELAR o sistema usando ele, porque é bem rapidinho mesmo fazer as paradas, e depois MUDE pra algum outro...MONGO, SQL, MYSQL, mas firebase de cu é rooooooola! 

<div class="title" title="Meu Sandbox">Meu Sandbox</div>

.title {

1. position: relative;
2. border-bottom: solid 1px #DEDEDE;
3. padding: .3em 0;
4. font-weight: 400;
5. color: #3B3B3B;

}

.title:before{

1. content: attr(title);
2. overflow: hidden;
3. border-top: solid 4px rgba(0,0,0,.2);
4. position: absolute;
5. top: 100%;
6. height: 0;
7. display: inline-block;

}

Essa é uma solucao simples ;-)

Espero que ajude

Eu to virando especialista em UI-GRID e agora esse trechinho de código serve pra deixar a altura da row automatica.

this.gridOptionsTitulos.gridApi.core.on.rowsRendered(null, () => {

//scope.gridApi.treeBase.expandAllRows();

this.gridOptionsTitulos.gridApi.expandable.expandAllRows();

});

 

this.gridOptionsTitulos.gridApi.expandable.on.rowExpandedBeforeStateChanged(null, (row) => {

var len = row.entity.parcelamento ? row.entity.parcelamento.parcelas.length : 0;

this.gridOptionsTitulos.expandableRowHeight = (len * 30);

});

Esse macete aqui, poucos conhecem! Então eu vou passar o pulo do gato pra galera!!!

Quando se está trabalhando com firebase, pode ocorrer da sua tabela ser muito grande, tipo ter uns 90mil registros.

Isso vai onerar sua aplicacao, então, no caso é melhor fazer uma paginação.

Mas como faço pra pegar o total de itens do meu banco?

firebase.auth().currentUser.getToken().then(data => {

let auth = data;

fetch('https://SEUPROJETO.firebaseio.com/SUAREFERENCIA/.json?shallow=true&auth=' + auth).then(resp => { return resp.json(); }).then(data => { this.gridOptions.totalItems = Object.keys(data).length; console.log(Object.keys(data).length) });

});

E oque é esse auth?

auth é a chave de autenticacao, que indica que você pode realmente acessar os dados. Pra vc pegar esse auth, basta usar o seguinte codigo.

firebase.auth().currentUser.getToken().then(data => {

let auth = data;

fetch('https://rjr-backend.firebaseio.com/clientes/.json?shallow=true&auth=' + auth).then(resp => { return resp.json(); }).then(data => { this.gridOptions.totalItems = Object.keys(data).length; console.log(Object.keys(data).length) });

});

É isso, ai o resto é só implementar!!!

select top ${take} * from (

SELECT

      isnull(Ltrim(RTRIM([CPFCGC_PES])),'') as documento

      ,isnull(RTRIM([IE_PES]), '') as inscricaoEstadual

      ,isnull(Ltrim(RTRIM([NOME_PES])), '') as nome

      ,ROW_NUMBER() OVER (order by CPFCGC_PES) AS rowid

      ,isnull(RTRIM([EMAIL]),'') as email, isnull((select enderecos.* from (SELECT RTRIM(PE.BAIRRO_ENDE) as bairro, 

                     RTRIM(PE.RUA_ENDE) as logradouro,

RTRIM(PE.CEP_ENDE) as cep,

RTRIM(CIDADES.CIDADES) as cidade,

RTRIM(CIDADES.UF) as estado,

RTRIM(TIPOS_ENDERECOS.NOME_TIPE) tipoEndereco 

              FROM   [cobsystems].[dbo].[PESSOAS_ENDERECOS] PE inner join [cobsystems].[dbo].[CIDADES] on PE.CIDADE_COD = CIDADES.CODIGO  inner join [cobsystems].[dbo].[TIPOS_ENDERECOS] on TIPOS_ENDERECOS.COD_TIPE = PE.COD_TIPE

              WHERE  PE.COD_PES = p.COD_PES) as enderecos FOR json path, INCLUDE_NULL_VALUES), '') AS enderecos, isnull((select telefones.* from ( 

              SELECT  RTRIM(PT.NR_TEL) as numero, RTRIM(TIPOS_TELEFONES.NOM_TIP) as tipo

              FROM   [cobsystems].[dbo].[PESSOAS_TELEFONES] PT inner join [cobsystems].[dbo].[TIPOS_TELEFONES] on pt.TIPO_TEL = TIPOS_TELEFONES.COD_TIP

              WHERE  PT.COD_PES = p.COD_PES) as telefones FOR json path, INCLUDE_NULL_VALUES), '') AS telefones FROM [cobsystems].[dbo].[PESSOAS] as p where CPFCGC_PES <> '') as c where rowid > ${skip} order by rowid

funciona da seguinte maneira, o take é a quantidade de registros

o skip, é a posição...ou seja, skip = 0, inicia na posicao 0, skip 50, inicia na posicao 50 e assim por diante.

Firebase ou você AMA ou você ODEIA!

O firebase não tem uma resposta muito boa, tipo um formato de que um tratamento decente.

No caso de paginacao de dados, é ainda pior.

Pra voê saber quantos registros você tem na sua base, tem um macete.

https://SEUPROJETO.firebaseio.com/SUAREFERENCIA/.json?shallow=true

Esse json?shallow=true, retorna somente as KEYS que estao no banco.

Na minha opiniao é uma GAMBIARRA, mas ajuda, quando se trata de ter um banco com 1milhao de registros.

Quem trabalha com firebase, deve "OBRIGATORIAMENTE" seguir oque os caras falam:

Melhorar a eficiência dos listeners

Coloque os listeners na última parte possível do caminho para limitar a quantidade de dados que eles sincronizam. Seus listeners devem estar perto dos dados que você quer detectar. Não coloque listeners na raiz do banco de dados, pois isso resulta em downloads de todo o seu banco de dados.

Adicione consultas para limitar os dados retornados pelas suas operações de detecção e use listeners que fazem o download somente de atualizações de dados. Por exemplo, on() em vez de once(). Use .once() somente em ações que realmente não exigem atualizações de dados. Além disso, classifique suas consultas com orderByKey() sempre que possível para alcançar o melhor desempenho. A classificação com orderByChild() pode ser de seis a oito vezes mais lenta. A classificação com orderByValue(), por sua vez, pode ser muito lenta para grandes conjuntos de dados porque requer uma leitura de todo o local, desde a camada de persistência.

Lembre-se também de adicionar listeners de maneira dinâmica e de removê-los quando não forem mais necessários.

#ficadica

Esse é o maior pulo do gato que eu descobri ultimamente em relação a conversão de Select para Json.

Essa primeira query, cria um objeto P e um objeto F, nao deixando tudo na mesma linha

SELECT 

      [SENHA_USU] as password

      ,[NIVEL_USU] as nivel

      ,[ATIVO_USU] as ativo

      ,[NOME_PES] as displayName

  ,EMAIL as email

      ,[DT_ENTRADA_FUNC] as dtEntrada

      ,[DT_SAIDA_FUNC] as dtSaida

      ,[SALARIO_FUNC] as salario

      ,[CARGO_FUNC] as cargo

      ,[COMMISSAO_FUNC] as comissao

  FROM [cobsystems].[dbo].[USUARIOS] inner join FUNCIONARIOS_OLD on USUARIOS.COD_FUNC = FUNCIONARIOS_OLD.COD_FUNC inner join PESSOAS on PESSOAS.COD_PES = FUNCIONARIOS_OLD.COD_PES order by COD_USU  FOR json auto

 

query arrumada

Essa query deixa tudo na mesma linha!

SELECT m.* 

         FROM (

 

SELECT 

      U.SENHA_USU as password,

      U.NIVEL_USU as nivel,

  IIF(U.ATIVO_USU = 1, 'true', 'false') as ativo,

 

      P.NOME_PES as displayName,

  isnull(P.EMAIL, '') as email,

      F.DT_ENTRADA_FUNC as dtEntrada,

      F.DT_SAIDA_FUNC as dtSaida,

      convert(int, isnull(F.SALARIO_FUNC, 0)) as salario,

      F.CARGO_FUNC as cargo,

      convert(int, isnull(F.COMMISSAO_FUNC,0)) as comissao

  FROM [cobsystems].[dbo].[USUARIOS] as U inner join [cobsystems].[dbo].[FUNCIONARIOS_OLD] F on U.COD_FUNC = F.COD_FUNC inner join [cobsystems].[dbo].[PESSOAS] P on P.COD_PES = F.COD_PES

 

) AS m

         FOR JSON AUTO

Essa foi a forma menos feia que eu encontrei pra não ter que ficar setando toda hora o createdAt, createdBy, updatedAt, updatedBy... É um baaaaaaaita jump the cat, hehehe!! Espero que sirva pra alguem tambem!

var set = firebase.database.Reference.prototype.set;
firebase.database.Reference.prototype.set = function(value, onComplete){
  value['createdAt'] = firebase.database.ServerValue.TIMESTAMP;
  value['createdBy'] = firebase.auth().currentUser.displayName;
  return set.apply(this, arguments);
}
var update = firebase.database.Reference.prototype.update;
firebase.database.Reference.prototype.update = function(value, onComplete){
  value['updatedAt'] = firebase.database.ServerValue.TIMESTAMP;
  value['updatedBy'] = firebase.auth().currentUser.displayName;
  return update.apply(this, arguments);
}

 

Oque é um decorator?

Basicamente ele é utilizado para sobreescrever métodos antes que de fato o método original seja chamado!

Vamos imaginar o seguinte cenario:

Temos alguns endpoints que realizam Create e Update no banco. E para cada um desses métodos, eu quero salvar o dia da criacao do registro e quem fez o cadastro, e o dia da alteracao do registro e que fez o cadastro!

Usando MongoDB é muito facil fazer isso, basta a gente indicar no model um timestamp: true

Exemplo:

var clienteSchema = new mongoose.Schema({

nome: {type: String}

},{

    timestamps: true

});

Qualquer inclusão ou alteração que ocorrer, o mongo já incluirá os valores da data da criação e ou alteração!

Mas no nosso caso, não estamos usando MONGO e tambem queremos incluir a pessoa que fez a ação!

Voltando ao nosso cenário, criamos o nosso Service que receberá os dados e enviará para API.

Eu vou fazer bem básico, porque a intenção aqui é focar no decorator!!!

Service.create = (data)=> {

    data.createdAt = firebase.database.ServerValue.TIMESTAMP; // ou new Date().getTime()

    data.createdBy = firebase.auth().currentUser.displayName; // ou currentUser.uid;

  return this._$firebaseArray(firebase.database.ref('suaRefencia')).$add(data)  

}

 

Service.update = (id, data)=> {

    data.createdAt = firebase.database.ServerValue.TIMESTAMP; // ou new Date().getTime()

    data.createdBy = firebase.auth().currentUser.displayName; // ou currentUser.uid;

  return this._$firebaseObject(firebase.database.ref('suaRefencia').child(id)).$save(data)  

}

Olha que chato, se toda vez que a gente criar um servico, ter que ficar colocando esse código, createdAt, createdBy, updatedAt, updatedBy

O ideial é quando a gente chamar o $add ou $save, antes de executar o método, ele inclua essas propriedades no nsso objeto data.

É ai que entra o decorator!!!

let app = angular.module('app', []);

app.config(function($provide) {

    $provide.decorator('$firebaseArray', function($delegate, $window) {

        var _add = $delegate.prototype.$add;

        $delegate.prototype.$add = function (newData) {

            newData['createdAt'] = $window.firebase.database.ServerValue.TIMESTAMP;

            newData['createdBy'] = $window.firebase.auth().currentUser.displayName; //uid

 

            return _add.call(this, newData);

        };

        return $delegate;

    });

})

app.config(function($provide) {

    $provide.decorator('$firebaseObject', function($delegate, $window) {

        var _save = $delegate.prototype.$save;

        $delegate.prototype.$save = function () {

            this['updatedAt'] = $window.firebase.database.ServerValue.TIMESTAMP;

            this['updatedBy'] = $window.firebase.auth().currentUser.displayName;

            return _save.call(this);

        };

        return $delegate;

    });

})

Agora no nosso controller, a gente faz a chamada do Service

let data = {

  nome: 'Joao da Silva';

  idade: 33

}

Service.create(data);

Nosso service chamado o firebaseArray, mas antes entra no decorator, que insere a data da criacao e o nome do usuário logado no firebase!

E assim, a gente finaliza nossa tarefa.

Espero que ajude!