Cómo son limitados los frameworks web

Question

Esta es una pregunta general acerca de cuán limitados son los frameworks de desarrollo web como Django y ruby-on-rails.

Estoy planeando crear un servicio web RESTful que tendrá una interfaz puramente JSON/XML, sin GUI. El servicio dependerá de una base de datos; sin embargo, para algunas de las operaciones más importantes, no hay una forma clara de persistir directamente en una tabla de base de datos un objeto "modelo". Además, necesito un control total sobre cuándo y cómo se escriben los datos en la base de datos. Necesitaré mantener conexiones de bases de datos múltiples para usar algunas conexiones solo para lecturas y otras solo para escrituras.

He visto los frameworks MVC "completos" como Django y otros más básicos como web.py y pilones. La impresión que tengo actualmente es que si voy con el marco completo, inicialmente las cosas irán más rápido, pero eventualmente me quedaré estancado porque estaré limitado por el marco en lo que puedo hacer. Si voy con un marco más básico, tomará mucho más tiempo para que todo funcione, pero seré libre de hacer lo que necesito.

Esto es lo que parece, pero sospecho que podría ser una impresión incorrecta dado cuántos sitios están escritos en Django y Rails. Podría dar su opinión ¿Estoy totalmente equivocado y hay una forma de hacer algo fácilmente con un framework como Django o Rails o teniendo en cuenta mis requisitos, debería ir con algo como web.py?

¡Gracias!

Answer 1

Los marcos web tienden a optimizarse en torno a la creación de sitios web, haciendo que la mayoría de los casos de uso normal sean más simples de lograr. Una vez que empiezas a hacer más cosas "listas para usar" con un marco, es posible que encuentres que pasas más tiempo trabajando en ello y luego guardas el uso de él en primer lugar.

Es difícil generalizar aquí (sobre todo desde que he realmente sólo trabajé en profundidad con Django), así que voy a ofrecer algunos consejos basados ​​en mi propia experiencia en desarrollo una API JSON usando Django:

put simple No recomiendo usar Django para escribir una API REST. En mi propia experiencia, realmente no encontré nada que valga la pena escribir a casa. No necesitaba el sistema de plantillas de Django, así que todo lo que realmente aproveché fue el envío de URL y el ORM. Incluso entonces, tuve que hacer algunos cortes para que el despachador de URL hiciera lo que yo quería: de no haber usado otras funciones, hubiera sido más rápido usar un sistema URL diferente, de hecho. En su caso, el ORM de Django ni siquiera sería adecuado, ya que no es compatible con múltiples bases de datos (a menos que esté usando 1.2 alphas ...). Compuesto eso con la falta de una buena señal de inicio de Django, y Django comienza a verse bastante mal para el trabajo.

Si estuviera en sus zapatos, buscaría bibliotecas específicas que hicieran lo que necesitaba (ORM, WSGI, etc.) y simplemente las usaría, en lugar de tratar de doblar y martillar a Django en algo que se adapta a mis necesidades .

En una nota totalmente diferente, es posible que desee echar un vistazo a Tornado como una posible interfaz HTTP. Es simple y rápido.

Answer 2

Se verá mucho más limitado por las capacidades de usted frente a una comunidad diversa de desarrolladores que trabajan en un proyecto grande para compartir todas esas partes comunes.

Answer 3

Rails es tan útil o no como lo necesita, en general. Si necesita cargar una colección con SQL directo, es sencillo. Si en la misma línea desea utilizar todo el ActiveRecord Fu incorporado, puede hacerlo. El enrutamiento RESTful es extremadamente simple, pero nuevamente si el sabor particular de Rails de REST no satisface tus necesidades, el enrutamiento es completamente configurable. En una aplicación de Rails, puede usar tanto o tan poco de los valores predeterminados que necesite, y la reconfiguración está disponible en todos los niveles.

Answer 4

Puede seguir utilizando todo el potencial del idioma en cuestión, incluso si también utiliza un marco. Un marco no es un factor limitante, es básicamente una herramienta para facilitar el desarrollo de ciertas partes de su aplicación. Django y los rieles, por ejemplo, resumen algunas funcionalidades de la base de datos, por lo que solo tendrá que preocuparse por los objetos de su modelo. Eso no significa que tampoco puedas hacer cosas tú solo ...

Answer 5

Si no estás utilizando la capa de presentación de Rails, te estás perdiendo una gran parte. La funcionalidad necesaria para volcar objetos a json/xml es tan pequeña que las únicas ventajas reales que podría obtener serían el ActiveRecord y el enrutamiento, y si no puede imaginarse que sus datos encajan perfectamente en un modelo, entonces eso no deja mucho .

Creo que realmente solo necesita un marco minimalista para ocuparse de algunos de los aspectos básicos. Algo que le proporciona algunas sutilezas sobre el manejo/enrutamiento de solicitud/respuesta y se sale de su camino. El equivalente en Python de algo como Sinatra podría estar en tu calle. Utilizo un framework similar en Scala llamado Step para webservices basados ​​en xml/json, donde me importa el rendimiento (y no hay presentaciones en curso).

Estoy echándole un vistazo a web.py, parece que cubre un nivel similar de funcionalidad a Sinatra/Step. Siento que esa es una dirección más apropiada que algunos de los marcos de funciones más completos. No me arrepentí de mi elección de Step, la base de código es tan cómicamente pequeña que es imposible no comprenderla, y eso hace que sea fácil ampliarla ligeramente si es necesario.

Answer 6

He usado Ruby/Rails desde hace años y, a diferencia de casi todos los demás lenguajes/frameworks que he usado (a lo largo de casi 15 años de Java, PHP, ColdFusion, ASP, etc.), se quita cuando lo necesitas para.

Parece que podría beneficiarse de un marco de "peso liviano" como Sinatra, pero con la próxima versión de Rails 3 los beneficios son cada vez menos pronunciados. Rails 3 hace que todo sea configurable ... de hecho, ahora Rails será un conjunto particular de complementos y extensiones sobre un núcleo infinitamente flexible.

Estoy interesado en esta declaración:

"El servicio se basará en una base de datos sin embargo, para algunas de las operaciones más importantes no hay manera clara de la persistencia de un 'objeto de modelo' directamente en una tabla de base de datos ".

No estoy seguro de lo que quiere decir con esta afirmación ... en algún momento tiene algo que entrar en la base de datos, ¿verdad?

En la mayoría de las aplicaciones no triviales raramente tiene un solo modelo vinculado al final de una solicitud ... en realidad podría tener una red bastante compleja de modelos que se devuelven o actualizan.

Si está trabajando con JSON, definitivamente sugeriría buscar en una base de datos como MongoDB. MongoDB se basa completamente en el almacenamiento de datos JSON, y por lo tanto puede ajustarse muy bien con su aplicación.

Answer 7

La mayoría de los sitios web serán bien adaptado a los marcos ricos como Rails o Django - pero usted está construyendo una red de servicios , y que tiene muy diferentes ventajas y desventajas.

Personalmente, yo prefiero usar muy marcos de luz para los servicios web: en Python, eso significa basándose principalmente en WSGI (que es un estándar, no un marco), con un mínimo de componentes altamente modulares para proporcionar alguna pequeña extras que pueda necesitar dependiendo de los detalles de los servicios (WSGI es muy bueno para permitir la composición modular de bits y piezas de "middleware").

Mi colección favorita personal de componentes WSGI modulares es Werkzeug, con WebOb para objetos de solicitud y respuesta; si necesito plantillas, estos días, tiendo a ir con Django Templates, y si necesito una base de datos relacional, prefiero escribir SQL directamente (¡aunque SQLAlchemy tiene sus puntos fuertes! -).

Pero lo bueno de usar componentes modulares en lugar de marcos integrados es que puede cambiar todas y cada una de estas opciones (¡y mezclar y combinar a voluntad según sus necesidades, preferencias y gustos exactos!) .

Answer 8

Usted ha anotado ningún requisito, ha anotado las decisiones tecnológicas . Eso es algo totalmente diferente. ¿Qué quieres lograr? Entonces podríamos ayudarle con cómo para lograrlos.

Answer 9

darle una oportunidad a Spring 3.0: See this post

Answer 10

En promedio, el más completo y útil el marco web es el más limitante que es cuando se trata de hacer las cosas de otra manera que la forma en que el framework de desarrollo web piensa que es La manera correcta. Algunos frameworks web intentan ser muy útiles y no restrictivos, y algunos lo hacen mejor que otros.

Y la recomendación general es: No pelee con el marco. Perderás. Por lo tanto, es importante elegir un marco que lo ayude con las cosas que desea hacer, pero que no impone ninguna otra cosa. Para su caso de servicio web, esto no debería ser un problema. Hay toneladas de frameworks web minimalistas, al menos en el mundo de Python (que es todo lo que me importa). Bobo, BFG, Pilones, Werkzeug, etc., etc. Nada de esto se interpondrá en tu camino.

Además, no olvide que a menudo puede utilizar varios marcos juntos haciéndolos funcionar uno al lado del otro. Especialmente usando técnicas como Dexterity/XDV. Plone.org, por ejemplo, es principalmente Plon (duh), un excelente sistema de gestión de contenidos, pero extremadamente restrictivo si quieres hacer otra cosa. Entonces, parte del sitio es Trac, el excelente rastreador de errores de Python. Está todo integrado para que luzca igual.

Answer 11

Si sabe que no va a utilizar un ORM o crea una interfaz de usuario, entonces, en primer lugar, ha eliminado aproximadamente el 90% de lo que usaría un marco de aplicación web. Si nos fijamos en el conjunto de características de Django, por ejemplo: ¿qué partes de eso usarías para implementar un servicio web que no podrías obtener usando algo mucho más simple, como Werkzeug o CherryPy? Las diferencias principales entre construir un servicio web y construir cualquier caja negra antigua que tome entrada y produzca son las diversas limitaciones técnicas impuestas por la API que se basa en HTTP, el problema de la apatridia y el problema de la idempotencia. Un marco de aplicación web le dará un poco de ayuda con esos problemas, pero no mucho.