Flujo de trabajo típico de AngularJS y estructura del proyecto (con Python Flask)

Soy bastante nuevo en este frenesí del framework MV * del lado del cliente. No tiene que ser AngularJS, pero lo elegí porque me parece más natural que Knockout, Ember o Backbone. De todos modos, ¿cómo es el flujo de trabajo? ¿Comienzan las personas desarrollando una aplicación del lado del cliente en AngularJS y luego conectando el back-end?

¿O al revés construyendo primero el back-end en Django, Flask, Rails y luego adjuntándole una aplicación AngularJS? ¿Hay una forma "correcta" de hacerlo, o es solo una preferencia personal al final?

Tampoco estoy seguro de si estructurar mi proyecto de acuerdo con el Flask o AngularJS? prácticas comunitarias.

Por ejemplo, la aplicación minitwit de Flask está estructurada así:

minitwit
|-- minitwit.py
|-- static
   |-- css, js, images, etc...
`-- templates
   |-- html files and base layout

La aplicación tutorial AngularJS está estructurada así:

angular-phonecat
|-- app
    `-- css
    `-- img
    `-- js
    `-- lib
    `-- partials
    `-- index.html
|-- scripts
 `-- node.js server and test server files

Podría imaginar una aplicación Flask por sí misma, y ​​es bastante fácil ver la aplicación AngularJS como ToDo List por sí misma, pero cuando se trata de usar ambas tecnologías, no entiendo cómo funcionan juntas. Casi parece que no necesito un marco web del lado del servidor cuando ya tienes AngularJS, un simple servidor web Python será suficiente. En la aplicación de tareas de AngularJS, por ejemplo, usan MongoLab para comunicarse con la base de datos con Restful API. No era necesario tener un marco web en el back-end.

Tal vez estoy terriblemente confundido, y AngularJS no es más que una elegante biblioteca jQuery, por lo que debería usar como usaría jQuery en mis proyectos de Flask (suponiendo que cambie la sintaxis de la plantilla AngularJS a algo que no entre en conflicto con Jinja2). Espero que mis preguntas tengan sentido. Principalmente trabajo en el back-end y este marco del lado del cliente es un territorio desconocido para mí.

Comenzaría organizando la aplicación Flask en la estructura estándar de la siguiente manera:

app
|-- app.py
|-- static
    |-- css
    |-- img
    |-- js
|-- templates

Y como mencionó btford, si está haciendo una aplicación Angular, querrá enfocarse en usar plantillas angulares del lado del cliente y mantenerse alejado de las plantillas del lado del servidor. El uso de render_template ('index.html') hará que Flask interprete sus plantillas angulares como plantillas jinja, por lo que no se renderizarán correctamente. En cambio, querrás hacer lo siguiente:

@app.route("/")
def index():
    return send_file('templates/index.html')

Tenga en cuenta que el uso de send_file () significa que los archivos se almacenarán en caché, por lo que es posible que desee utilizar make_response (), al menos para el desarrollo:

    return make_response(open('templates/index.html').read())

Luego, desarrolle la parte AngularJS de su aplicación, modificando la estructura de la aplicación para que se vea así:

app
|-- app.py
|-- static
    |-- css
    |-- img
    |-- js
        |-- app.js, controllers.js, etc.
    |-- lib
        |-- angular
            |-- angular.js, etc.
    |-- partials
|-- templates
    |-- index.html

Asegúrese de que su index.html incluya AngularJS, así como cualquier otro archivo:

<script src="static/lib/angular/angular.js"></script>

En este punto, aún no ha construido su API RESTful, por lo que puede hacer que sus controladores js devuelvan datos de muestra predefinidos (solo una configuración temporal). Cuando esté listo, implemente la API RESTful y conéctela a su aplicación angular con angular-resource.js.

EDITAR: armé una plantilla de aplicación que, aunque un poco más compleja que la que describí anteriormente, ilustra cómo se puede construir una aplicación con AngularJS + Flask, completa con la comunicación entre AngularJS y una API simple de Flask. Aquí está si quieres echarle un vistazo: https://github.com/rxl/angular-flask

Puedes comenzar en cualquier extremo.

Tiene razón en que probablemente no necesite un marco completo del lado del servidor con AngularJS. Por lo general, es mejor servir archivos estáticos HTML / CSS / JavaScript y proporcionar una API RESTful para que el cliente la consuma. Una cosa que probablemente debería evitar es mezclar plantillas del lado del servidor con plantillas del lado del cliente de AngularJS.

Si desea usar Flask para servir sus archivos (puede ser excesivo, pero puede usarlo de todos modos), debe copiar el contenido de "app" de "angular-phonecat" en la carpeta "estática" de "minitwit".

AngularJS está más dirigido a aplicaciones similares a AJAX, mientras que el matraz le brinda la capacidad de hacer tanto las aplicaciones web de estilo antiguo como crear API RESTful. Hay ventajas y desventajas en cada enfoque, por lo que realmente depende de lo que desee hacer. Si me da algunas ideas, podría hacer más recomendaciones.

Este video oficial de Jetbrains PyCharm de John Lindquist (angular.js y jetbrains guru) es un buen punto de partida, ya que muestra la interacción del servicio web, la base de datos y angular.js dentro del matraz.

Construye un clon pinterest con frasco, sqlalchemy, frasco inquieto y angular.js en menos de 25 minutos.

Disfruta: http://www.youtube.com/watch?v=2geC50roans

editar : la nueva guía de estilo Angular2 sugiere una estructura similar, si no la misma, con mucho más detalle.

La respuesta a continuación apunta a proyectos a gran escala. He pasado bastante tiempo pensando y experimentando con varios enfoques para poder combinar un marco del lado del servidor (Flask con App Engine en mi caso) para la funcionalidad de back-end junto con un marco del lado del cliente como Angular. Ambas respuestas son muy buenas, pero me gustaría sugerir un enfoque ligeramente diferente que (al menos en mi opinión) se amplía de una manera más humana.

Cuando implementa un ejemplo TODO, las cosas son bastante sencillas. Sin embargo, cuando comienza a agregar funcionalidad y pequeños detalles agradables para mejorar la experiencia del usuario, no es difícil perderse en el caos de estilos, javascript, etc.

Mi aplicación comenzó a crecer bastante, así que tuve que dar un paso atrás y repensar. Inicialmente, un enfoque como el sugerido anteriormente funcionaría, al tener todos los estilos juntos y todos JavaScript juntos, pero no es modular y no es fácil de mantener.

¿Qué pasa si organizamos el código del cliente por característica y no por tipo de archivo:

app
|-- server
    |-- controllers
        |-- app.py
    |-- models
        |-- model.py
    |-- templates
        |-- index.html
|-- static
    |-- img
    |-- client
        |-- app.js
        |-- main_style.css
        |-- foo_feature
            |-- controller.js
            |-- directive.js
            |-- service.js
            |-- style.css
            |-- html_file.tpl.html
        |-- bar_feature
            |-- controller.js
            |-- directive.js
            |-- service.js
            |-- style.css
            |-- html_file.tpl.html
    |-- lib
        |-- jquery.js
        |-- angular.js
        |-- ...

y así.

Si lo construimos así, podemos envolver cada directorio nuestro en un módulo angular. Y hemos dividido nuestros archivos de una manera agradable para que no tengamos que pasar por un código irrelevante cuando trabajamos con una característica específica.

Un corredor de tareas como Grunt configurado correctamente, podrá encontrar y concatenar y compilar sus archivos sin mucha molestia.

Otra opción es separar completamente los dos.

proyecto
| - servidor
| - cliente

Los archivos relacionados con el matraz se encuentran en la carpeta del servidor y los archivos relacionados con angularjs se encuentran en la carpeta del cliente. De esta manera, será más fácil cambiar el backend o el front-end. Por ejemplo, es posible que desee cambiar de Flask a Django o AngularJS a ReactJS en el futuro.

Creo que es importante determinar en qué extremo desea realizar la mayor parte del procesamiento de datos: front-end o back-end.
Si es frontal, entonces siga el flujo de trabajo angular, lo que significa que su aplicación de matraz funcionará más como una API donde terminará una extensión como matraz de descanso.

Pero si, como yo, está haciendo la mayor parte del trabajo en el backend, vaya con la estructura del matraz y solo enchufe angular (o en mi caso vue.js) para construir el extremo frontal (cuando sea necesario)