Les webinaires et autres conférences en ligne sont de plus en plus nombreux, particulièrement depuis le début du confinement. Généralement organisés sur des logiciels de visioconférences comme Zoom, nous souhaitions nous démarquer en proposant un format plus proche d’une conférence, un peu à la façon de TED (oui, sacrée ambition !) : un speaker mis en valeur, traité comme un invité de marque, dont la conférence pourrait être visionnée par plusieurs centaines de participants en même temps.

Cela écarte donc d’office tous les logiciels de visioconférences qui sont limités dans leur nombre de participants et ne mettent pas un participant particulièrement en valeur. Vers quoi se tourner alors ? Il se trouve qu’un secteur est particulièrement en avance sur ces questions de diffusion live : le jeu-vidéo. En effet, des plateformes comme Twitch accueillent chaque jour des millions de spectateurs, analysant et applaudissant les *skills* des joueurs les plus en vogue sur Fortnite, League of Legends ou encore Overwatch.

Face à ce marché en pleine expansion, de nombreuses entreprises se sont lancées sur ce créneau, proposant des technologies et logiciels très accessibles pour pouvoir lancer son propre stream de joueur. Une aubaine pour BeeMyDesk !

## Choix de la plateforme de diffusion

Plusieurs plateformes proposent aujourd’hui de diffuser de la vidéo en direct. Nous avons éliminé d’office **Twitch**, qui est orienté essentiellement vers le jeu-vidéo ainsi que **Facebook et Instagram**, pas suffisamment business. **LinkedIn** est actuellement en train de déployer sa solution petit à petit, mais nous n’avons pas encore la chance d’être sélectionnés.

Notre choix s’est donc naturellement porté sur **YouTube** : un acteur majeur, connu du grand public et qui ne nécessite pas de compte pour regarder les vidéos. De plus, il est possible de proposer les replays immédiatement après la fin de la diffusion, directement sur la chaine.

## Logiciel de streaming

Une fois la plateforme sélectionnée, il faut ensuite s’intéresser au logiciel pour produire le contenu en lui-même. On parle d’**encodeur logiciel**. YouTube propose bien un outil intégré, mais il se cantonne à diffuser la webcam, ce qui est largement insuffisant pour notre besoin. La contrainte dans notre cas est qu’il nous fallait un logiciel capable d’intégrer un intervenant lui-même à distance.

On peut distinguer deux catégories de logiciels : les **logiciels traditionnels** à installer sur son ordinateur ou les **services en ligne** accessibles depuis le navigateur. La seconde catégorie est souvent plus moderne et plus accessible aux novices (ce que nous étions !), c’est pourquoi nous avons d’abord opté pour l’un de ces services en ligne.

### Premières armes avec un service en ligne

Nous en avons essayé deux : Stage Ten et Lightstream Studio. Tous deux étaient effectivement très facile d’accès et nous ont permis de lancer un live très rapidement sur YouTube. Après plusieurs essais, nous avons finalement adopté Lightstream Studio, car il permettait plus simplement d’intégrer le **partage d’écran**, indispensable pour nos speakers qui souhaitent passer un slide pendant leur intervention.

Nous avons réalisé nos trois premiers talks à l’aide de Lightstream Studio. Malheureusement, à l’issue de ceux-ci, le bilan n’était pas satisfaisant :

1. Les essais que nous faisions avec nos intervenants prenaient beaucoup de temps, car nous rencontrions beaucoup de problèmes de compatibilité en fonction du navigateur, du système d’exploitation, qui étaient parfois difficiles à résoudre.
2. Pendant le live, nous devions faire très attention à ce que nous faisions, au risque de lancer un autre plan ou de casser quelque chose. Globalement, l’équilibre semblait fragile et le moindre faux pas pouvait tout faire s’écrouler.
3. Pendant notre premier talk, nous n’avons malheureusement pas pu avoir le retour caméra de Jean Pouly, alors que cela fonctionnait parfaitement pendant les tests.
4. Lors de notre troisième talk avec Jean-François Fontana, le logiciel refusait carrément de lancer le live sur YouTube. Nous avons dû nous résoudre à passer sur un live Facebook en dernière minute.

Au bout de trois talks, nous avons donc décidé que cette solution ne répondait pas à nos attentes en termes de qualité et de fiabilité.

### On s’élève d’un cran !

Même si le bilan était un peu sombre, cela nous a tout de même permis de monter en compétences et d’avoir les idées plus claires sur notre organisation.

Premièrement, afin de ne pas perdre trop de temps en tests avec nos intervenants et limiter au maximum les problèmes techniques, il fallait que l’on puisse les contacter via des solutions connues de tous et éprouvées. En cherchant un peu, nous avons découvert l’existence de la **technologie NDI**. Pour simplifier, il s’agit d’un protocole de communication permettant de faire passer un flux audio/vidéo sur un réseau local. Et par chance, **Skype** est compatible NDI ; ce qui signifie qu’il offre un accès via ce protocole au flux vidéo d’un correspondant. Bien qu’un peu passé de mode face à Zoom ou Microsoft Teams, Skype reste un logiciel connu de tous et largement utilisé. Cela répondait donc à notre premier besoin. Premier critère donc : un **encodeur logiciel compatible NDI**.

La technique du NDI est la plus efficace pour intégrer un appel visioconférence dans un flux live. Si vous regardez l’émission de cuisine en direct de Cyril Lignac “Tous en cuisine” sur M6, vous remarquerez que les familles sont contactées via Skype 😉

Deuxièmement, nous avions besoin d’un logiciel robuste qui ne chamboule pas tout le live au moindre clic malheureux. Si en plus il permettait d’aller plus loin dans la mise en scène et les possibilités, c’était encore mieux.

Ces prérequis nous ont laissé trois choix : Open Broadcaster Software, XSplit Broadcaster et Wirecast. Utilisant un Mac, nous avons opté pour Wirecast.

Alors bien sûr, la prise en main a été un peu plus complexe mais, au bout de 25 talks, nous n’avons eu à subir aucun problème majeur. Les tests avec nos intervenants ont été réduits à moins de 5 minutes en moyenne avec une procédure simplissime : appelez-moi sur Skype. C’est tout.

## Matériel

La partie logicielle est essentielle, mais le matériel n’est pas à négliger. Il faut bien avoir en tête qu’**encoder un flux vidéo en direct** demande **beaucoup** de ressources. C’est pourquoi il est fortement recommandé d’avoir un ordinateur avec une carte graphique dédiée, qui est un composant conçu pour les tâches comme l’encodage vidéo. Sans cela, la vidéo risque d’être saccadée.

Deuxièmement, une connexion fibre (ou une très bonne VDSL) semble indispensable. Le problème de l’ADSL est que les vitesses en envoi de données (upload) sont extrêmement lentes. Or, ici, l’upload est essentiel puisque vous devez envoyer un flux vidéo en direct, dans une qualité correcte. Sans compter qu’il faut aussi prendre en compte la connexion Skype avec le speaker qui elle aussi va prendre sa part de bande passante.

Toujours concernant la connexion, privilégiez l’utilisation d’un câble Ethernet au lieu du Wi-Fi. Pourquoi ? Le Wi-Fi peut être perturbé par énormément de facteurs et votre débit peut varier considérablement d’un moment à l’autre. Si cela n’a pas d’incidence lors d’une utilisation internet “normale”, cela en a lors d’une diffusion live qui a besoin d’un lien stable. De plus, vous pourrez profiter de la véritable puissance de ce que votre connexion a à offrir. C’est particulièrement impressionnant sur une connexion fibre :

Test de connexion en Wi-Fi

![Vitesse connexion Wi-Fi](https://storage.googleapis.com/beemydesk-production-uploads/blog/e292fcd3-e0e4-47c1-bccf-c99b921bc156.png)

Test de connexion en câblé

![Vitesse connexion câblée](https://storage.googleapis.com/beemydesk-production-uploads/blog/e678d417-c7c9-48eb-96e6-3954680f1943.png)

À ce sujet, veillez également à la **catégorie de vos câbles Ethernet**. En effet, cette catégorie indique le débit maximum que le câble est capable de supporter. Pour une connexion 1 Gigabit, il faut des câbles de **catégorie 6 minimum** (même si a priori, c’est devenu la norme).

## On ne néglige pas les tests

Peut-être que cela va sembler évident, mais on ne le rappellera jamais assez : faites des tests !

Avant de lancer votre premier live, il est essentiel de bien tester votre logiciel, de voir l’effet de telle ou telle fonctionnalité. Mon conseil : avoir à côté de son ordinateur sa tablette ou son smartphone avec le live ouvert pour vérifier que le son et l’image fonctionnent correctement.

De la même manière, nous ne coupons jamais à un essai avec nos intervenants avant le jour de leur talk. Même si un appel Skype semble une formalité, l’expérience nous a montré que cela permet d’éviter beaucoup de problèmes le jour J (configuration du micro, positionnement dans la pièce, etc.). C’est encore plus vrai si l’intervenant souhaite partager son écran.

C’est là aussi que vous pourrez constater la qualité de connexion de votre interlocuteur et voir avec lui s’il est possible de l’améliorer si elle n’est pas satisfaisante : utilisation d’un câble (cf. le point précédent) ? Se rapprocher du Wi-Fi ? Utiliser une connexion 4G, parfois meilleure que de l’ADSL ?

## Les aléas du direct

Malgré le meilleur logiciel, le meilleur matériel et des tests exhaustifs, les professionnels du spectacle le savent : les problèmes arrivent. Vous rencontrerez *forcément* des problèmes à un moment ou un autre. Mais *show must go on* : soyez prêts à y faire face. C’est avec l’expérience que vous apprendrez à les gérer, mais voici quelques conseils tout de même :

* Restez calme. C’est facile à dire quand 200 personnes vous regardent et que tout s’écroule, mais c’est en gardant les idées claires que vous trouverez des solutions.
* Annoncez clairement à votre auditoire qu’il y a un problème. Inutile de cacher la vérité, les spectateurs ont probablement déjà remarqué que quelque chose cloche. D’une part, cela vous permettra de diminuer la pression et d’autre part cela rassurera le public que vous êtes conscient du problème et que vous allez faire quelque chose. Vous constaterez aussi que les gens sont extrêmement **bienveillants** et pardonneront ces problèmes techniques.
* À l’issue du live, réalisez un *post-mortem* : comprenez le problème, les raisons de sa provenance et notez les étapes qui vous ont permis de le résoudre.

Malgré tout, il y aura peut-être des fois où vous ne serez pas en mesure d’assurer votre direct. Personne n’est à l’abri d’un technicien opérateur peu scrupuleux qui débranche votre arrivée fibre optique dans les sous-sols de votre immeuble (oui, c’est du vécu !). Dans ces cas-là, il est encore une fois essentiel de **communiquer** avec votre public pour expliquer le problème et annoncer l’annulation.

## On air !

Voilà nos conseils pour mettre en place un live fonctionnel. Bien sûr, nous n’avons évoqué que la partie purement technique de l’opération. L’essentiel évidemment reste le contenu que vous allez proposer et le style que vous allez donner à votre émission. À vous de jouer !

Depuis un peu plus d'un mois, nous proposons les Talks par BeeMyDesk : un format de conférences en ligne qui permet à nos meilleurs experts de s'exprimer sur des thématiques ciblées pour les entrepreneurs. Comment avons-nous mis cela en place techniquement ? Quels logiciels, matériels utilisons-nous ? Nous vous proposons de le découvrir !

Mise en place d'un talk en live streaming

Nowadays, many solutions exist to help non-technical people automate those tasks like Zapier, Autopilot, and, of course, our friends at [Webmecanik](https://www.beemydesk.com/listing/e4dmthjxpz8-webmecanik).

Sometimes however, you may need very specific integrations that are not possible to do with those all-in-one solutions. Here is where developers come! But, as you may know, developers are lazy... And spin-up a project, test it and deploy it in production is a large work for just doing some clever automations.

But hey, we are in 2020 ; and serverless functions *are* a thing!

## What are serverless functions?

Let's start with a funny tweet from *@iamdevloper*:

> Serverless is server less in the same way a beef burger is vegetarian because you didn't personally see the cow being killed.
>
> — I Am Devloper (@iamdevloper) [May 1, 2019](https://twitter.com/iamdevloper/status/1123531597314019329?ref_src=twsrc%5Etfw)

Surely you understood from this joke that *serverless* is a misleading term. There are servers that run the code, just as a standard web application. So, why do we call it like this? The main motivation behind serverless functions is to focus only on the code and don't a care a second about the deployment, server provisioning or configuration.

The execution environment is entirely managed by the cloud provider: Amazon Web Services Lambda, Google Cloud Functions or Azure Functions. Just upload your source code to them and they will handle the deployment, and **scale automatically** if the load increases.

The cherry on the cake is that you only pay for the time the functions are running. So, if your automation only runs for a few seconds each day, you'll pay almost nothing.

The downside is that, generally, the runtime environment is constrained by the cloud provider. For example, Google Cloud Functions only supports NodeJS, Python or Go programs. Besides, you won't be able to install more system packages than the ones that are already installed. If you rely on a specific package or language, serverless functions won't work for you (in that case, containers seem more appropriate).

Another issue is vendor lock-in: each cloud provider has its own way of implementing serverless functions, so a code that will work in AWS Lambda likely won't work in Google Cloud Functions without a few adjustments.

In the case of marketing automation though, this is OK: generally, it just involves to get data from one service and put it in another. Each function will consist of a few lines of code and HTTP requests!

## React to events: webhooks to the rescue!

Now, let's say we want to add a contact to a mailing list whenever we create a new deal in our CRM. Without webhooks, the logic of our automation would look like this:

> *Automation:* Is there a new deal?
>
> *CRM:* No.
>
> *\[One minute later\]*
>
> *Automation:* Is there a new deal?
>
> *CRM:* No.
>
> *\[One minute later\]*
>
> *Automation:* Is there a new deal?
>
> *CRM:* No.
>
> *\[One minute later\]*
>
> *Automation:* Is there a new deal?
>
> *CRM:* Yes. The contact is **Arthur Pendagron**, its email is `arthur@camelot.bt`.
>
> *Automation:* Ok. Hey, mailing list! Add **Arthur Pendagron**, its email is `arthur@camelot.bt`.
>
> *Mailing list:* Ok, done.

As you see from this play, our automation would harass the CRM every minute to check if there is something new. Not very effective, and a total waste of resources.

Hopefully, we have something that could help: **webhooks**! They are a way of telling the service we want to get the data from to notify our automation when something happens. This way, our automation is only called when there is something to do. Let's see our new play with webhooks:

> *Automation:* Hey, CRM! Tell me when a new deal is created.
>
> *CRM:* Ok.
>
> *\[One eternity later\]*
>
> *CRM:* Hey, automation! A new deal was created. The contact is **Arthur Pendagron**, its email is `arthur@camelot.bt`.
>
> *Automation:* Ok. Hey, mailing list! Add **Arthur Pendagron**, its email is `arthur@camelot.bt`.
>
> *Mailing list:* Ok, done.

Far more efficient ⚡️ Funny things start when you trigger more events after reacting to other events. For example, we could set up a webhook that tell the email marketing service that a new contact was added in the mailing list, so that it could subscribe it to our e-mailing scenario!

![Mind-blowing](https://storage.googleapis.com/beemydesk-production-uploads/blog/ae0f8771-2e67-4c73-a794-a3327ce6fe68.gif)

## A bit of code

Now, how does it look like as actual code? Let's see a short example with Google Cloud Functions. We assume we have `pipedrive` (CRM) and `mailjet` (mailing service) clients at hand to help us:

```python
def pipedrive_to_mailjet(request: flask.Request) -> Tuple[str, int]:
    """Add new deals contacts to a Mailjet list."""
    webhook_meta = request.json["meta"]
    deal_id = webhook_meta["id"]
    deal = pipedrive.get_deal(deal_id)

    mailjet.add_contact(
        deal["person_id"]["email"][0]["value"],
        deal["person_id"]["name"],
        MAILJET_LIST_ID,
    )

    return ("", 201)
```

That's it! Get the data we were notified about, add it to another service. Deploy this code into production only requires one command:

```python
gcloud functions deploy pipedrive_to_mailjet --runtime python37 --trigger-http --allow-unauthenticated
```

After a few minutes, your automation will be ready with a nice HTTP endpoint that webhooks can actually call.

> You may have noticed the `--trigger-http` option. Actually, serverless functions can also be triggered by message queues. We'll talk about this in a future post.

## Automate the automation

![Inception](https://storage.googleapis.com/beemydesk-production-uploads/blog/2236f2ee-6991-4855-b376-1a43969d9315.gif)

Great! We've created a working automation: just a few lines of code, a simple deployment process, our dreams have come true. But remember: developers are *super* lazy.

If we have one automation, it's manageable. But usually, we have dozens of them. Each time we update the code, we would have to re-deploy them individually. That's boring. And error-prone!

The secret is to automate the deployments of our cloud functions. How? With Continuous Integration (CI)! This would require a dedicated article but, in a nutshell, those are technologies that provide an environment to script and execute actions whenever we add changes to the source code. Travis, GitLab CI or the youngest one, GitHub Actions, are some of them.

Generally, CI configuration files look like this:

```python
name: Build

on: [push, pull_request]

jobs:

  deploy:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/master'

    steps:
    - uses: actions/checkout@v1
    - name: Deploy pipedrive_to_mailjet
      uses: actions-hub/gcloud@275.0.0
      env:
        PROJECT_ID: ${{ secrets.GCLOUD_PROJECT_ID }}
        APPLICATION_CREDENTIALS: ${{ secrets.GOOGLE_APPLICATION_CREDENTIALS }}
      with:
        args: functions deploy pipedrive_to_mailjet --runtime python37 --trigger-http --allow-unauthenticated
```

You see that we have several steps, including one that execute the deploy command we saw earlier. If we have several automations to deploy, we just have to add it once in this configuration file. Now, each time we update the code, all automations will be automatically deployed.

## Conclusion

It's key to understand that, while automations are useful to help grow the business, they are not a core part of it. Hence, they should be written and deployed quickly so that developers can focus on the product. We saw that serverless functions and CI can greatly help in that matter.

At BeeMyDesk, we rely on those technologies to automate our CRM pipelines and customer success actions. It's important to us to keep up with the latest technologies and select the ones that will maximize the impact of the developers time on the business growth.

Marketing automation is an essential field for startups that need to react fact and focus on one thing: bring value to their clients. Repetitive and time-consuming tasks should be automated.

Serverless functions for marketing automation

![And that, kids, is how we started to do JS in backend ](https://storage.googleapis.com/beemydesk-production-uploads/blog/0ba59516-836d-487b-b5df-a824a024907b.jpg)

In recent months, other languages have started to catch up, implementing their own flavor of asynchronous style. Among them, of course, almighty Python (did I tell you I love Python?).

But before talking about the Python ecosystem, let's have a quick overview of how asynchronous programming actually works.

## How does asynchronous work?

The main motivation behind asynchronous style can be summed up in one simple statement: I/O is *painfully* slow. Reading from disk, networks requests, are **million times slower** than reading from RAM and processing instructions. Traditionally, in a synchronous program, you would do things like this:

```python
with open("file.txt") as f:
    data = f.read()
# The program will block here until the data has been read
print(data)
```

We see that the program will block until we retrieved the data from the disk ; and, as we said, this can be long. 99% percent of the execution time of the program is just to wait for the disk. It's usually not a big deal for simple scripts like this because you probably don't have to perform other operations meanwhile.

However, in more complex cases, this is a waste of resources that could have been used to perform **other things**. For example, think of a web server: if a first user makes a request that needs to block the program for 10 seconds, a second user making a request meanwhile would have to wait for the first one to finish before they get answered. We can simulate this behaviour quite easily with `flask` and `gunicorn`:

```python
# app.py
import time
from flask import Flask, request

app = Flask(__name__)

@app.route("/slow")
def slow():
    time.sleep(10)
    return "That was slow!"

@app.route("/fast")
def fast():
    return "That was fast!"
```

```bash
gunicorn --workers=1 app:app
```

If you hit the `/slow` endpoint and right after the the `/fast` endpoint, you'll see that you get the `/fast` response only when `/slow` has answered (after 10 seconds have passed).

![Waiting](https://storage.googleapis.com/beemydesk-production-uploads/blog/3421fa2d-f3f6-4f18-bd12-6a07380caad6.gif)To circumvent this, web servers usually spawn several threads (notice that we purposely started `gunicorn` with 1 worker) to be able to serve several users at a time, even if one request takes time to complete.

Solution adopted in asynchronous style doesn't involve threads, as they come with their own difficulties. Asynchronous frameworks implement a concept you probably have already heard of: **event loops**.

An event loop basically is the **conductor** of your program: at each iteration, it'll check for the completion of the tasks, yield the result if it's done, and go on to the next task. As a developer, your role is thus to send tasks to the event loop, knowing that you'll eventually get their result. Let's rebuild our previous example asynchronously with `fastapi` and `uvicorn`:

```python
# app.py
import asyncio
from fastapi import FastAPI

app = FastAPI()

@app.get("/slow")
async def slow():
    await asyncio.sleep(10)
    return "That was slow!"

@app.get("/fast")
async def fast():
    return "That was fast!"
```

```bash
uvicorn --workers=1 app:app
```

If you spawn the two requests at the same time like earlier, you'll see that `/fast` has answered immediately, not waiting for `/slow` to finish: the event loop put the `/slow` request in its queue, and moved on to the next one.

![Fast](https://storage.googleapis.com/beemydesk-production-uploads/blog/58f80c01-6e62-4092-abd7-27e909b9d1fa.gif)Notice that we traded `time.sleep` for `asyncio.sleep`. This is important because the event loop can only manage asynchronous tasks, that give back control to their caller. If you keep `time.sleep`, you'll experience the same behaviour as in the previous example: the thread will be blocked because it didn't yielded to the event loop.

Fine. But how does that solve our I/O problem? If we want to work with our event loop, I/O operations have to work asynchronously. To do this, we leverage an interesting feature of the operating systems: the `select` and `poll` calls (and derivatives). Those allow to ask the OS to ping us when something happened on a file or a socket (new data to read, ready to write data...). By using them, we allow the event loop to put the I/O calls in background and handle them once the OS notified us.

![Complicated](https://storage.googleapis.com/beemydesk-production-uploads/blog/eb7251d5-0643-490f-a073-0acfcac9429c.gif)That was a *very* simplified overview of how asynchronous is implemented. If you wish to have a more complete and correct view of what is going on under the hood, be sure to check the [references](https://www.beemydesk.com/blog/15589-asynchronous-programming-is-now-a-thing-in-python#references).

## The Python async ecosystem

`asyncio` module is included since Python 3.4 (2014!), and the `async/await` syntax since Python 3.5. Both have been greatly refined in 3.6 and 3.7; making the use of async style very easy. Logically, the ecosystem has grown since: there are now solid libraries ready for production use. We will just cite a few of them:

* [Starlette](https://www.starlette.io/), an impressively fast and clean framework to build web applications ;

* Its offspring, [FastAPI](https://fastapi.tiangolo.com/), which builds upon Starlette and [Pydantic](https://pydantic-docs.helpmanual.io/) to propose a very efficient developer experience to build API ;

* [HTTPX](https://github.com/encode/httpx), an async-compatible HTTP client with a `requests`-like API.

* [Tortoise ORM](https://tortoise-orm.readthedocs.io/en/latest/), a Django-like ORM.

* [Motor](https://motor.readthedocs.io/en/stable/index.html), an official MongoDB client.

All those tools allow to build performant web services leveraging the power of the asynchronous paradigm.

## Conclusion

Asynchronous programming is a very interesting pattern that can greatly improve performance in some contexts, especially in web servers. While it has been the privilege of NodeJS for quite some time, other languages are now catching up and it's great to see that Python community is becoming more and more involved in this trend.

At BeeMyDesk, we are currently building our platform using those technologies, especially **FastAPI**. We are glad to contribute to this ecosystem by releasing open-source libraries like [FastAPI Users](https://github.com/frankie567/fastapi-users) or [HTTPX OAuth](https://github.com/frankie567/httpx-oauth).

## References

* <https://en.wikipedia.org/wiki/Asynchronous_I/O>

* <https://en.wikipedia.org/wiki/Async/await>

* <https://docs.python.org/3/library/selectors.html>

* <https://trio.readthedocs.io/en/stable/tutorial.html>

* <https://trio.readthedocs.io/en/stable/design.html>

* <https://stackoverflow.com/questions/49005651/how-does-asyncio-actually-work>

* <http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/>

* <https://snarky.ca/how-the-heck-does-async-await-work-in-python-3-5/>

* <https://jvns.ca/blog/2017/06/03/async-io-on-linux--select--poll--and-epoll/>

\


Asynchronous programming have become very popular in the recent years, NodeJS being the locomotive of this trend, highly encouraging the async style and backed by impressive benchmarks.

Blog: Technique

Mise en place d'un talk en live streaming

Serverless functions for marketing automation

Asynchronous programming is now a thing in Python