Creando un reemplazo de Google Reader desde cero

Aquí Fabio invadiendo Denker Über, gracias Mariano por dejarme este espacio para comentar lo que ha sido una extraña misión en la que me embarqué.

Así fue cuando Google decidió cerrar Google Reader, lo primero que busqué fueron alternativas, pero las que encontré no me conformaban, había un problema sustancial: iba a sucederles lo mismo o, no iban a poder escalar lo suficiente. Y así como tenemos infinidad de aplicaciones para distintas tareas ¿Por qué no hacer la propia para esto?

Si, lo se, ponerse a programar un reemplazo de Google Reader iba a ser toda una tarea...

Lo primero fue tratar de entender ante qué universo me encontraba ¿Por qué Google está dejando esto? primero pensé que los costos no daban pero luego me fui enterando que Google quería poner el 100% de su esfuezo en Google Plus, la muerte del Reader no era técnica, era política.

Esto me abría la puerta porque no iba a ser una tarea imposible de escalar ni de realizar, una estructura de datos, una lógica de funcionamiento, en papel cerraba todo. Pero como todo desarrollo hecho en poco tiempo y con baja planificación, siempre hay un problema que aparece en el medio de todo.

Lo primero son los intermediarios, es decir, FeedBurner y similares. Los empezamos a usar para unificar los feeds de RSS y tener no sólo un formato común sino estadísticas confiables. Las estadísticas no fueron confiables y los enlaces a nuestras notas pasaron a tener una URL distinta. Hasta fueron utilizadas por los "ladrones" de contenido para evitar linkearnos y mil dilemas más que Google aprovechó para bajarle el puntaje a todo sitio. Fue más un problema que una solución y, para colmo, sigue siendo un producto de Google que en un futuro no muy lejano matará.

Así que hubo que limpiar toda esa basura, los "utm_source" y demás cosas que le agregaban a las urls de los blogs, lo que se estaba ensuciando las urls es sorprendente porque la mayoría parece ignorarlo, desde acortadores de url hasta feedburner todos han hecho lo posible para duplicar, triplicar y saturar las urls sin sentido. Todo esto debía "curarlo" de alguna forma.

Decidí entonces pasarle todos los filtros posibles y unirlo a otro proyecto mío: LinksDV.com que creé desde Cake Division. Este es un linksharing convencional, con usuarios votando links que les parecen interesantes, con sus categorías, tags y demás. La idea era simple, combinar los RSS que leemos todos los días con la posibilidad de compartirlos cuando nos parecen realmente importantes y darle así una mayor relevancia. Si Google nos iba a querer matar, entre nosotros nos podíamos defender y revivir.

El servidor

Parece curioso hoy en día pero el primer problema que tuve fue con el servidor. No pensé que iba a utilizar tantos recursos pero he aquí mi primer problema, ni con un volumen de datos enorme (éramos pocos usuarios inicialmente) se podía procesar en un servidor "shared", de los compartidos. Realmente son muy baratos y convenientes, con todo "administrado" y muchas veces con un buen backup diario, pero a la hora de la verdad son los primeros en caerse ¡Un desastre! y encima era de unos amigos, no daba matarlos por ello, es que yo les estaba pidiendo mucho.

Optimización fue la primera respuesta, tenía consultas a la base de datos bestiales, principalmente para tratar de evitar que la base de datos se llene de posts duplicados. Un dilema con el RSS es que uno debe guardar en su propia base de datos todos los artículos porque el RSS sólo muestra los 10 últimos, si quería dejar las notas de un sitio para que uno las vea cuando quiera no alcanzaba con guardar el título y un enlace, el contenido debía estar en el lector guardado y esperando.

Pero no alcanzó con optimizar el uso de la base de datos, cada una hora un spider debía consultar todos los feeds posibles y ver qué había de nuevo, llegó el punto que desde el mismo servidor me limitaron el tiempo de ejecución, si mi proceso tardaba unos dos tres minutos me lo cortaron al minuto ¡imposible!

Entonces decidí ir por lo más violento: un VPS.

En un tiempo récord para mis estándares en tres días instalé un Debian, Apache, MySQL, optimizaciones varias, PHP, crons y todo lo que hacía falta y migré el sitio y la base de datos, moví los DNS y luego de un fin de semana los usuarios pasaron de tener un tiempo de ejecución de 1-2 segundos para ver sus feeds a 0.0004 segundos. Oh, si, lo que un server bien configurado puede hacer.

La conclusión en esta etapa fue clara, no se puede encarar un proyecto web de magnitud alguna sin un buen servidor, un VPS de estas características, donde uno debe instalar todo, cuesta menos de 10USD por mes y te da dos procesadores para vos, 1GB de RAM y 2TB de transferencia ¿Acaso hace falta sufrir en un servidor normal? bueno, hay que aprender un poco más para la instalación y mantenimiento, pero vale la pena. He visto a muchos sufrir por sus WordPress y plugins mal optimizados, sitios caídos sin explicación alguna, el VPS es una buena solución aunque si no se optimiza, todo morirá tarde o temprano.

Escalabilidad

Aquí lo más interesante ¿Esto escala? pues bien, sí, puede, pero hay un dilema, cuantos más usuarios más volumen de datos, una de las formas que encontré para evitar duplicar contenido es guardar una sola copia de cada nota, no una por usuario, una por feed. Esto me ahorró muchos megabytes pero lo interesante fue ver los números después.

Hay una serie de sitios que son seguidos por mucha gente, luego una larga cola de sites que casi nadie lee, el grueso está en no más de 50-100 feeds por lo que no hay un gran costo en ese sentido. Actualmente se actualizan unos 1800 feeds distintos y apenas 20 estan en ese tope llamativo. El resto tienen pocos suscriptores.

La cuestión es ¿Cuando se torna imposible de manejar? hay varias soluciones si estan haciendo algo parecido, la primera es separar los servidores MySQL entre primario y secundarios, utilizando el primero para cargar los datos de los feeds y los segundos para lectura solamente. Por el momento no necesito semejante división, el costo de procesador todavía es bajo.

He leído desde Reddit como contaban esto, en su caso utilizaron Cassandra como base de datos, yo estoy con la vieja y usable MySQL pero es obvio que en algún momento, si se dispara el uso, uno estará en problemas y deberá pasar al esquema master-slave sí o sí.

Del lado del Apache/PHP también se puede escalar pero es el que menos requiere, un sistema como este utiliza mucha base de datos, así que hay que estar preparado para alquilar más de un VPS y pasar al siguiente nivel, que repliquen datos, dividir el código para que una parte escriba y otra distinta lea, no es fácil y si tu código estaba pensado para un sólo servidor es fácil confundirse.

La fachada

No soy diseñador gráfico pero trato de inspirarme en otros para hacer lo mío. La interfaz fue lo más difícil, tratar de emular a Google Reader sin los conocimientos suficientes, una tortura.

La "cáscara" del LinksDV Reader es tan sólo CSS y mucho JQuery, pero no es la panacea, es, de hecho, uno de los mayores inconvenientes a la hora de hacer un sitio que funcione bien por la simple razón de que uno comienza una aplicación como esta sin una planificación adecuada.

En una semana tuve lista la primer versión beta, en una semana no se puede hacer nada serio y planificado, menos si encima se es un equipo de una sola persona. Aun así logré aprender mucho y hacerlo funcionar, eso ya de por sí fue mucho ¡funciona! no es elegante, no es agradable a la vista, pero traté de priorizar el contenido. Al fin y al cabo uno no va a ver el lector sino el contenido de los feeds ¿que cuernos importa el aspecto del menú?

Agregué luego las opciones que le podrían dar su toque distintivo, marcar favoritos, compartir a LinksDV, ver los compartidos de tus amigos (dentro del sitio), marcar como leídos, un dashboard para ver lo más leído por los usuarios y así.

La imagen del sitio la modifiqué para que permita una vista en paneles, más o menos adaptables a la resolución de cada monitor, y listo, ahí está. En un futuro tendré que tirar todo a la basura y armarlo de nuevo, para que esté bien planificado, pero en su momento no tuve tiempo.

El espacio que Google nos dejó

La titánica tarea de reemplazar un servicio de Google en pocos días me dejó varios aprendizajes. El primero es la poca confianza que tiene el medio hacia los desarrolladores locales. Debo confesar, me sentí bastante abandonado y ninguneado por mis colegas, la mayoría de ellos rechazaron la mera existencia de mi lector.

Hoy ya lo veo como esperable, hay como un desprecio natural a lo que se hace localmente, como que "no podemos" o no tenemos la capacidad, eso duele, pero no debe desanimarnos. Al día de la fecha sigo viendo a conocidos quejarse por su lector de feeds pero que jamás le dan una oportunidad a este. Es lógico ¿Qué podría hacer un sólo developer latinoamericano que no pueda hacer uno de USA o Europa? ¿Es lógico? no importa, lo cierto es que la mayoría no le dará siquiera la oportunidad.

Esto me deja en claro algo, hay que hacer servicios y sistemas orientados hacia afuera, no hacia tu propio país, la única forma de tener una buena imagen en tu proyecto es que sorprenda a los locales con el éxito exterior ¡igual que un artista! así es, uno no es profeta en su tierra, pero hoy en día si sos famoso afuera, lo serás dentro.

Suena triste pero creo que aplica para casi todos los países latinos, y como segundo aprendizaje, Google está dejando muchos nichos abiertos que pueden y deben ser recuperados, porque a ellos poco les importa el usuario final. Estos nichos pueden ser negocios potenciales geniales que estan siendo desaprovechados y ahí tenemos un lugar donde ponernos a trabajar.

Próxima misión, entonces: internacionalizar el reader, crear la app para móviles y ver donde más nos va a abandonar el gigante.

Para usarlo simplemente pueden entrar a LinksDV Reader y se pueden registrar o usar su cuenta de Facebook y comenzar, no es el más "amigable" para gente que nunca usó un lector, pero acepto todo tipo de sugerencias (recuerden mis limitaciones, jeje)