Como tudo começouTormento idealTecnologias e como elas não são únicasComo armazenar e onde?Não apenas para armazenar, mas também para pesquisarEste é um SEO enigmáticoCDN nosso tudoResumirComo tudo começou
Quero compartilhar nossa história de meio ano de criação de um serviço on-line para pesquisar e reservar viagens de direitos autorais em todo o mundo. Ao criar este artigo, o objetivo era falar sobre a experiência de criar nossas próprias soluções do zero e os problemas e desafios que encontramos ao longo do caminho, portanto, não julgue rigorosamente.
Para começar, que tipo de serviço é e por que foi necessário criá-lo. Durante muito tempo, nossa equipe trabalhou em vários grandes projetos para clientes empresariais. São portais para bancos, empresas, grandes participações e sistemas de gerenciamento de documentos. Naturalmente, trabalhar com esse segmento implica a satisfação de um círculo restrito de funcionários interessados e nem sempre termina com um uso longo e bem-sucedido.
Existem várias razões para isso: falta de entendimento do projeto na fase inicial, desejo de economizar dinheiro e obter o equipamento mais completo, alterando os requisitos na fase final sem nenhuma revisão dos termos e orçamentos. Como você pode ver, é muito difícil alcançar a satisfação do projeto de ambos os lados, após essas condições.
Então, depois de toda essa experiência, decidimos nos testar no mercado, onde o feedback do cliente é extremamente rápido, você entende o interesse no produto o mais rápido possível e vê o uso do seu serviço todos os dias.
Como se viu, nossos dias calmos acabaram!
Tormento ideal
A primeira coisa que precisava ser feita foi ter a idéia do que queremos fornecer tão útil que não esteja no mercado e que seja percebido e esperado. Tivemos várias dessas amostras e, durante os primeiros dois meses, realizamos experimentos para encontrar o futuro. Como você pode entender, também havia um problema com as tecnologias, pois é necessário fazer maquetes em funcionamento no menor tempo possível, verificar sua operacionalidade e melhorar constantemente ou refazê-las novamente.
No início, a bagagem de tecnologias que tínhamos não era muito jQuery e C # (que usamos em nossos projetos anteriores). Essas ferramentas não nos permitiram enfrentar de forma rápida e flexível os desafios. Felizmente, já consideramos novas abordagens para o desenvolvimento de clientes e servidores. Nossa escolha recaiu sobre o Angular 2 e o Node.js. Essa solução nos permitiu formar rapidamente componentes e módulos que pudemos modificar no menor tempo possível (no dia em que pudemos refazê-los duas ou três vezes).
Chegamos à conclusão de que cada componente deve ser o menor possível e integrável a outros componentes e módulos. Assim, no processo de experimentos, acumulamos modelos suficientes a partir dos quais foi possível montar vários layouts de trabalho.
Mas se descobrimos as ferramentas com rapidez suficiente e, na batalha, aumentamos nossas habilidades cada vez mais (notarei imediatamente o Google para ajudá-lo, mas não se esqueça dos tutoriais em vídeo), surgiu outra pergunta sobre onde armazenar os dados. Mas vou falar sobre isso um pouco mais tarde, e agora voltando à ideia em si.
Como principal vetor de nosso serviço, pretendemos organizar viagens, você dirá imediatamente que, em nosso tempo, existem vários sites e serviços para viagens, além do mesmo grupo de agências de viagens e eu concordo com você. Mas, a questão é como mudar a atitude do turista comum para descansar e dar a ele a oportunidade de obter o conjunto máximo de impressões e sentir uma abordagem individual de sua amada.
Entendemos que esses planos ambiciosos não podem ser resolvidos com um serviço ou com uma única solução, mas sempre precisamos começar em algum lugar. E agora, tendo nos estabelecido com o objetivo principal, começamos a procurar o primeiro tijolo, que servirá de base para a nossa solução futura. Após uma longa pesquisa, tivemos a ideia de um serviço, sobre o qual agora quero falar.
O que é isso?
Em suma, esta é a UBER para viajantes. Imagine que você é um viajante experiente que viajou para muitos lugares interessantes ao redor do mundo e realmente quer compartilhar bem sua experiência e ganhar algum dinheiro. E, por outro lado, um turista que está cansado de um feriado turco deitado na praia, comendo e bebendo. E essas pessoas precisam estar de alguma forma unidas. Então decidimos ajudar essas pessoas a se encontrarem.
O serviço é um mercado no qual turistas experientes podem se registrar para projetar seus passeios e fornecê-los às massas de futuros viajantes.
Tecnologias e como elas não são únicas
Como armazenar e onde?
Como já escrevi, depois de escolher as ferramentas para criar o serviço, surgiu a questão de escolher um data warehouse. É claro que, ao longo dos anos, nos acostumamos aos bancos de dados relacionais e ao SQL Server em particular. Porém, era necessária uma plataforma para uma configuração mínima no início e um mínimo de esforço com suporte adicional, além da capacidade de escalar no desenvolvimento de nosso serviço e no crescimento de visitantes.
Assim, no processo de busca, foi encontrada uma solução que cobria todos os nossos requisitos: o Firebase Realtime Database. Esse serviço nos ajudou a resolver os problemas de armazenamento de dados, hospedagem, serviço de autenticação e armazenamento para armazenamento de dados estáticos. Além disso, esse serviço está sob a asa do Google, que por sua vez nos deu bons bônus, pois fornecia bibliotecas separadas para o trabalho com o Angular 2 e era conveniente e rápido. Mas a coisa mais legal que temos é o banco de dados do RealTime pronto para uso. Nossas primeiras sensações foram simplesmente fantásticas.
Agora, não era necessário fazer solicitações constantemente ao serviço, monitorar a relevância dos dados no cliente, aguardar até que os dados cheguem ao cliente (bem, notei que a Angular também nos ajudou). Configuramos tudo isso em algum lugar do dia e começamos a criar diretamente nosso serviço, sem nos distrairmos com problemas de infraestrutura. Devo dizer imediatamente que, durante o processo de desenvolvimento, não gastamos um centavo neste serviço, pois a versão básica é gratuita e é suficiente para desenvolvimento, teste e experimentação.
Não apenas para armazenar, mas também para pesquisar
E assim, assim que a primeira versão beta ficou pronta, surgiu a questão de filtrar os dados e percebemos as primeiras desvantagens no Firebase. Como se viu, o processo de amostragem de dados para um grande número de condições simplesmente não é suportado. É possível selecionar dados com apenas uma condição ou coletar vários valores em um campo e depois filtrá-los. Essa abordagem não nos convinha e novamente começamos a procurar uma solução.
Obviamente, não recusamos o Firebase, já que este menos não se sobrepunha à massa de vantagens oferecidas por este serviço. Felizmente, tivemos a experiência de usar o Google Big Query, que adquirimos no processo de nossa pesquisa, e decidimos aplicá-lo. A primeira vantagem é que é o Google, a segunda - consultas SQL nativas e favoritas e o baixo custo de possuir 1 TB de dados por mês gratuitamente.
Novamente, tudo ficou claro e compreensível, eles escreveram um serviço de envio de dados e o parafusaram com sucesso na Cloud Function. Esqueci de dizer que o Firebase também cuidava do back-end, você pode escrever seus próprios gatilhos no Nodejs e pendurá-los em qualquer evento no banco de dados, bem como em uma solicitação http.
Como você pode ver, o processo de encontrar soluções e abordagens tornou-se uma tarefa diária para nós, pois quase todos os dias nos deparamos com novos desafios que precisavam ser resolvidos rapidamente.
Não tivemos tempo para relaxar e continuar a criar nosso serviço com calma quando o teste do grupo de foco começou, e percebemos que os usuários estão acostumados a trocar de filtro com muita rapidez e querem ver imediatamente o resultado de seu trabalho. Tais requisitos nos forçaram a abandonar o Big Query e procurar algo novo. Como o Big Query nos deu uma velocidade de resposta de no máximo 2 segundos, e isso com uma quantidade mínima de dados. Aqui, é claro, não há nada para culpá-los, pois esse serviço é destinado ao processamento de grandes volumes de informações, e não à reação rápida a um monte de solicitações consecutivas.
Como resultado, optamos pela pesquisa elástica. Este produto nos permitiu criar um mecanismo de pesquisa rápido, nossa filtragem começou a atender aos requisitos de nossos usuários. Não vou contar muito aqui, pois este produto começou a ganhar popularidade e há informações suficientes sobre ele. A única coisa que quero observar é que, para este produto, você precisa de uma máquina virtual que precisa estar hospedada em algum lugar. Esse recurso fornece o Google e a Microsoft, portanto, a escolha é sua. A configuração é tão fácil quanto o recurso bitnami. Escolhemos o Azure por conta própria, essa escolha não foi tanto por causa dos recursos tecnológicos, mas mais por fatores de terceiros).
Este é um SEO enigmático
E agora o serviço está em execução, as plataformas estão sendo desenvolvidas e tudo parece estar bem, estamos nos esforçando para um futuro brilhante. Porém, isso levanta a questão de promover nosso serviço e a principal questão de SEO. Eu nunca pensei que essa questão pudesse não ser tão elaborada pelos criadores do Angular. Como se viu, o Aplicativo de Página Única é muito fraco em fornecer esse recurso e, para ser honesto, não é de todo. Sim, você pode costurar dados estáticos em metatags e, quando você ignora o Crowl ou quando o compartilhamento fornece as mesmas informações, bem, elas de alguma forma estão erradas e ineficazes. Depois de navegar na Internet, encontramos um serviço maravilhoso, que faz parte do Angular 4, Angular Universal. Depois de ler a descrição, percebemos que é disso que precisamos e que, em vão, censuramos os desenvolvedores do framework.
Um épico começou com o estrago dessa felicidade em nosso projeto. Observo que naquele momento cerca de 10 módulos grandes já haviam sido escritos e cerca de 12 pacotes npm de terceiros foram usados. A primeira configuração de um projeto limpo foi perfeita, graças aos manuais na Internet, e tudo parecia começar. Além disso, distorcemos a parte do servidor na mesma função de nuvem do Firebase. Bem, agora temos que tentar o código de batalha, e depois houve problemas. Primeiro, como se viu, todos os pacotes npm de terceiros devem suportar o Angular 4; no código no servidor, você não pode usar a janela de variáveis, o documento etc., bem, depurar toda essa felicidade simplesmente não é realista.
Não vou descrever todos os nossos tormentos com este serviço, pois foi muito e doloroso. Vou dizer uma coisa: não superamos, não o conheço ou não o entendi completamente, ou simplesmente ainda está úmido e não está pronto para uso produtivo. Em geral, cabe a você decidir quem pode ter sucesso, mas decidimos parar por aí. Como resultado, foi criado um serviço que atende a todas as solicitações HTTP e retorna uma solicitação index.html, mas antes disso lança as metatags necessárias. Como resultado, ficou bem e por três meses o voo foi normal. A propósito, também hospedamos tudo no Azure para os mesmos fatores de terceiros.
CDN nosso tudo
E aqui novamente algum tempo de estabilidade e trabalho relativamente silencioso. E ninguém pensou que a surpresa nos espera do Facebook. Um belo dia, descobriu que compartilhar no FB não funciona. Inicialmente, pensamos que isso se devia ao aperto das políticas de segurança no FB, depois com o bloqueio de IP, mas não encontramos o motivo. Contatados em apoio ao FB e Firebase, mas cada um chutou o outro.
A única coisa que determinamos é que o problema está nos URLs das imagens que armazenamos na loja Firebase, e o URL, digo imediatamente, é muito específico lá. Decidimos transferir todo o conteúdo estático para o Azure também, e digo que essa decisão foi correta, pois a velocidade de upload de fotos aumentou e você pode gerenciar tudo isso de maneira mais flexível e transparente.
Resumir
No momento, já estamos no terceiro mês produtivo, estamos constantemente aprimorando e expandindo a funcionalidade. Para controle de versão, é claro que usamos o Git, gradualmente automatizamos as compilações e implementamos. Recebemos cerca de 450 novas visitas únicas por dia, há saltos de até 1000 usuários. E tudo funciona.
O que eu gostaria de resumir de tudo o que foi dito:
- Não é necessário tentar resolver todos os problemas que aparecem em seus projetos devido a um serviço ou uma tecnologia.
- Tente desenvolver módulos universais para obter mais flexibilidade no futuro.
- A escolha de um provedor de serviços em nuvem é uma questão puramente pessoal, pois, em geral, todos eles fornecem o mesmo conjunto de serviços. A questão permanece no preço e nas suas preferências.
- Projete sua solução para poder migrar entre diferentes provedores de serviços e tecnologias ou, pelo menos, pensar em uma estratégia para uma possível mudança.
- Bem, não tenha medo de experimentar.