Construyendo una aplicación web que está casi completamente representada por Javascript, mientras que el back-end solo entrega Json. Hacer o no hacer

7

Como programador, y teniendo en cuenta la "diversión" general del proceso, tengo la tentación de comenzar un proyecto en Sinatra donde la única preocupación del back-end es la lógica, devolver una API de Json y luego escribir una Aplicación javascript que interactuaría con esa API para presentar el contenido real al usuario.

Soy bastante nuevo en programación y nunca antes había hecho algo así de forma remota. ¿Cuáles serían las dificultades, ventajas y desventajas de separar completamente la lógica de la presentación de tal manera? ¿Algún ejemplo de esto se está haciendo en la naturaleza?

Una de las preocupaciones más importantes es cómo responderían los motores de búsqueda a un sitio cuyo contenido se sirve casi exclusivamente como Json ...

    
pregunta o_o_o-- 18.06.2013 - 00:25

4 respuestas

5

La mayoría de las aplicaciones web que he escrito para mi empresa funcionan de esta manera: una sola página, una aplicación basada en javascript que realiza llamadas ajax a un servicio de back-end.

Entonces, cuando empecé mi propio sitio web , mi primera implementación se realizó de la misma manera. Sin embargo, más de la mitad del desarrollo, me di cuenta de que cometí un gran error.

Mi sitio web ofrece contenido a mis usuarios, y este contenido debe estar disponible a través de motores de búsqueda. También necesito monetizar mi sitio web a través de anuncios. El problema es que ambos requisitos dependen del contenido estático disponible en el sitio web .

Se requiere contenido estático para indexar palabras clave para la búsqueda y mostrar anuncios relevantes. Estas palabras clave se obtienen del texto que se encuentra en el HTML subyacente. Si su contenido se obtiene de una fuente remota y se muestra a través de javascript, es probable que su HTML subyacente esté casi en blanco.

Debido a que proporcionan una experiencia de cliente enriquecida, las páginas dinámicas son ideales para aplicaciones basadas en web. Sin embargo, si pretende entregar contenido, es mejor evitar las páginas dinámicas.

    
respondido por el jramoyo 18.06.2013 - 09:59
3

Por supuesto, vale la pena probarlo, pero debes saber que la curva de aprendizaje puede ser un poco empinada a veces (Javascript es un lenguaje fácil de odiar). Las aplicaciones web de Javascript tienen algunas características realmente interesantes. Por ejemplo, puede transferir su aplicación a varios dispositivos móviles como aplicaciones nativas envolviendo la aplicación con Phonegap.

Hay un puñado de opciones en cuanto a los marcos. Leí este artículo para obtener una descripción general de alto nivel de algunas de las opciones más populares: "enlace

En cuanto a la capacidad de rastreo del motor de búsqueda, creo que (aunque no estoy al 100%) puede hacer que se puedan rastrear algunas de las diferentes "páginas" de su aplicación usando lo que se denomina un "enrutador" (que puede ser aunque es específico de Backbone.js, y podría estar equivocado, creo que ese es el caso.) Definitivamente, puedes usar el "enrutador" de Backbone para hacer que las diferentes "páginas" se puedan marcar y enlazar, así que tiene sentido que también estén rastreable.

    
respondido por el dave 18.06.2013 - 10:42
2

Pruébalo. Hice algunos proyectos (en su mayoría con api angular y web), y fue una buena experiencia en general.

Ventajas: tiene una experiencia de usuario muy fluida y puede crear aplicaciones de una sola página con facilidad; tener una separación limpia entre negocios y UI; puedes usar el servicio web para diferentes aplicaciones (por ejemplo, para alimentar una aplicación móvil, etc. - los datos son datos, puedes reutilizarlos).

Desventajas: probablemente terminará con más llamadas al servidor, a menos que combine varias llamadas en una sola parte (por ejemplo, para extraer datos de 5 menús desplegables diferentes en una sola llamada). También puede ser un poco más lento de cargar: primero se carga una página vacía con JS, y luego se realizan llamadas a los servicios web. Obviamente, esto lleva más tiempo que solo servir una página completa. Generalmente no hay una pequeña diferencia.

SEO puede ser un problema, sí. Supongo que puede servir páginas estáticas simples para robots, si necesita que se indexen sus datos.

    
respondido por el Evgeni 18.06.2013 - 01:00
1

El mejor enfoque absoluto sería tener un marco, cms o similar en el que almacene y acceda al mismo contenido con ajax y carga de página completa. Haga que se ejecute la misma función cuando vaya a la página principal del sitio y navegue hacia el frente a través de javascript.

Por uso inteligente de .pushState () , anulando onclick a través de jQuery en los enlaces, puede tener un sitio que tenga los enlaces correctos, pero a menudo utiliza ajax para cargar nuevas páginas. El respaldo en caso de que el estado de empuje no sea compatible también existe; el usuario simple navega a la página en lugar de a jQuery y ajax anulando el efecto onclick .

Este enfoque también le encantará a SEO, ya que también puede navegar su contenido libremente. Para mencionar un ejemplo, considere mi propia galería . Puede navegar a la imagen anterior presionando en el lado izquierdo de la imagen. Esto ejecutará un .pushState() y cargará el contenido a través de ajax. Sin embargo, puedes tomar la página "nueva", vincularla a mí y me da la imagen anterior. SEO también solo ve el enlace correcto y no tiene que preocuparse por ajax y demás.

    
respondido por el Robin Castlin 18.06.2013 - 10:46

Lea otras preguntas en las etiquetas