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 鈥榖acking 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 鈥榖acking 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鈥橲.
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.