Angular para Djangonautas

Archivada en Desarrollo

Angular para Djangonautas

Serie “Angular para Djangonautas”

Este es el artículo número 1 de la serie “Angular para Djangonautas”:

  1. Angular para Djangonautas
  2. Acreditación y Autorización

La verdad es que no encontré mucha información que me ayudará a comprender como funcionaba AngularJS. Tengo poca experiencia en JavaScript, así que cometí el error de evitar usarlo.

Qué es AngularJS

Es un marco de trabajo, como Django, pero para lo que se llama el frontend, es decir, para la parte que interactúa con el cliente. Está escrito en JavaScript y permite modificar la página web, el DOM para presentar y manipular información de forma muy eficiente.

La forma de usar las funciones de Angular es idéntica a la de Django: {{ }} por lo tanto hacen cortocircuito. Mi primera opción fue cambiar estos delimitadores en AngularJS para poder usar las plantillas de Django, pero después me di cuenta que es innecesario. AngularJS, desde el punto de vista de Django, se sirve como archivos estáticos.

Un proyecto aparte

Entender que AngularJS se debe tratar como estáticos es toral para un mejor manejo del framework.

De hecho, es incluso mejor manejar los proyectos por separado: por un lado la aplicación del lado de servidor con Django, es decir el backend y por otro la aplicación del lado del cliente, o sea, el frontend.

Una de las razones mas importantes para separar el backend de Django en un proyecto aparte es que este debe ser agnóstico, es decir, no debe estar programado para un frontend específico, sino para cualquiera.

Esto es así: Django ofrece una API, una interface programática de la aplicación para que cualquiera, literalmente cualquier frontend pueda interactuar con ella, consumirla.

Acostumbrado como estoy a usar siempre las plantillas de Django, este paradigma fue un cambio total.

La API de Django

Una interface programática de aplicaciones o API por sus siglas en inglés es como el menú de los restaurantes, expone a los clientes los productos que se pueden consumir. No te explica como los hacen, solo te muestran el resultado final.

Cuando escribimos una API en Django, debemos saber que estamos ofreciendo antes de poder servirlo. Generalmente son operaciones comunes (como en los restaurantes, la mayoría tienen un menú): las operaciones que llaman CRUD por sus siglas en inglés Create (crear), Read (leer), Update (actualizar) y Delete (borrar).

Para generar API, el protocolo más común es REST, un protocolo para realizar operaciones bien definidas sobre datos sin estado, donde cada mensaje tiene toda la información necesaria, incluyendo autenticación y autorización.

Para Django, el paquete mas común para crear API REST es Django REST Framework que de forma realmente muy simple permite crear APIs con todos los verbos que usa una API: GET, POST, PUT, DELETE, etc.

Esta API va en el servidor backend, por lo que en el frontend va otro servidor. De ahí que tener dos proyectos independientes tenga mucho sentido.

AngularJS y Django

AngularJS es un framework a toda regla, que funciona del lado del cliente. Junto a una aplicación de AngularJS, las plantillas de Django son verdaderamente tontas, y así deben de quedarse. Pero ¿para que seguir hablando de las plantillas de Django si ya no las volveremos a usar?

AngularJS permite traer los datos que sirve la API1 de Django y presentarlos de forma dinámica, con características que son al mismo tiempo simples pero muy potentes.

Pero funcionan de forma independiente de Django. Así como Django puede crear una API sin importar quién la consuma, así también AngularJS puede consumir APIs sin importar quien la sirva. Un argumento más para separar los proyectos.

En esta serie, intentaré registrar mis intentos por crear una aplicación con AngularJS y Django. Estén pendientes.


  1. En el argot se dice “consumir”

Javier Sanchez Toledano

Soy programador en Django+Python y WordPress. Auditor líder certificado en la norma ISO 9001:2008. Fotógrafo aficionado.
Redes Sociales:

Tlaxcala, México

Comentarios