Bienvenida

1

Todo lo que aprenderás sobre Django

Cimientos

2

Arquitectura de una aplicación

3

The Twelve-Factor App

4

Codebase: Settings modular

5

Codebase: Dependencias y archivos de docker

6

Codebase: Docker

7

Setups alternativos

Modelos

8

Herencia de modelos

9

Proxy models

10

App de usuarios

11

Organizando modelos en un paquete de Django

12

Creando el modelo de perfil de usuario

13

Solución del reto: arreglando la migración de users a user

14

Aplicación y modelo de círculos

15

Migraciones y admin de círculos

Introducción a Django REST Framework

16

Aprende cómo construir tu propio API con Django Rest Framework

17

Vistas, URLs y Parsers de DRF

18

Serializers

19

Buenas prácticas para el diseño de un API REST

20

Request, response, renderers y parsers

Real DRF

21

Autenticación y tipos de autenticación

22

APIView

23

Creando el token de autorización

24

User sign up

25

Limitar login a usuarios con cuenta verificada

26

Configurar envío de email

27

Instalar PyJWT y generar tokens

28

Verificar cuenta usando JWT

29

Actualizar modelo de circle (membership)

30

Crear CircleViewSet

31

Añadiendo autorización y paginación

32

Creación de circulos

33

Update de círculo, custom permissions y DRF Mixins

34

Migración de vistas de usuarios a ViewSets

35

Detalle de usuario

36

Update profile data

37

List members - Recursos anidado

38

Retrieve destroy member

39

Modelo de invitaciones y manager

40

Obtener invitaciones de un miembro

41

Unirse a grupo

42

Filtrado

43

App de rides y modelos

44

Implementar la publicación de un ride

45

Validación de campos de un serializer

46

Listado de rides

47

Editar un ride

48

Unirse a viaje

49

Terminar viaje

50

Calificar viaje

Tareas asíncronas

51

¿Qué es Celery?

52

Creando tarea asíncrona

53

Creando tarea periódica

Testing

54

Python unittest y Django TestCase

55

DRF APITestCase

Django Admin

56

Admin actions: Modificar datos de un query

57

Admin actions: Regresando una respuesta HTTP

Deployment

58

Instalación de la aplicación

59

Configuración del dominio en Mailgun y del Bucket en Amazon S3

60

Configuración final de Docker Container usando Supervisor

61

Tutorial de despliegue de la aplicación

62

Futuros pasos y cierre del curso

The Twelve-Factor App

3/62
Recursos

Algunos principios de Twelve Factor app

  • Formas declarativas de configuración
  • Un contrato claro con el OS
  • Listas para lanzar
  • Minimizar la diferencia entre entornos
  • Fácil de escalar

Codebase: Se refiere a que nuestra app siempre debe estar trackeada por un sistema de control de versiones como Git, Mercurial, etc. Una sola fuente de verdad.

Dependencias: Una 12 factor app nunca debe depender de la existencia implícita de nuestro OS, siempre se declaran explícitamente qué dependencias usa el proyecto y se encarga de que estas no se filtren. Dependency Isolation.

Configuración: Acá nos referimos a algo que va a cambiar durante entornos.

Backing services: Estos pueden ser conectados y desconectados a voluntad. Es cualquier servicio que nuestra aplicación puede consumir a través de la red como Base de Datos, Mensajería y Cola, Envío de Emails o Caché.

Build, release, run: Separa estrictamente las etapas de construcción y las de ejecución. Build es convertir nuestro código fuente en un paquete.Release es la etapa donde agregamos a nuestro paquete cosas de configuración como variables de entorno y Run donde corremos la aplicación en el entorno correspondiente. Las etapas no se pueden mezclar.

Procesos: En el caso más complejo tenemos muchos procesos corriendo como Celery y Redis, en esta parte los procesos son stateless y no comparten nada. Cualquier dato que necesite persistir en memoria o en disco duro tiene que almacenarse en un backing services,

Dev/prod parity: Reducir la diferencia entre entornos para reducir tiempo entre deploys y las personas involucradas sean las mismas que puedan hacer el deploy

Admin processes: Tratar los procesos administrativos como una cosa diferente, no deben estar con la app.

Aportes 27

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Les dejo mi aporte. Recomendaciones y aclaraciones, son bienvenidas.
7 Port binding
La Twelve-Factor app es completamente autónoma, cuando el usuario se conecta a la app via hostname, una capa de enroutamiento se encarga de conectar al puerto conveniente para mirar el contenido de la app, lo que un developer ve como http://localhost:5000/, el usuario lo ve como web-app.com.

8 concurrency
El developer debe poder arquitectar su app manejando cada uno de sus procesos como un trabajo por separado. Esto debe de permitir que la app escale sin problemas horizontalmente.

9 Disposability
Los procesos son desechables, es decir, se deben de o parar en cuanto se le dé dicha indicación y lo deben de hacer, si se inicia: rápidamente, si se detiene: elegantemente. Esto facilita el escalamiento, el rápido despliegue de los cambios en el código y la configuración y la robustez del despliegue de ejecución

11 Logs
Un log es un output que indica cómo se comporta la aplicación.
Una Twelve-Factor app no se debe de preocupar por dónde manda estos logs o dónde los va a guardar, simplemente los refleja en la stdout del dispositivo del developer para que este lo analice cuando sea conveniente.

Espero sea un buen aporte y les ayude. Agradezco si tienen algo adicional que agregar. 😃

Yo lo entiendo asi:

  1. Codebase
    Esto significa que tengo que poder hacer un pull de todo mi código fuente.

  2. Dependencies
    Debe de haber una manera de tener todas mis dependencias en un solo lugar.
    Entiendo que algo como el requirements.txt de python puede ser una forma de lograr esto.

  3. ** Config **
    Este archivo o archivos debe tener la configuración de mi ambiente de ejecución, ya sea ambiente de desarrollo de pruebas o de producción. Lo que debería de cambiar en configuración del proyecto debería de estar en este archivo o archivos.

  4. Backing services
    Yo debo de ser capaz de trabajar con mis ‘backing services’ como base de datos o sistema de colas separadamente de mi proyecto o mejor dicho deben de ser intercambiables. En este caso, yo considero que tener en un archivo de config o equivalente la configuración de la base de datos y hacer los queries a esta utilizando un ORM es una forma de conseguir este paso, al menos en bases de datos, al menos asi lo entiendo, por favor corríjame si me equivoco.

  5. **Build, release and run **
    Un delivery pipeline deberia de tener estos estados por separado. Esto lo entiendo en concepto, me parece un poco confuso en la práctica porque el código compilado que he tenido la oportunidad de trabajar todo se hacia automáticamente.

  6. ** Processes**
    La data que utilizan mis procesos debería de venir de una fuente externa como una base de datos o un sistema de almacenamiento y no asumir que esa data esta en memoria.

  7. **Port binding **
    Los procesos deberían de ser auto contenidos, es decir que mi aplicación, servicios, o procesos deberían de poder comunicarse con otras aplicaciones, procesos o servicios auto contenidos que expongan su contenido a travez de un puerto. Eso para mi fue un poco difícil de entender, pero es como cuando alguien se conecta a un servidor de apache, uno se conecta a travez de un puerto abierto de apache, o la conexión a mysql (que regularmente es 3306 ) es decir que yo se que puedo conectarme a mi base de datos en el purto 3306 y que pase adentro, no tengo ni idea, solo se que puedo comunicarme con mi base de datos a travez de ese puerto y punto.

  8. ** Concurrency **
    Escalabilidad horizontal. Yo puedo escalar levantando otro contenedor u otra instancia y esto no debe de afectar al resto de procesos.

9.Disposability
La aplicación debe de poder apagarse y apagar todos sus recursos así como encenderse y encender todos sus recursos.

  1. ** Dev / prod parity **
    Los ambientes de desarrollo y producción deben ser lo más similar posible. Esto es fácil de lograr utilizando cosas como Vagrant o Docker.

  2. ** Logs **
    Los logs deben de guardarse en algun lugar central.

  3. **Admin processes **
    Los procesos de administración o de administrador deberían de ejecutarse independientemente de los demás procesos.
    Los procesos administrativos no son parte de la applicación.

Es muy bueno tomar los cursos dos veces. A veces la primera vez no entendés todo tan claro, luego la segunda, cuando ya tuviste algo de práctica, el profe dice algo y te estalla la cabeza porque entendés muy bien a qué quiso referirse.

Les comparto un video del un meetup de Python Argentina sobre Twelve Facttor.
Video

Port binding: Publicar servicios mediante asignación de puertos - Entiendo que podemos exponer servicios en puertos específicos donde se podrá interactuar con servicios con diferentes protocolos. Si entendí bien?

el principio VII es medio abstracto la mejor manera de entenderlo es traduciendo la cuestion:

La aplicación de doce factores es completamente autónoma y no se basa en la inyección en tiempo de ejecución de un servidor web en el entorno de ejecución para crear un servicio orientado a la web. La aplicación web exporta HTTP como un servicio al vincularse a un puerto y escuchar las solicitudes que ingresan en ese puerto.

En un entorno de desarrollo local, el desarrollador visita una URL de servicio como http: // localhost: 5000 / para acceder al servicio exportado por su aplicación. En la implementación, una capa de enrutamiento maneja las solicitudes de enrutamiento desde un nombre de host de cara al público a los procesos web vinculados a puertos.

Ok, la página 12-factor ya esta en los bookmarks, la verdad que son items fundamentales para proyectos serios.

En codebase también se refiere a que se pueden tener múltiples deploys con el mismo codebase aunque cada deploy puede tener diferentes versiones. Por ejemplo staging puede tener commits que no estén en producción.

Estuve leyendo el # 8 Concurrency y no me cuadra del todo aún… Alguien con un ejemplo que me ayude a clarificar bien este principio?

The Twelve Factors
I. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production as similar as possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes

Comenzando con el numero 12, me parece buena practica usar gestores de logs, por ejemplo pappertrail o stackDriver si tener tu all en google

Factor VII

The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.

Entiendo que las aplicaciones deben enlazar sus servicios directamente con puertos, tales como el 80/443 para el http, y recibir requests y servir respuestas a través de los mismos.

Una aplicación en PHP entonces no puede cumplir con este factor?

Buenos datos, todos los dias se aprende algo bueno.

Twelve Factors

principios de apps

7 port binding:
Debe ser siempre independiente de aplicaciones adicionales, Cada función
debería ser su propio proceso en completo aislamiento.
Nos permiten esperar peticiones o solicitudes en un puerto definido

8 Concurrency:

El escalado de aplicaciones debe ser fluido una vez que este en la nube,
tanto que puede ejecutar procesos en simultaneidad sin generar esfuerzo a
la nube.

9 Disposability:
La aplicación puede morir en cualquier momento, pero no afectará al
usuario. Puede ser reemplazada por otras aplicaciones, de tal manera que
vuelva a funcionar correctamente.

The Twelve-Factor App

Son doce principios que deben ser tomados en cuenta

  1. Codebase:
    Esto significa que debo poder hacer un pull de todo mi código fuente, centrarse en el uso de una rama master,

  2. Dependencies:

    Debe de haber una manera de tener todas mis dependencias en un solo lugar. Entiendo que algo como el requirements.txt de python puede ser una forma de lograr esto. Nunca depende de la existencia de una dependencia implicita en nuestro SO. Siempre debe de declarse explicitamente cuales son las dependencias necesarias para el funcionamiento del proyecto

  3. Configuration:

    Este archivo o archivos debe tener la configuración de mi ambiente de ejecución, ya sea ambiente de desarrollo de pruebas o de producción. Lo que debería de cambiar en configuración del proyecto debería de estar en este archivo o archivos.

  4. Backing Services

    Cualquier servicio que nuestra aplicación pueda consumir a través de la red. Yo debo de ser capaz de trabajar con mis ‘backing services’ como base de datos o sistema de colas separadamente de mi proyecto o mejor dicho deben de ser intercambiables. En este caso, yo considero que tener en un archivo de config o equivalente la configuración de la base de datos y hacer los queries a esta utilizando un ORM es una forma de conseguir este paso, al menos en bases de datos, al menos asi lo entiendo, por favor corríjame si me equivoco.

  5. Build, release, run

    Sepera ESTRICTAMENTE las etapas de construcción y las de ejecución. En Build nos referimos a convertir nuestros código fuente a un paquete, por ejemplo el compilado. Release, es la etapa donde nosotros incluimos en el paquete cosas de configuración como las variables de entorno. Y Run, es donde ya ejecutamos la aplicación en el entorno donde se debe ejecutar.

  6. Processes
    La data que utilizan mis procesos debería de venir de una fuente externa como una base de datos o un sistema de almacenamiento y no asumir que esa data esta en memoria. Todos los procesos deben ser State-Less y no compartir nada, un proceso no puede depender de que un dato que esta en memoria este siempre allí

  7. Port Binding

    La Twelve-Factor app es completamente autónoma, cuando el usuario se conecta a la app vía hostname, una capa de enroutamiento se encarga de conectar al puerto conveniente para mirar el contenido de la app, lo que un developer ve como localhost:5000, el usuario lo ve como web-app. com

  8. Concurrency

    Escalabilidad horizontal. Yo puedo escalar levantando otro contenedor u otra instancia y esto no debe de afectar al resto de procesos.

  9. Disposability

    La aplicación debe de poder apagarse y apagar todos sus recursos así como encenderse y encender todos sus recursos.

  10. Dev / Prod parity

    Reducir la diferencia entre entornos, producción y desarrollo debe ser casi nula, que las mismas personas que hacen el código y las funciones deben ser capaces de hacer el Deployment

  11. Logs

    Los logs deben de guardarse en algun lugar central.

  12. Admin Processes

    Deben tratarse los procesos administrativos como algo totalmente ajeno a la app y no debe estar con la app, como por ejemplo la limpieza de datos o los respaldos de la app. Estos procesos deben realizarse de forma completamente independiente

  1. Codebase: siempre se traquea la app en un sistema de control de versiones como una única fuente de verdad.
  2. Dependencias: nunca depende de la existencia implícita de dependencias en SO. Siempre se debe de declarar explícitamente las dependencias y deben de estar isoladas. Debe de haber dependency isolation (ambiente virtual o contenedores)
  3. Configuración: algo que cambiará dependiendo del entorno. Se debe de versionar las configuraciones dependiendo de si es entorno local, de pruebas, producción, etc
  4. Backing services: Un backing service es un servicio que la aplicación puede consumir a través de la red, como una base de datos o un servicio de mensajería. Los backing services como recursos conectables (debido a cambios de proveedores por ejemplo), estos pueden ser conectados y desconectados a voluntad
  5. Build, release, run: separa estrictamente las etapas de construcción y las de ejecución.
    • Build: construir código fuente en un paquete, si es compilable
    • Release: incluimos en el paquete variables de configuración
    • Run: corremos el paquete en el respectivo entorno donde se va a ejecutar
  6. Procesos: ejecuta la app como uno o más procesos sin estado. Puede ser uno o múltiples procesos dentro de una app. Se refiere a que ninguno de los procesos comparten algo, deben de asumir que no estará la segunda vez que lo busquen y deben de usar los backing service
  7. Port binding: Procesos deben de ser autocontenidos y capaces de exponer su contenido a través de un puerto, de forma tal que la capa de enrutamiento permite que el usuario vea el hostname que se le ha dado a la app solamente
  8. Concurrency: Cada uno de los procesos debe ser capaz de trabajar por separado para que escale horizontalmente
  9. Disposability: Los procesos deben ser desechables, es decir, deben de parar cuando se les indique para que la app puede apagarse y prenderse junto a todos sus recursos. Esto facilita el escalamiento, despliegue y configuración del proyecto
  10. Dev/prod parity: reducir la diferencia entre entornos, ser casi nula la diferencia entre los ambientes de producción y desarrollo. Objetivo es reducir tiempos entre deploys, que el desarrollador pueda hacerlo por su cuenta. Esto se puede lograr implementando contenedores
  11. Logs: Output que indica el comportamiento de la aplicación
  12. Admin processes: tratar los procesos administrativos de forma que no tenga que ver con la app, como es el backup de la base de datos

VII. Port binding: Este principio significa qué la aplicación web maneja (escucha y responde) las peticiones HTTP a travez de puertos específicos en lugar de URL’S.
VIII. Concurrency: Este principio significa que cada servicio web tiene un único “processes are a first class citizen” proceso dentro del OS, en el caso de procesos Linux/Unix corren como Daemos (demonios).

gracias por la explicacion

Concurrencia: escalar con el modelo de procesos. Entiendo que podemos manejar servicios asignándolos a diferentes procesos, o distribuyendo la ejecución de los servicios, así podemos manejar la carga según el servicio.

En que clase del curso básico de Django menciona lo que son Formas declarativas de configuración, y contrato con el OS, me gustaría repasar estos conceptos para entender mejor.

Primero decidí tomar el curso de Docker para entender todo mejor, no sé si fue una buena decisión pero ya lo veré

Mi aporte a la clase es la siguiente:

**Port Binding **: Es simplemente un enlance o redirecionamiento donde un puerto de entrada apunta a otro puerto puede ser el mismo, diferente, publico, privado, Es muy usado en los dockers

Concurrency: Es la capacidad de poder tener corriendo multiples procesos en paralelo cada uno de estos podrian estar realizando diferentes tareas

Disposability: Como su nombre lo indica es la capacidad de desechar algún proceso sin afectar al resto del sistema

Logs: Es una bitacora donde se registra información relevante previo, durante y posterior a la ejecución del sistema, Es usualmente utilizado para registrar, errores, accesos y auditorias en general.

Tarea:
7. Port binding: las aplicaciones son auto-contenidas, por lo que no dependen de un servidor web que esté ejecutandose (como Apache para PHP, o Tomcat para Java), sino que se le asigna un puerto y escucha las peticiones a través de el.
8. Concurrency: una aplicación debe distribuir el peso de la ejecución asignando tipos de trabajos a tipos de procesos.
9. Disposability: una aplicación minimiza el tiempo de arranque usando procesos desechables (pueden inicializarse y finalizarse cuando se necesite)
11. Logs: la aplicación no debe preocuparse por las salidas que genere. Los procesos escriben a la salida estandar y el desarrollador debería poder ver los logs en su terminal. En producción, el SO se encarga de guardar los logs.

  1. Port binding
    Mediante el uso de puertos se permite la comunicación con el servicio

  2. Concurrency
    Cada proceso debe ser capaz de trabajar independientemente de la cantidad de otros procesos activos

Cuando empiezas a leer este tipo de documentos y explorar estas prácticas (Aunque al principio no las entiendas) empiezas a hacer el click de que ser Backend Developer es muchísimo más que sólo escribir código.