22

Los puntos débiles de los CMS

August 12, 2009

Publicidad / Advertisement

Drupal es el mejor CMS Open Source en este momento, pero ¿realmente es tan bueno como dicen?. El problema está en el hecho de usar un CMS para desarrollar cualquier tipo de web y muchas veces es usado para sites que escapan a sus posibilidades. Seguramente sea un problema de no tener claras ciertas cosas acerca del uso de los CMS.

En mi opinión son perfectos para hacer sites tipo blog, donde se publican contenidos tipo noticias y que no requieran mucha carga de información. Pero gracias a la gran aceptación que han tenido, en la actualidad se usan para todo tipo de sites que requieren de una programación más precisa.

El principal problema que encuentro en Drupal es el modelo de datos rígido centrado en la tabla node, que es su principal cuello de botella cuando se le exige más de lo que puede dar. Este modelo de datos es apropiado para hacer un site tipo blog. Para otro tipo de sites, es mejor crear tu propio modelo de datos relacional, con lo que evitas JOINS innecesarios entre tablas y la sobrecarga al motor de base de datos. Uno de los principios fundamentales de cualquier página web es hacer que las peticiones a base de datos  sean lo más rápidas posible y cuanto menos numero se realicen mejor rendimiento general de la aplicación. Y esto solo se consigue haciendo una estructura de tablas ad hoc.

Hoy en día hay una tendencia a usar demasiada arquitectura, ( O.R.M´s, sistema de templates, etc ) para mostrar en pantalla datos sencillos. pero eso es otro tema que no solo afecta a Drupal.  Los sistemas de caché de Drupal, no digo que sean malos, precisamente ha sido necesario desarrollar módulos de cache para mitigar las deficiencias en el rendimiento de base.  Me pregunto si no será mejor intentar solucionar el problema desde la raíz en lugar de intentar poner soluciones parciales. Caché sí, pero no para ocultar deficiencias causadas por otros problemas. Además, la cache solo es útil si la página no se actualiza cada minuto, cosa que puede ocurrir perfectamente en una página como ésta (drupal.org.es).

Quizás lo solución al modelo de datos rígido sea contruir un módulo o arquitectura que te permita construir tu propio modelo de datos, y que sustituya al CCK. Puede que esto solucione muchos de los problemas que tiene Drupal en cuestión de rendimiento y le llevaría a un nivel más alto que lo acercaría a los actuales frameworks de desarrollo en PHP. Lo mismo esto que digo ya lo estarán pensando en hacer.

Publicidad / Advertisement

 

Topics: Desarrollo web, Drupal | 3 Comments »

3 Responses to “Los puntos débiles de los CMS”

  1. Dario Says:
    August 13th, 2009 at 5:20 am

    Buena tu reflexión, aunque no estoy del todo de acuerdo.

    El tema es que Drupal posee además de las características básicas de todos los cms, buenas apis(formularios, xmlrpc, paginacion, sort, etc) y capas de abstracción (base de datos, schemas, etc), lo que te permite desarrollar sistemas seguros, no solos sitios sociales. Te lo comento porque hace un año estoy desarrollando un sistema que utiliza mucho mas el framework Drupal que su estructura como CMS y funciona de maravillas. Un plus, los hooks, con lo que Drupal ha innovado en las interacciones entre modulos (tipo plugins).

    Y con respecto a la caché, no creo que trate de suplementar una deficiencia en la estructura de la base de datos. Es más, creo que uno de los fuertes de Drupal es centralizar todo en la tabla nodes, con lo cual cada registro es tomado como un nodo pudiendo ser de diferente índole (un blog post, video, noticia, etc), y sus datos suplementarios distribuidos en diferentes tablas. Ahora bien, aumentar con otros módulos las funcionalidades de esto es primordial, con lo cual entra en juego el buen uso de la caché, que funciona para muchos fines (por ejemplo en mi sistema, cacheé las consultas a la api de adwords que son lentísimas). Con lo cual, las caché son más bien un feature que un patch.

    No está mal crear tu propio modelo de datos, pero esto conlleva grandes implicaciones de tiempo, recursos y seguramente el factor error del programador/diseñador, lo cual nos deja en el mismo punto que Drupal. Suponiendo que quieras listar todos los ultimos contenidos de tu sitio, sean videos, imagens o noticias, con tu propia estructura de datos, buen lío se te arma, ni hablar de tiempo.

    Un sitio que me tocó ver de cerca es mylifetime.com , que tiene una carga gigantesca de datos (en su tiempo 2 millones de contenidos!), y no es tan solo un blog.
    Creo que hacer una propia estructura de datos para un sitio como ese hubiese demorado muchísimo tiempo más que una simple instalación de Drupal.

    Saludos y buen posteo

  2. Juss Says:
    August 17th, 2009 at 6:19 am

    Seguro que debe ser cierto lo que dices acerca de los nodos, pero yo nunca le encargaria un proyecto a un solo desarrollador o a una empresa, cuando podria utilizar un proyecto como drupal con una comunidad tan grande, donde participan millones de desarrolladores en el mundo, haciendo pruebas y contribuyendo de una forma u otra, incluso hasta Google y Adobe ha usado este cms y contribuido con codigo.

    Seguro este problema con los nodos esta siendo analizado por muchos en este momento…

    Todavia estoy buscando las 1001 razones para no usar drupal, que mencionaste en alguna parte, pero aún no las encuentro…

  3. paco Says:
    October 16th, 2009 at 11:30 pm

    Coincido con la sobrecarga en la base de datos, quizá cuando ya se pueda usar mySQL proxy con Drupal se pueda mejorar el rendimiento. Es cierto que hay que currarse mucho el tema de cachés con drupal, Authcaché, memcache…, ésta ultima con instancias distribuidas y que en sitios grandes tiene comportamientos erráticos. Hay que afinar mucho para obtener un buen rendimiento.

    Otro tema que es bastante cansino es el theming. Digamos que tanto el core como los módulos que aporta la comunidad no se puede decir que aporten las mejores prácticas en cuanto a marcado y/o CSS. Ya sea semántica, embeber microformatos, mucha divitis, o simplemente poca lógica en cuanto a la estructuración para poder encajar diseños de agencias y/o diseñadores que por otra parte no suelen tener conocimientos técnicos en este aspecto y menos de Drupal, lo cual es un handicap. Así, la única forma es atacar la maquetación y las prácticas SEO mediante las formas que Drupal proporciona para capturar y sobrescribir los hooks theme. Sobrescribir a mi modo de ver no es óptimo, y no, no me conformo con el marcado que me dan. Encima, muchos módulos se saltan a la torera las propias practices de enmarcar en function themes dichas salidas, embebiendo en el código a capón los outputs HTML (mucho MVC no veo), lo cual a veces te lleva a adoptar medidas poco “estéticas”. En cuanto al CSS, pues tampoco es de lo mejor, y encima buena parte está pensado sólo para Firefox. Nos guste o no, en sitios grandes todo se tiene que ver bien en IE, Webkit o cualquier otro motor/navegador, por mucho que MS sea el diablo, se trata de ser realistas.

    No sé si en Drupal 7 creo que vamos a disponer de una solución digamos “RAW”, que al menos nos permitirá tratar mejor el theming.

    por otra parte, javascripts o frameworks javascript, cuando crecen los módulos no es descabellado encontrarte con cargas de librerías repetidas, o código js poco óptimo a nivel de rendimiento tanto en la forma de cargarlo como en otras cuestiones como delegación de eventos, bubbling, etc.

    Muchas de estos issues te obligan a hacer, y sobretodo cuando el tiempo apremia, verdaderas guarradas a nivel de código, bad practices, código spaguetti, etc.

Comments