¿Qué es un marco de aplicación web bien documentado, estable, seguro y escalable?

Question

Estamos creando una API RESTful para nuestra empresa, que proporcionará XML, JSON y, potencialmente, otros tipos de contenido.

Mi equipo está tratando de encontrar un marco que es (En orden de prioridad):

1. bien documentado
   • Idealmente con buenos tutoriales y una comunidad próspera y base de conocimientos
2. Sigue los patrones de diseño racional
   • Sobre todo queremos que consista ency en el marco. Convenciones de nombres que no cambian según el método al que llamas.
3. Secure
   • Centrado en forzando el promotor para llevar a cabo algún tipo de validación de la GET, POST, PUT y eliminar variables
4. estables
   • Parte de este es la madurez, en el sentido de que el marco no cambia demasiado a menudo
   • otra parte es una lista de errores bien documentado que no es aterradoramente enorme
5. escalable/rendimiento orientados
   • Tenemos más de 50 mil usuarios que requieren alta disponibilidad significativa en todo el mundo. Si nuestra aplicación falla, las personas no tienen Internet en su hogar. Entonces, es un ambiente altamente crítico.
   • Idealmente, podríamos lanzar la misma base de código en 10 servidores y seguir agregando loadbalancers. No quiero tener que definir qué servidor se encuentra en que los métodos ....
6. se integra bien con un Linux/MySQL Medio Ambiente
   • No tenemos un solo servidor MS. No estamos cambiando eso. ventiladores .Net Lo sentimos :-D

Me di cuenta que un objetivo nebuloso. No habrá un solo marco que satisfaga todas estas necesidades, de hecho, probablemente haya muchos que se encuentren con ellos de diferentes maneras, formas y formas.

Esto es independiente del idioma. Ya tenemos experiencia en PHP, pero también tenemos desarrolladores que nunca han escrito una aplicación web en su vida, así que aprender Python o Ruby o Java es aceptable.

Answer 1

Voy a salir en una extremidad aquí y sugerir Ruby con Sinatra.

¿Por qué?

1. Sinatra no está "bien documentado", pero está "bien documentado". Teniendo en cuenta que es mucho más simple que otros frameworks, no es necesario que haya tanta documentación, y como se basa en Rack como un servidor web, comparte una documentación común con eso. Pero lo que necesita saber está en el sitio web, está bien escrito y no contiene ningún error que haya encontrado (es decir, está actualizado).

   La mayor parte de lo que necesita saber está en el Sinatra Book, el Readme y el FAQ. A pesar de la naturaleza de trabajo en progreso del libro, sus contenidos son muy precisos y útiles. Y, si todavía tiene preguntas, visite la sala de chat de IRC freenode.net # sinatra.

2. Sinatra se puede utilizar en un método de lógica funcional/basado en ruta o anulando el objeto Sinatra :: Application. Puede usar cualquiera, dividir su lógica y métodos en varios archivos, o mantener todo en uno. Todo depende de usted.

3. Sinatra es, de por sí, seguro. DEBE validar todas las variables enviadas por el usuario, porque aparte de analizarlas y pasárselas, a Sinatra no le importa cuán válida sea. Por lo tanto, o haces cumplir la validez de tus variables o lo lamentas. ;-)

4. Sinatra no ha cambiado mucho en los últimos cuatro meses, pero ciertamente ha tenido mantenimiento y actualizaciones menores. Además, no he encontrado que la lista de errores sea grande o amenazante. Ya tengo casi todo lo que necesito para construir mis aplicaciones.

5. Sinatra no tiene que ser desplegado con pasajeros, pero puede ser fácilmente hechas a medida para ser rápido. Si usa cosas como Enterprise Ruby y Thin, puede usar proxy en Nginix o LightHTTPd. Si tomaste dos servidores, puedes hacer uno primario (con el proxy y varios hilos) y el segundo el servidor de la base de datos (con MySQL y varios hilos) y soltarlos. De esta forma, las tareas se distribuyen en los servidores. Te dará más control de lo que creo que pasajero. (Por no hablar de un mejor rendimiento.)

   Encuentro de pasajeros (en Dreamhost) para dar rendimiento relativamente bajo cuando se compara con hilos ejecutados por cualquiera de rack, mestizo, o delgada. Dicho esto, una vez cargadas, las aplicaciones responden incluso en ese entorno. Si tuviera que predecirlo, no tendría un problema con la ampliación de la aplicación como desee simplemente tiene que volver a desplegar su código y reiniciar los hilos – nada que no se puede poner en Capistrano.

6. Ruby on Linux es rápido y no es un problema de implementar. MySQL con Ruby es bastante fácil, y hay varios paquetes de ORM realmente buenos disponibles como ActiveRecord y Sequel. Sinatra no te hará elegir uno que odies.

Además de las respuestas a sus preguntas, tengo algunas más razones.

1. Sinatra tiene una curva de aprendizaje fácil, y es muy fácil de recoger. El mayor problema que tuve fue conseguirlo en mi servidor Dreamhost ya que Rack era una versión anterior, pero con una versión de Rack vendida, el problema desapareció. Si pudiera, volvería a escribir mi último proyecto de Rails en Sinatra con ActiveRecord para facilitar el mantenimiento; ya se gastó demasiado esfuerzo en eso.

   Gracias a su facilidad de uso y facilidad de aprendizaje, me he encontrado más productivo en Sinatra y sin generadores de código que en los carriles con todos los generadores de código. Y eso es decir algo.

2. Sinatra admite middleware para Rack, y por lo tanto es muy flexible en lo que puede hacer con él.

3. Si tuviera que promediar la utilidad de la comunidad Sinatra, en el IRC, yo diría que son más conocimientos sobre el marco que el usuario medio de rieles – al igual que una comparación superficial. La razón es que Rails es más accesible para los novatos y las personas que simplemente no tienen programación comercial.

4. Sinatra soportará Ruby 1.9. Todavía no estoy del todo seguro de la cantidad de soporte para 1.9 que hay actualmente en Sinatra, pero sé que inicialmente estaban esperando en Rack. As of April 25 esto ya no es un problema, por lo que presumiblemente Sinatra ya está preparado para 1.9; Sé con certeza que el soporte para 1.9 está en proceso para mediados de 2009, pero no sé cuánto tiempo será eso.

   Suponiendo que usted puede conseguir Sinatra trabajar con Ruby 1.9 con un poco de esfuerzo (versión 0.9.2 ya soportes de la parrilla 1,0 y 1,9 por representación en el código del bastidor), antes de que el público 1.0 con soporte para 1.9, su rendimiento en el Rubí lado sería estelar. Incluso si no puedes, entonces Enterprise Ruby ayudaría a la velocidad.

Answer 2

Supongo que si existiera un marco así, sería uno y único.

Answer 3

¡Pruébalos todos para encontrar la respuesta correcta!

¡Bueno, las personas que sugerirán "un marco para gobernarlas todas" tampoco las habrán probado todas!

Answer 4

Para PHP, me encantó el framework Zend (aunque para mí no es realmente un framework). Una de sus mejores características es que cada componente es independiente de los demás ... Por lo tanto, si hay alguna parte de ella que no le gusta, simplemente no la use. Además, mencionas JSON ... Zend es totalmente compatible con JSON en ambas direcciones ....

Answer 5

Ruby on Rails está ampliamente documentado con una gran cantidad de complementos y ya ha sido probado en escalabilidad (ver BaseCamp y otras soluciones hechas en rieles)

Answer 6

Si usted está pensando en Java que recomendaría Jersey, funciona muy bien y creo que llegue a todo lo que los 5 goles ...

Answer 7

en cuanto a su lista de prioridades que es difícil decir que una sola ruta es la "correcto" camino a seguir. En el lado de PHP, he pasado una cantidad significativa de tiempo con CakePHP, que logra gran parte de lo que estás buscando. Pero como soy un tipo que odia PHP, sugeriría que evites cualquier cosa en ese ámbito.

Se trata de estilo y experiencia. He usado Ruby On Rails, que no es el más elegante de los idiomas, pero hace el trabajo excepcionalmente bien. No había madurado tanto como el uso de una pila Spring/Hibernate en Java o el uso de .Net, que maneja casi todo directamente, pero hace el trabajo excepcionalmente bien. Prefiero los proyectos basados ​​en Java/.Net porque encajan mucho mejor con la forma en que me gusta programar.

No hay una respuesta "correcta", solo muchas buenas. ASP.Net MVC, por ejemplo, es una buena opción. Hace un tiempo utilicé Spring en Java, que también fue bastante efectivo para lograr el trabajo. Incluso PHP no es una elección incorrecta. Ruby On Rails, con el que solo he hecho dos proyectos, es muy fácil de aprender y hace algunas tareas bastante complicadas en otros idiomas bastante simples.

Answer 8

Bien. La escalabilidad no es nada fácil de conseguir. Para los tiempos de respuesta similares a Google, necesita algo como MapReduce. De acuerdo. No te engañes, la súper escalabilidad no es nada para los principiantes.

Como para todos los demás puntos, Seaside es claramente el mejor. En cuanto a la seguridad, consulte seaside.st para ver por qué es intrínsecamente más seguro que todos los otros marcos de los que tengo conocimiento (incluidos Rails y Seam, por ejemplo). Seaside está razonablemente bien documentada, pero también es tan fácil y conveniente observar las partes internas del mar, que apenas queda una pregunta abierta para que la comunidad responda, lo que generalmente hace rápido. Seaside ha estado estable durante muchos años, así que creo que estarás bien con eso.

En cuanto a rendimiento orientado: ejecute Seaside comercial, GLASS, obtendrá un rendimiento sorprendente en comparación con una configuración LAMP, debido a la solución de base de datos mucho más rápida que está integrada, y el marco que intercambia memoria por velocidad y obtiene mucha velocidad

Seaside está tan bien diseñado que a mucha gente le resulta más fácil escribir aplicaciones Seaside que las aplicaciones de escritorio. Pruébalo, te encantará.

PD: Para que conste, Seaside no es RESTful.

Answer 9

Ambos Django y Rails están muy cerca de ajustarse a la mayoría de sus criterios, excepto que creo que la documentación de Django es manera mejor que la de Ruby on Rails '; la documentación para Django es nada menos que increíble (y no estoy hiperbólico aquí).

No sé si la escalabilidad de Django, sin embargo. Sé que Rails escala bastante bien (hasta cierto punto), pero no sé si lo mismo se puede decir de Django. (No estoy diciendo que no puede ; sólo digo que sinceramente, no sé , ya que nunca he escrito una aplicación grande usando Django.)

Django también tiene a pony, en caso de que en secreto lo desee también.

Answer 10

Creo que por el gran volumen de documentación no se puede vencer a J2EE. También se cree que es increíblemente escalable y estable.

Ahora, de ahí a ser muy conveniente ....

Answer 11

Usted puede echar un vistazo a Django, Python framwork. Es un marco muy bien documentado, tiene una interfaz de administrador CRUD automática en la base de datos y también tiene un libro gratis en línea, que por supuesto se puede comprar de manera real :)

Answer 12

Si Java está en su kit de herramientas, mire Stripes .

Rock estable, entusiasta, aunque no es una comunidad espectacularmente grande. Buenos documentos, algunos obsoletos, pero el sistema es tan estable que incluso las "cosas viejas" son relevantes. Un libro muy bueno, reciente (finales del año pasado). Stripes es lo suficientemente pequeño como para que el libro pueda, y lo haga, "cubrir todo".

Es un marco de acción, no hace mucho en el área de presentación (salvo en el caso de los formularios, en su mayoría, y tiene un recurso de plantilla/diseño completamente opcional). Puede usar JSP o FreeMarker, o, realmente, cualquier otra cosa. También puede hacer servicios web (aunque no tan bien como algo como Jersey).

Es back-end agnóstico, pero hay un proyecto de integración JPA para él.

Finalmente, puede aprovechar, si lo desea, todos los demás juegos Java/Java EE si lo desea. Como Stripes no consume toda la pila, tienes mucha flexibilidad para elegir las piezas que deseas. Barco completo Java EE, Transacciones, Session Beans, JMS. Funciona con Spring (es "consciente" de Spring y tiene una buena integración) JPA, iBatis, Hibernate, raw JDBC, Lucene, JSR-170 Content Repository, lo que sea.

Es una gran pieza del kit.

Answer 13

Trate cppcms

es una web de alto rendimiento marco de desarrollo

Answer 14

Para una respuesta de 2014, yo recomendaría laravel/Marco Delgado (PHP), Ruby on Rails/Sinatra (Rubí), Django/Flask (Python), Grails (Groovy, lenguaje basado en JVM), Play! Framework (Java/Scala) o Sails.js/Kraken.js (Javascript).

Donde el primer marco mencionado es un poco más grande y el segundo es un poco más pequeño para los idiomas donde menciono 2 marcos con el uso de un "/".

Espero que esto ayude a las personas que tengan preguntas similares 5 años después.