10. Web Server

I capitoli sul networking hanno portato la cam in rete e le hanno fornito i socket per comunicare (Networking). E adesso? La maggior parte delle applicazioni per camera si riduce a due cose – esporre al mondo ciò che la cam vede e reagire a ciò che gli altri dispositivi in rete dicono. HTTP è il modo in cui avviene questa conversazione, e funziona in entrambe le direzioni:

  • Come server, la cam risponde alle richieste di telefoni, browser e altri dispositivi sulla rete. Il framework microdot è il server della cam.

  • Come client, la cam si rivolge a servizi cloud per caricare, recuperare o coordinare. Il modulo requests è il client della cam.

Nel corso dei prossimi 14 capitoli costruiremo un’unica applicazione per camera funzionante che mette in pratica entrambi.

Una cam con trigger di movimento da giardino sta su un palo nel cortile, osserva ciò che accade e avvisa il proprietario di qualsiasi cosa interessante. Faremo crescere la cam da un server a una sola route del tipo «sono viva» fino a un prodotto distribuibile: anteprima live sul telefono del proprietario, una dashboard con uno slider per la soglia e un registro degli eventi, notifiche push quando scatta il movimento, login, HTTPS e un archivio cloud di ogni frame attivato.

Ogni capitolo aggiunge una funzionalità. Gli esempi di codice presuppongono che i capitoli precedenti siano già in piedi – non incolliamo di nuovo l’intero script ogni volta.

Il telefono o il laptop comunica con la cam su HTTPS per la dashboard, gli eventi SSE e i comandi WebSocket; la cam comunica verso l'esterno con un archivio cloud tramite HTTPS POST.