No voy a explicar qué es CORS, la página de la wikipedia y cientos de web a golpe de búsqueda te lo explicarán. A mi gusta verlo como el gran bugfix del desarrollo web. Este post trata de explicar algunas de las dificultades que nos hemos encontrado en el uso de CORS después de dos años usándolo en producción.
Hasta ahora hemos estado usando JSONP y otros hacks para consumir servicios de dominios diferentes al que se ejecuta nuestra web app. Aunque tenga una siglas más o menos aparentes, detrás de ellas se esconde un hack horrible, que nunca debería haber existido. Alquien pensó que ya era hora de cambiar eso, que debería haber una tecnología que permitiese coger datos de dominios usando AJAX que no son el nuestro de forma segura. Y ahí entro CORS.
Nosotros en cartodb y otros proyectos de vizzuality usamos CORS cosas muy variopintas:
- poder manipular los píxeles de las imágenes (para hacer análisis raster en mapas)
- poder hacer POST y con enviar más datos de los que permite una petición GET
- consumir datos de nuesta API desde aplicaciones web sin necesidad de un backend
Decir que en ningún caso hemos usado autentificación, desconozco lo completo que será el tema, pero imagino que tendrá sus cosillas (hay tokens CSRF por ejemplo) de por medio.
Cuando digo que tenemos en producción quiero decir que hemos estado más de 9 meses basando nuestra arquitectura pública de mapas en CORS, quiero decir, ya hemos llegado a la fase de “esto functiona” a “vamos puliendo los detalles”. Cuando digo producción, digo millones de usuarios y en sitios con mucho tráfico y usuarios diferentes, por ejemplo, wikileaks, blog de twitter, lemonde, the guardian y otros con mucho más tráfico que no recuerdo.
Los problemas que nos hemos encontrado:
- INTERNET EXPLORER. Sí, las versiones anteriores no lo soportan y dependiendo de como le de [1] IE10 a veces reporta que tampoco lo soporta. Así que tendrás que tener un fallback ( leer la siguiente)
- Vas a necesitar un fallback: no puedes basar tu arquitectura en CORS, aunque los navegadores que soporten sean compatibles, hay muchos otros problemas (leer siguientes), así que vas a tener que tragar con JSONP o proxy en tu servidor.
- Algunos proxies eliminan las cabeceras de CORS. Cuando tu navegador web hace un OPTIONS antes de hacer la petición de verdad (necesita saber si puede de verdad hacerlo) si eliminan las cabeceras el navegador devolverá un error.
- El número de peticiones se multiplica. Hay que hacer un OPTIONS antes de hacer la petición real. No es que sea mucha carga, pero es una petición más que tus servidores tienen que tragar (no es cacheable según el standard y efectivamente los navegadores no las cachean), hay cierto lag y es un fastidio cuando estás desarrollando.
- Ahora ese problema ya no existe, pero durante este tiempo tanto chrome como FF han cambiado la forma de funcionar.
Para terminar, nosotros basamos todo nuestro API de mapas en CORS y teníamos como fallback JSONP. Hace cosa de 1 mes hemos pasado de usar JSONP como herramienta principal y CORS como fallback. Falta aún un tiempito para poder basar todo el sistema en CORS, pero desde luego es un gran avance en el desarrollo web.
Ya hay mucha gente incluyendo las cabeceras de CORS en sus servicios permitiendo hacer algunas cosas interesantes, por ejemplo, los tiles de los mapas de google los incluyen o algunos servicios de autentificación, por ejemplo openstreemap, permitiendo hacer oauth desde javascrip
[1] si está en modo compatibilidad IE10 no funciona CORS, pero incluso a veces en modo normal, tampoco.
During the Torque development (a small javascript library to create animations on maps) we decided to use a markdown template to write there the reference API documentation:
https://gist.github.com/javisantana/6413167
some goodies about it:
- plain text
- easy to read without format
- plenty of tools to transform to html (or whatever)
- easy to parse if the project grows and it need to be transformed to something better
- nice starting point. Useful when you don’t know how/where to start
While I was coding I always had a vim window open with the documentation so I can update it at the same time I was changing the interface in the code. It’s the only way I’ve found to keep the API documentation up to date.
At the end this is another example of “stone soup" story. In this case putting this file in a doc folder and opening it every time you start to code remind you need to update it.
Llevo desarrollando en javascript casi exclusivamente 2 años y pico, posiblemente sea el lenguaje que más he usado de continuo en mi vida profesional. A pesar de ello no conozco cada detalle del lenguaje, cuando eres más jóven te entretienes en conocer cada aspecto y uso de cada cosa que usas, quizá pensando que eso es saber programar.
En este tiempo sin embargo me he intentado centrar en mejorar la arquitectura y organización de las aplicaciones. Hay cosas que son comunes a todos los lenguajes pero es inevitable aprender ciertos patrones concretos del lenguaje que estás usando, y javascript tiene unos cuantos.
Javascript no tiene un sistema de gestión de módulos. Eso es un gran problema, ya que no hay una forma de importar módulos, de hacer sandboxing (de una forma coherente), etc. Casi todos los lenguajes lo tienen, mejores o peores, pero todo el mundo usa la misma forma y simplifica mucho las cosas. Y esto parece una gilipollez suprema, pero modula muchísimo el uso del lenguaje.
Cuando haces una aplicación javascript grande, la organización del código, de módulos, la separación y todas esas cosas que todos sabemos que hay que hacer bien pasan a ser fundamentales. Por esa razón la mejor forma de hacerlo bien es coger ideas de otras aplicaciones que ya están funcionando. He visto algunas presentaciones y librerías donde te explican como modularizar todo, organizarlo con un buses, eventos, patrones, pero en general, no se basan en experiencia real.
Algunas de las aplicaciones que uso como referencia para coger ideas son las siguientes (todas ellas en producción, con millones de usuarios en algunos casos):
- DocumentCloud: es posiblemente la primera aplicación hecha con Backbone (por los creadores obviamente) y es interesante por dos razones: 1) la organización de la aplicación 2) el uso de Backbone. Como nota adicional, conocí a Jashkenas y además de ser un tío inspirador me quedó bastante sorprendido de algunas decisiones tomadas en Backbone.js, sobretodo relacionadas con cambios a lo largo de su historia.
Se ha quedado un poco obsoleta (usa backbone 0.4 o algo así)
- prose: posiblemente no lo conozcas, es un editor de contenidos basada en github. Usa Backbone también, pero esta está mucho más actualizada y tiene algunas cosas interesantes que cuentan los magos de mapbox en su blog.
- iD: es el nuevo editor por defecto de OpenStreetMap. Tiene la peculiaridad de que está construido todo con d3, no usan jQuery y tienen un sistema modular para los widgets algo diferente. Tom MacWright lo explica en su blog con detalle (este post es un must). Muy bueno el documento de arquitectura en su repo.
- CartoDB: vale, esta aplicación es la que desarrollamos en Vizzuality, pero que la hagamos nosotros no significa que no tenga cosas interesantes. Seguramente haga un post detallado de la arquitectura frontend de CartoDB, pero hay algunas cosas interesantes que puedes ver, por ejemplo la gestión de vistas, o como organizamos las diferentes partes de la app
Seguro que hay muchas más, pero estas son las que me han parecido más realistas, interesantes y por supuesto en producción. Nunca me fio de algo que no está en producción
No sé exactamente si esta es la expresión correcta, creo que el refrán original es “a capar se aprende cortando cojones”. Lo bueno de los refranes es que aunque los versiones los entiendes perfectamente.
Me quedo embobado todos los días de Dios con el making of de las cosas, de hecho lo normal es que me interese más el como se hace que el resultado final, desde como pasa lo que compras la cajera del mercadona (ese estilazo colocando los códigos de barras), como limpia el pescado el pescadero o como con solo escuchar el sonido de un coche un mecánico es capaz de saber el problema de un coche.
El factor común es que todos tienen los huevos pelados de hacer eso. Seguro que hay gente portentosa que en 5 minutos es capaz de hacer maravillas, pero si eres normal te va a costar trabajo y mucho esfuerzo dominar algo. De hecho el repetir una tarea no basta, hay que analizar el proceso y el resultado, cada vez, variar y analizar, todas las santas veces.
Por eso cada vez que veo a alguien que profesionalmente admiro, que hace las cosas como me gustaría hacerlas, me pregunto como fueron sus inicios y trayectoria, las horas que ha echado mejorando, las veces que la ha cagado y sobretodo las que ha pensado en mandar todo a tomar por culo.
Y todo esto viene por este video.
This is the mail I sent to the internal mailing list in vizzuality some weeks ago when we started to prepare the next big release of CartoDB (probably it will be live when you read this post) with some guidelines to report bugs while manual testing is performed. I think it might be useful for you:
Hey, The following days we will report lot of bugs (I hope not …) and there are some things we can do to improve the time they take to be resolved:
We assume we work on chrome/osx. If you are using other browser/OS report it, specially IE/windows.
Sometimes the bugs can’t be reproduced easily, don’t worry, just report it and write all the things you did, every detail is important and write you can’t reproduce always. This is very important because if you don’t say that we will mark it as invalid and we will spend some time discussing it
Please, don’t use “gets crazy”, “crash”, “does not work”, they don’t provide information and make developers feel bad, really.
Spend time reproducing and reporting the bug, if a bug report is good the resolution is easier.
Open developer tools (or similar) when you are testing, if you see a javascript error, report it in the ticket. In some cases resolution time is 100x faster.
Do not assume things work in the way you think, please report the expected behavior
Be smart reporting bugs. Maybe that wrong padding is important, but if there are 200 tickets with real important things that does not work report it and add to a different milestone. Tickets are like inventory, keeping inventory cost money: http://www.joelonsoftware.com/items/2012/07/09.html
and the last one but not less important:
Thanks