2010-02-13 24 views
6

Estoy considerando crear un sitio web con la complejidad de Facebook que debería poder escalar a los millones de usuarios. Mi pregunta es: ¿hay alguna razón para no usar Adobe Flex para un proyecto tan grande aparte del punto obvio de requerir que todos tengan Flash instalado y no tengan que depender de Adobe? En mi opinión, Adobe Flex reduciría la carga del servidor para Facebook, porque podría hacerme más trabajo en el lado del cliente. ¿Estás de acuerdo?¿Se pudo implementar Facebook en Adobe Flex?

+3

Estoy muy contento de que no se haya implementado en Flex, sería una pena no poder usar Facebook en mi SO de código abierto. – Earlz

Respuesta

7

Por supuesto, Facebook podría haberse implementado en Flash. Pero entonces la pregunta es ¿habría tenido éxito? Hay razones por las que las grandes compañías web como Google, Facebook y Yahoo solo usan Flash tan moderadamente como sea posible.

Lo que más me temo es alienar a los usuarios. El complemento Flash no es la mejor pieza de software que existe. Es lento y es probable que se bloquee de vez en cuando. Si su aplicación crece, es posible que obtenga algunos tiempos de carga que podrían no ser aceptables para sus usuarios. También, en mi opinión, los sitios completos de Flash simplemente no se sienten bien porque se comportan de manera diferente a los sitios web de HTML. Todos los sitios web geniales como Google, Flickr, Stackoverflow o Facebook se sienten muy livianos y resbaladizos, lo cual es muy elegante y compensa la gran facilidad de uso.

Y a continuación, HTML y JavaScript son mucho más flexibles. ¿Quieres que tu sitio web esté disponible en smartphonse? El iPhone no tiene Flash e incluso con teléfonos que tienen el problema de que los usuarios probablemente odien un sitio Flash completo, ya que esos teléfonos no necesariamente escalan Flash tan bien como escalan HTML y Flash consume la batería como loco. Si a alguien se le ocurre otra revolución como los teléfonos inteligentes, puede estar seguro de que es compatible con HTML y JavaScript, pero no puede estar tan seguro acerca de Flash.

Entonces la pregunta es ¿cómo ganarías alguna eficiencia? Por supuesto, puede escribir su UI con Flex y simplemente llamar a servicios web muy livianos como los usaría para AJAX e incluso puede almacenar en caché parte del contenido localmente para que no transmita más datos según sea necesario para la interacción del usuario (la IU se transmite solo una vez). Pero también puedes hacer eso con JavaScript. Puedes escribir tu UI en HTML y JavaScript, cargarla una vez y luego extraer los datos JSON desnudos de los servidores y renderizarlos usando JavaScript.También puede obtener muchos de estos datos por adelantado para disminuir el número de solicitudes. Pero aún así un enfoque así tiene sus contras. ¿Alguna vez notaste que cuando escribes una respuesta en stackoverflow y alguien más envía una respuesta, se te notifica mientras escribes tu respuesta? Estas características en tiempo real son muy buenas y es posible que desee esto en algún momento, lo que significa una mayor interacción del servidor.

Pero hagas lo que hagas, tus servidores aún tienen que escalar si tu sitio crece. Incluso si minimiza el número de solicitudes GET que llegan a sus servidores, crecerán mucho cuando su sitio se vuelva popular y necesitará muchos servidores para manejarlo, solo mejorará su proporción usuarios/servidores.

El punto más interesante es que Flex es mucho más fácil de programar que AJAX (piense en incompatibilidades de navegador por ejemplo) y todavía AJAX no solo se inventó sino que el mundo entero se enreda con todos los problemas que vienen en vez de usar Flexionar. Creo que esto dice mucho sobre el valor del resultado que obtienes al crear un sitio web completo en Flash.

4

Ir a facebook y ver la fuente ... ¿Ves todo ese JavaScript? Que todo se ejecute en el lado del cliente

+0

Pero cosas como multithreading son, por lo que sé, solo compatibles con GoogleGears. Esto significa que utilizar al cliente será mucho más complicado. – David

+0

@David, creo que su exceso de utilización del código del lado del cliente, a continuación ... No debe necesitar código multi-threading para ejecutarse en un navegador para todos los propósitos prácticos. (¿Sabes que no debes crear consultas SQL en el lado derecho del cliente?) – Earlz

+0

tu cliente llamará a un servicio en el servidor que podría ser paralelizado allí ... por lo que sabes, el cliente aún ejecuta una caja PIII 600 MHZ. . – SQLMenace

2

Flex es la GUI para el cliente. Aún necesita almacenamiento en el lado del servidor y eso es lo que tiene que escalar. La interfaz de usuario podría estar en Flex, mientras que a la mayoría de sus usuarios no les gustarían tales interfaces.

+0

Lo de la familiaridad, es un buen punto. – David

+0

No obtengo los votos abajo aquí (tal vez la afirmación argumentativa sobre "los usuarios no les gustarán tales interfaces") La cuestión fundamental del cliente frente al servidor es un punto muy válido. – jeroenh

1

Tendrá que hacer una versión personalizada de su sitio para el iPad/iPhone.

Existen otras formas de mover la carga hacia el lado del cliente. Javascript le dará dolores de cabeza de portabilidad, pero menos que alejarse de toda la arquitectura como Flex.

OTOH cuando obtenga un millón de usuarios, tendrá los recursos para volver a implementar su sitio.

+0

El soporte para iPad/iPhone es un excelente punto. Reimplementar un sitio nunca es favorable, incluso con recursos casi ilimitados. – David

+0

Lo siento, estaba siendo un poco gracioso :-) La respuesta correcta es, cuando tienes "millones de usuarios", podrás pagarle a alguien para que te lo reemplace, o lo vendas a Google :-) –

+0

Por cierto, creo que es un excelente nombre para un clon de Facebook :-) –

4

Johannes tiene razón al señalar la diferencia entre el servidor y el cliente. Las cosas del lado del servidor es lo que necesita escalar.

Como ejemplo, el equipo de Microsoft Silverlight ha ensamblado un facebook client app in silverlight (utilizando la API pública de Facebook). Mi punto es que, usando las tecnologías de hoy, es completamente posible escribir una aplicación web dirigida a muchos tipos diferentes de tecnologías de cliente: navegadores web clásicos (HTML/javascript), 'aplicaciones de Internet sofisticadas' (flex, silverlight), ...

Vea también la gran cantidad de clientes de Twitter que existen.

+0

Me gusta su punto de uso de muchos clientes. Sin embargo, agrega complejidad. – David

4

La empresa para la que trabajo tiene una gran aplicación en Flash utilizada por los gobiernos. Es muy difícil de mantener y falla algunas veces. El problema es que todos los archivos .fla y .as deben ser alterados solo para hacer un pequeño cambio. Sí, la aplicación podría haberse construido mejor, pero aun así, es aún más difícil de mantener que una interfaz HTML/JavaScript.

Si bien me encanta escribir aplicaciones Flash/Flex, creo que deberían complementar un sitio y no serlo.

El uso de un buen marco de JavaScript como jQuery elimina la pregunta de compatibilidad del navegador (en su mayor parte) y permite una gran cantidad de funcionalidades.

+0

¿Por qué hay que actualizar más archivos cuando se implementa un sitio en Flex? ¿Es su opinión que crear una buena arquitectura en Flex es más difícil que en HTML/Javascript? – David

+0

Esto está en Flash pero lo mismo podría ocurrir en Flex. Hay archivos SWF que contienen la UI y la lógica de la UI, y luego los archivos AS que contienen la lógica comercial. Estos archivos AS deben comunicarse con una capa de base de datos del lado del servidor (PHP en este caso). Eso significa que si tiene un problema, está en PHP, AS o SWF. Mientras que una aplicación de PHP generalmente solo tiene una clase de PHP para los datos y una página de IU para comunicarse con esa clase. –

1

No creo que veas una ventaja de rendimiento con un sitio como Facebook, porque el contenido es muy dinámico, proviene de muchos lugares diferentes y es creado por muchas entidades independientes. Flash (y por lo tanto Flex) es mejor para aplicaciones monolíticas de una sola fuente que no necesitan cambiar muy a menudo.

El valor predeterminado en Flash es crear todo en un solo archivo .swf que contenga todo. Es posible salir de este comportamiento predeterminado, por supuesto. Puede realizar llamadas al servicio web, incorporar componentes externos a través del mecanismo SWC, cargar contenido estático a través de HTTP, etc. Sin embargo, no es el patrón predeterminado, que afecta el funcionamiento de las bibliotecas y herramientas de desarrollo de Flash. Además, cuanto más hagas, menos obtendrás el beneficio de "ejecutar todo lo que podamos en el lado del cliente". Se empapa de la sobrecarga de la conexión HTTP.

El predeterminado en el viejo y simple web basado en estándares es almacenar todos los activos por separado y ensamblarlos dinámicamente en el cliente. Esta es una de las razones por las que la web es lenta, una vez más, toda esa sobrecarga de conexión HTTP, pero también por qué es flexible y dinámica. Se combina bien con un sitio como Facebook que requiere una evolución constante por parte de muchos desarrolladores independientes.

Digo esto después de haber desarrollado una aplicación Flex, con la que estoy contento. Solo una persona, yo, tiene que mantenerla, y es, naturalmente, una aplicación monolítica. Se juega directamente en las fortalezas de Flex.

+0

Puntos excelentes. Gracias – David

Cuestiones relacionadas