Usando un marco como Backbone [cerrado]

Actualmente tengo una página http://proctors.org/tv que está impulsada por varias vistas y archivos adjuntos con toneladas de jQuery y spaghetti JavaScript hackeado, y me gustaría limpiarlo. Entiendo que los marcos más recientes de JavaScript "MVC" hacen uso de plantillas y no almacenan estrictamente todos los datos en el DOM como lo haría con jQuery.

Creo que usaría algo como Servicios y / o Vistas como back-end, con Backbone en el frente.

Hay un proyecto Do para Backbone , y recuerdo que hubo un BoF o una Sesión en DrupalCon Denver al respecto ...

Espero descubrir si vale la pena intentar reescribir esto en un nuevo marco o simplemente limpiar lo que tengo aquí.

He usado Ember y Backbone junto con Drupal, pero no de la forma en que piensas.

Ember y Backbone son herramientas excelentes para crear una aplicación web, pero Drupal no es realmente una buena herramienta para usar junto con ellas. Lo que deseas cuando creas una aplicación web es algo ligero y rápido. Desea que sea rápido para poder dar a sus usuarios la sensación de tiempos de respuesta inmediatos. Desea que sea ligero para mejorar la escala. Drupal no es rápido: el arranque completo de Drupal lleva mucho tiempo (en comparación con muchas otras opciones) si todo lo que desea hacer es proporcionar una API REST para su aplicación web. Drupal es PHP, lo que también hace que tenga mucha RAM y limita la cantidad de usuarios concurrentes.

Entonces, si Drupal es tan malo para esto, ¿por qué usarlo?

Realmente deberías usar Drupal para lo que Drupal se destaca en: un CMS. Lo que he hecho en el pasado con proyectos que necesitaban una aplicación web es usar Drupal para crear el CMS alrededor de la aplicación web. Para construir cosas como blogs, listas de contenido y me gusta. También creé módulos para definir algunas cosas de back-end, como definiciones de esquemas y otras cosas en las que tenía sentido usar Drupal, porque hizo que mi desarrollo fuera mucho más fácil.

En lugar de usar Drupal para crear la API REST que necesitaba la aplicación web, utilicé Node.js para crear la API REST real y otras comprobaciones que AJAX llama que debía realizar la aplicación web. Node.js sobresale al hacer esto. Es increíblemente rápido (tiempos de respuesta tan bajos como 30 ms para una lista de objetos). También es muy liviano, ya que JavaScript en el servidor usa acciones asíncronas, un servidor Node.js generalmente puede manejar miles de usuarios concurrentes donde PHP puede manejar quizás 100. Además de eso, ya que Node.js es JavaScript, puede reutilizar mucho del servidor de código y del lado del cliente. Literalmente, puede escribir el mismo código de validación, en lugar de tener que implementar tanto el lado del cliente en JavaScript como el lado del servidor en PHP. Si va a ir a Drupal con en Münich en unas pocas semanas, debería considerar ver la presentación de node.js.

Entonces, si usted es un desarrollador, le recomendaría encarecidamente que haga una configuración similar, y solo use Drupal para lo que es realmente bueno. Si desea crear una aplicación web simple y no espera muchos usuarios, usar Drupal como back-end podría ser una opción si ayuda a su tiempo de desarrollo.

Actualizar Drupal 8

Entonces, con el lanzamiento de Drupal 8, algo de lo anterior sigue siendo cierto, pero no en la misma extensión que antes. Drupal 8 es como Drupal 7, no una herramienta ligera, como Node.js, Rails, Django, etc. Dado que las aplicaciones de JavaScript consumen principalmente varios servicios, aún debe considerar si Drupal es la mejor herramienta para esto.

Con Drupal 8 se han mejorado muchas cosas. Los servicios son mucho más nativos, con Symphony dirigiendo la solicitud / respuesta. Drupal 8 tiene muchas posibilidades interesantes con el almacenamiento en caché avanzado y todas las excelentes características. Pero incluso con toda la grandeza de Drupal 8, sigue siendo mucho más pesado que las aplicaciones livianas. Es difícil saber qué tan exitoso se puede utilizar Drupal 8 como proveedor rápido de servicios web.

Aún así, con todo lo dicho y hecho, mi recomendación general sigue siendo la misma. Al ser un desarrollador de Drupal, es fácil usar Drupal para todo, ya que estamos familiarizados con él. Se siente seguro y Drupal se puede usar para casi cualquier cosa. Recuerde que aunque es posible usar Drupal para cualquier cosa, no significa que sea la mejor herramienta para todo. Hacer un análisis sólido y comprender las fortalezas y debilidades de las herramientas que desea utilizar en un proyecto de TI siempre será de gran ayuda y puede ayudarlo a evitar terminar en una posición de bloqueo con un resultado que no cumple con sus expectativas .

Recientemente comencé a desarrollar mi primera aplicación backbone + drupal y realmente la estoy disfrutando. Usar el módulo Backbone junto con Servicios, Vistas de servicios y las bibliotecas requeridas. El proyecto es bastante simple: crear un carrusel de contenido manejable de 6 páginas que muestre varios datos, junto con un control deslizante de Noticias adicional que muestre contenido diferente. Esta página se encuentra en varias pantallas sin interacción del usuario, por lo que se requiere la capacidad de actualizar el contenido front-end sin actualizar el navegador. Pensé que esto encajaba perfectamente en una aplicación Drupal + Backbone con Drupal administrando el contenido y la columna vertebral controlando y sincronizando con el db. Me integré en jquery.cycle 2, que tiene una API increíble y se adapta bien al estilo de codificación MVC.

Puedo ver por qué las personas pueden asomarse al usar Drupal como marco de back-end, pero para una pequeña aplicación como esta, Drupal es ligero y rápido . Lo logré comenzando con una instalación mínima y seleccionando cuidadosamente los módulos contrib y core. Ahora tengo alrededor de 50 módulos con un poco menos de 150 líneas de código JS personalizado para el backbone y ya casi termino.

Eventualmente, intentaré confirmar esto como un ejemplo para el módulo backbone, ya que actualmente no hay ningún ejemplo que muestre cómo usar las Vistas como colecciones, etc.

En conclusión:

Merece la pena investigar esto si su proyecto coincide bien. En mi opinión, los problemas de rendimiento derivados de la pesadez de Drupal se pueden combatir fácilmente mediante el uso de mecanismos de almacenamiento en caché como Varnish, o incluso aumentar o almacenar en caché la página principal. La flexibilidad y la velocidad de desarrollo del uso de Drupal supera por completo los aspectos negativos para mí.

La respuesta básica es sí, algunas personas lo están usando. No lo he usado yo mismo (todavía no he encontrado una buena combinación de proyecto), pero actualmente hay un grupo Drupal para él, y también encajaría con la Iniciativa de Servicios Web y Contexto Básico, que es una de las Iniciativas de Drupal 8 . También hay una sesión en DrupalCon Munich 2012, Backbone.js en el Frontend .

Todavía no sé si está listo para el horario de máxima audiencia, pero en mi opinión vale la pena crear una prueba de concepto si tiene algo que podría beneficiarse de él y puede diseñar el lado JS para una interfaz y no una implementación . Eso ayudaría a aislar cualquier cambio en el backend si decide rescatar a Drupal, por cualquier razón.

Puede resultarle útil: muestra un ejemplo de conversión de un script basado en JQuery en un script de backbone. Obviamente, necesitará extraer backbone.js, ya sea como una biblioteca usando drupal_add_js o usando el módulo.

https://github.com/kjbekkelund/writings/blob/master/published/understanding-backbone.md/