GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

Firebase x Parse x MongoDB x MySQL

mysql
java
mongodb
android
Tags: #<Tag:0x00007f7606184060> #<Tag:0x00007f760617fe70> #<Tag:0x00007f760617fd30> #<Tag:0x00007f760617fbf0>

#1

Olá, estou querendo desenvolver um aplicativo parecido como uma lista telefônica para Android com Java, onde armazeno os telefones comerciais, parecido com a ‘TeleListas’. É um projeto ambicioso, pode ser que exista milhões de usuários, mas pode ser que não vingue tbm rsrs Gostaria de uma sugestão de vocês, pois ainda não sei os melhores caminhos no Java. A minha dúvida é a respeito de hospedagem e banco de dados. Queria saber qual o banco de dados mais utilizado pelos desenvolvedores de Java? Li sobre novas tecnologias (não sei se são arriscadas) como a Firebase, Parse, MongoDB, o que vocês acham? ou mysql? Eu não tenho dinheiro para investir em servidores bons pois estou começando agora o projeto e nem sei se vai dar bons frutos. Me corrige se eu estiver errado, mas por exemplo talvez sairia mais barato eu fazer um servidor em um site de hospedagem, mas como estou começando, pode ser que demore um pouco mais de tempo para eu pegar os macetes e talvez seja vulnerável as falhas, encriptação de dados e tal, pois eu vou ter que implementar a segurança no servidor. Li sobre o Firebase e falam que ele é gratuito, mas quando você começa a crescer já começa a pagar e eu não sei quanto minha aplicação irá crescer, vai que ela dá um salto grande e eu teria que pagar caro pela manutenção. Então eu gostaria de uma sugestão de vocês que são experts nesta área. Abraços.


#2

Acho que você está se apressando demais.

Seja mais pé no chão nessa etapa: construa o aplicativo com o conhecimento e as ferramentas que você tem. Quando for a hora de expandir o projeto, aí você pensa em como fazê-lo da melhor forma.

Isso não quer dizer para fazer de qualquer jeito, mas para não tentar fazer um sistema complexo como um Uber ou WhatsApp sendo que você não tem a mesma demanda que eles (nem de longe). O mais importante é ter uma arquitetura razoavelmente modular, que te permita mudar partes do sistema sem um trabalho gigantesco.

Por exemplo, seu aplicativo deve ser totalmente agnóstico quanto às tecnologias de backend (servidores). Com isso, se amanhã você decidir mudar de MySQL para Access ( :joy: ) , não precisa mudar nada no aplicativo. Isso é possível através de protocolos que usem JSON ou XML para comunicação, por exemplo (similar ao que se faz com Ajax nas páginas web hoje em dia).

Outro ponto é, no seu backend, isolar ao máximo os serviços de banco de dados (gravar, ler) da camada de aplicação do servidor. Com isso, essa primeira camada ficará totalmente independente do banco, mandando comandos como “gravarContato” ou “lerContatos”, que o serviço de banco retorna como objetos ou listas de objetos (não como ResultSets). Isso torna a troca de sistema de banco de dados mais transparente.

Abraço.


#3

Desenvolvedores iOS podem armazenar dados na nuvem do usuário (todo usuário iOS possui uma conta no iCloud com 5GB de capacidade) ou na nuvem publica. Google não oferece algo parecido com CloudKit para desenvolvedores Android? Incrível o que uma plataforma integrada como da Apple é capaz de oferecer para seus desenvolvedores em termos de funcionalidade. Android perto do iOS parece coisa de amador.

ps: Parse não existe mais.


#4

muito obrigado pela dica, foi de grande importância!! vou fazer isso mesmo, encapsular as funções e quando quiser mudar de banco será bem mais simples… valeu


#5

Eu uso dois pacotes, database e handler pra separar. Não vejo necessidade de separar em projetos diferentes porque se chegar ao ponto de ter que trocar o banco de dados toda essa parte de acesso a dados vai ter que ser refatorada de qualquer jeito.

Por exemplo, mudar o banco de SQL pra noSQL implica em todo o modelo de consistência mudar de ACID pra eventual. Até mudar pra algo que é o meio termo, como Datomic, implica em mudanças profundas (aplicações mais inteligentes e com noção de tempo).

Portanto acho meio ilusão achar que fazer a arquitetura modular vai permitir que no futuro apenas “troca o banco” e pronto, agora você tem escala do uber. :smiley:


#6

Bom dia, amigo!!! Então, eu estou pesquisando ainda, mas vou trabalhar bastante com os encapsulamentos e mais tarde eu vejo o banco de dados, pois será fácil a migração. iOS eu ainda não desenvolvi nada, mas penso em desenvolver no futuro, minha prioridade agora é o Android pois sei que mais de 90% dos brasileiros usam, e depois desenvolverei para iOS.
O Parse foi descontinuado pelo Facebook e se tornou Open Source que agora chama Parse Server (retirei um trecho de um site)

Como sabem, no início de 2016 o Facebook decidiu não mais prestar serviços de hospedagem de aplicativos e optou por criar uma versão Open Source de seu Backend as a Service. Tal decisão afetou milhares de desenvolvedores ao redor do mundo e o prazo para migração das aplicações está terminando. Se você ainda não definiu uma alternativa para o Parse, que encerrará os serviços em 28 de Janeiro de 2017, você não está sozinho. Felizmente, o Parse lançou uma versão Open Source que é o Parse Server.


#7

Bom, eu prefiro fazer meu próprio back-end do que usar CloudKit para minhas apps, mas é bom pro desenvolvedor que não quer gastar nada de hospedagem e precisa do serviço.

Mas como o TerraSkill disse, não precisa se apressar. Se o google não oferece nada, então da pra ir bem longe com um back-end bem simples, PHP é bem baratinho a hospedagem… só discordo em querer ficar complicando a arquitetura descenessariamente em busca de objetivos duvidosos como modularização máxima.


#8

Em outras palavras, o serviço não existe mais.


#9

Como está sem verba pra investimento, no início procure soluções baratas para ver se o negócio realmente dá sinais que vá “pegar”, daí conforme retorno você investe pra valer. Como @pfk66 sugeriu para o back-end, PHP costuma ser a tecnologia de entrada, por ser simples e ter hospedagem barata, geralmente com banco de dados MySQL ou PostgreSQL. Só cuidado pra não usar coisas como Laravel, onde além de contribuir pra baixar a performance, quem usa fala que dificulta o deploy em hospedagens onde não há controle do servidor, cenário de quem busca serviço barato.


#10

valeu pela dica!! =)


#11

valeu pela dica!! vou fazer um projeto aqui e começar logo =)