#365Posts – O futuro dos blogs e sites de conteúdo
Uma das coisas mais tolas a se fazer, em minha opinião, é tentar adivinhar o futuro — seja lá qual for o contexto. Em se tratando de Internet, então, a tolice pode ser ainda maior, haja vista a velocidade com que novas tecnologias são desenvolvidas, implementadas e aposentadas, bem como a capacidade de surpreender que as pessoas têm.
Entretanto, vou me permitir aqui fazer uma interpretação de leituras que tenho feito no decorrer dos anos, principalmente embasado em meu trabalho à frente da PortoFácil, que conta com mais de 99% dos sites de seus clientes com blogs WordPress.
Índice de Tópicos
A evolução dos blogs e gerenciadores de conteúdo
Gerenciadores de conteúdo (CMSs ou Content Management Systems, em Inglês) sempre foram peças importantes para a web como conhecemos, antes mesmo de os CMSs terem este nome. Com a popularização dos blogs ferramentas foram surgindo, entre as quais destaco o MovableType, primeiro CMS voltado para blogs que usei, e o WordPress, que hoje faz fluir pelo menos 99% dos sites que tenho, e a mesma proporção se aplica aos de meus clientes.
Como todo CMS o WordPress (e o Joomla, o Drupal, ou qualquer outro) se baseia em um banco de dados que armazena entre outras coisas (e bota “outras” nisso) os posts e os comentários dos visitantes, e quando alguém deseja visualizar um post os dados são “puxados” do banco de dados, formatados e exibidos. Para cada visitante em cada página, o processo todo é repetido.
Se fosse só isso já seria bastante, mas o nó é mais embaixo por conta de que o WordPress (e também os outros CMSs, mas falo de WP porque é a ferramenta que eu uso, e a qual conheço bem) conta com muitas funcionalidades adicionadas pelos usuários. São plugins para os mais diversos fins, inclusive para desabilitar funções do WP, além de scripts adicionados ao arquivo functions.php do tema em uso, que regra geral deveriam dar suporte a funções requisitadas pelo próprio leiaute, mas que na prática acabam por servir para os mais diversos fins também.
Problemas potenciais do cenário atual
Como os parágrafos acima deveriam sugerir, o cenário atual dos CMSs populares, entre eles o WP, se mostra bastante prejudicado pelo uso ineficiente de recursos de computação. Mesmo com todas as funcionalidades providas por plugins de cache (que em alguns casos beiram o milagroso) ainda há muito procedimento de gerar uma mesma página diversas vezes, mesmo que ela não sofra nenhuma modificação.
Além disso, com a multitude de dispositivos com acesso à web — desde relógios de pulso a televisores inteligentes, também conhecidos como “função smart”, passando por celulares, tablets, notebooks, e até mesmo computadores comuns — fica cada vez mais evidente a dificuldade de se aliarem leiaute bonito (ou “avançado”) com os tamanhos de telas dos diversos dispositivos existentes. Não são raros os casos em que o dono do blog deve escolher entre entregar ao visitante conteúdo adaptado ao dispositivo de navegação (funcionalidade esta provida por um plugin) ou utilizar cache.
O futuro como eu prevejo
Sites “responsivos” ou adaptáveis
Minha primeira aposta para tecnologias “do futuro” (na verdade são tecnologias existentes há muito tempo, só que ainda não se popularizaram) é nos assim chamados sites responsivos.
Sites responsivos são feitos de tal forma que não importa com que navegador (ou dispositivo) o usuário acesse, o site sempre será visualizado corretamente, e de acordo com as dimensões da tela do aparelho.
Uma vez que não seja necessário usar de gambiarras para ter um site “versão móvel”, o que na prática implica ter dois conjuntos de código funcionando ao mesmo tempo, obtêm-se pelo menos 50% de economia de mão de obra e de recursos.
Geradores de conteúdo estático
Esta é uma outra tecnologia que não é nova, mas que está se enraizando sem pressa mas também sem trégua.
Diferente do paradigma atual (um conjunto de scripts que geram páginas dinamicamente a partir de consultas feitas a um banco de dados), os geradores de conteúdo estático geram os arquivos HTML do site uma vez (ou sempre que o dono do site quiser), quando necessário, quando criado conteúdo novo, ou qualquer outra situação em que realmente seja necessário republicar o conteúdo.
Já existem muitos programas para geração de sites estáticos, mas eu estou apostando minhas fichas todas no Axe. Explico.
- O autor do Axe, o Augusto, é conhecido na “comunidade”: tem sites muito respeitados acerca de Linux e do mundo Apple, não fala besteira e no decorrer de muitos anos de estrada já mostrou quem é.
- O Augusto é blogueiro, igual a mim. Ele sabe das necessidades de um blogueiro com relação a um CMS.
- O Axe é escrito em PHP, linguagem que eu domino e em que posso escrever código para complementar as funcionalidades que o código do Augusto não contemplar.
- Aliás, o Axe é Open Source, ou seja, é lícito a qualquer um começar um novo projeto a partir do que o autor vai publicar daqui a alguns dias (pelo Twitter ele me disse hoje de manhã que prevê a publicação do código em 15 de junho próximo — veja abaixo).
E por que não computação em nuvem?
A pergunta mais óbvia que alguém pode se fazer para refutar meus argumentos é de que se existe a famigerada “computação em nuvem”, por que é que alguém teria todo o trabalho de mudar de um sistema de publicação consagrado como o WordPress para um sistema novo (para o usuário) se existe a opção de rodar o próprio WP em um sistema de “nuvem” com poder de processamento alegadamente ilimitado?
A resposta é simples: custos.
Para começo de conversa, quando se configura um servidor apenas com o necessário para servir o conteúdo estático, sem a necessidade de scripts dinâmicos (ou seja, PHP), sem banco de dados, o custo da máquina pode baixar assustadoramente, na inversa proporção que a sua capacidade de entregar páginas aos visitantes aumenta.
Já no mal compreendido ambiente de nuvem, que não é a panaceia que os vendedores pregam, é necessário ter várias máquinas virtuais com funções diferentes para que o poder de “processamento infinito” seja despertado, no mínimo:
- um balanceador de carga;
- um servidor de banco de dados “mestre”;
- dois ou mais servidores web;
- opcionalmente, um ou mais servidores de banco de dados “escravos”, de acordo com a necessidade do site.
Além disso tem uma outra questão: se o ambiente de nuvem não fornecer um sistema de arquivos distribuído e em rede (o que também não é nenhuma maravilha como os vendedores tentam fazer crer) será necessário preocupar-se com o fato de os webservers necessitarem de um mecanismo de sincronização dos arquivos. O que talvez também seja um problema a causar preocupação no que diz respeito ao banco de dados.
Com um site estático, é possível ter várias cópias do site espelhadas em diversas hospedagens, e um mecanismo simples de balanceamento de carga (DNS round robin, para quem quiser pesquisar mais), de forma a criar uma estrutura de alta disponibilidade e baixíssimo custo.
Quem viver verá.