Cómo elegir entre un marco ligero o pesado para la aplicación web [cerrado]

7

En mi función actual como desarrollador de software en una tienda Java / Spring / Hibernate / JSF , a veces me piden que desarrolle aplicaciones web a gran escala con muchos sistemas de interfaz y / o grandes bases de datos < em> así como aplicaciones web a pequeña escala con poco tráfico y / o bases de datos simples. Para acomodar esta variación, me gustaría tener 2 pilas de tecnología para elegir, dependiendo del tipo de aplicación que se me solicite desarrollar. Creo que esto nos beneficiaría porque creo que nuestra pila de tecnología que mencioné anteriormente es un poco sobre diseñada o incómoda para aplicaciones CRUD pequeñas y simples.

Si, por ejemplo, he elegido Spring Framework para mis aplicaciones a gran escala y ¡Juega! Framework para mis aplicaciones a pequeña escala, ¿cómo elijo cuál usar para una aplicación determinada? En otras palabras, ¿cómo puedo saber si una aplicación web propuesta califica para un marco pesado como Spring o podría beneficiarse más de un marco ligero y ágil como Play?

¿Puede alguien darme algunos puntos de control aproximados para ayudarme a decidir qué tipo de marco usar (pesado o liviano)? Si utiliza este enfoque de dos marcos, dígame qué criterios utiliza para decidir qué marco es el más adecuado para una aplicación web determinada.

    
pregunta CFL_Jeff 25.02.2013 - 19:57

1 respuesta

3

De hecho, una implementación a gran escala de Java / Spring / Hibernate / JSF puede ser un poco demasiado diseñada para los requisitos de muchos sistemas a pequeña escala, sin embargo, normalmente evalúo los nuevos requisitos de las aplicaciones con los siguientes factores para ayudarme a determinar la arquitectura adecuada:

Carga anticipada de usuarios

  • ¿Cuál es la carga anticipada de usuarios?
  • ¿Hay potencialmente una enorme cantidad de usuarios?
  • ¿Están los usuarios realizando tareas que utilizarán grandes cantidades de recursos?
  • ¿La aplicación necesitará escalar horizontalmente con mayor carga?

Alcance futuro anticipado

Esto es difícil de juzgar a veces porque el alcance a veces puede ser a capricho o voluntad de un gerente de producto o persona de ventas. Si anticipa que incluso existe la posibilidad más pequeña de que un vendedor intente marcarlo y venderlo a cualquier persona que no sea las partes interesadas originales, entonces es mejor ir con un enfoque más estratificado.

Necesidades del sistema distribuido

¿Existen necesidades anticipadas para que diversos consumidores diferentes logren información diferente de diferentes maneras (aplicación móvil, ETL, SSO, servicios web públicos, etc.), entonces siempre desea tener un enfoque de distribución de tres niveles y tener una lógica Separación de componentes y capas. Estos tipos de requisitos arquitectónicos serán mejor atendidos por un enfoque más diseñado.

Restricciones presupuestarias

¿Cuál es el presupuesto asignado para alojar la aplicación en producción? ¿Requerirá costosas licencias de software propietario, múltiples VPS, computación en la nube de alta disponibilidad? Tal vez si solo se le permite un presupuesto limitado, las tecnologías de hospedaje CHEAP como PHP pueden tener mucho más sentido.

Restricciones de conocimiento

¿Cuál es su equipo más eficiente en la implementación? Cuáles son sus habilidades y debilidades. Sure Play Framework puede parecer genial para el desarrollo rápido de aplicaciones, sin embargo, si existe una curva de aprendizaje significativa, entonces quizás corra menos riesgo en el enfoque más complejo y engorroso que se comprende bien.

Restricciones de tiempo

¿Cuánto tiempo tiene para desarrollar la aplicación? Esto también juega con las restricciones de conocimiento, ya que el tiempo necesario para aprender una nueva tecnología puede ser una imposición a tiempo.

    
respondido por el maple_shaft 25.02.2013 - 21:02

Lea otras preguntas en las etiquetas