In the integration examples for Flask, Django, and Fast API, development servers spin up two threads—one thread runs the server, the other thread monitors for code changes. When a code change is detected, the “main” thread kicks the server thread to tell it to restart, thus hot loading the new changes.
In the integration examples, pyngrok is possibly be creating in both of these threads (or the server thread), and in either of those cases it means we may have either port conflicts or the ngrok process may be unnecessarily restarted along with the web server (doing this would generate a new ngrok URL as well, which would be annoying). The integration examples should ensure the ngrok process is only started in the “main” thread so it is as long-lived as the development server’s “main” process (and only started once).
In the integration examples for Flask, Django, and Fast API, development servers spin up two threads—one thread runs the server, the other thread monitors for code changes. When a code change is detected, the “main” thread kicks the server thread to tell it to restart, thus hot loading the new changes.
In the integration examples,
pyngrok
is possibly be creating in both of these threads (or the server thread), and in either of those cases it means we may have either port conflicts or thengrok
process may be unnecessarily restarted along with the web server (doing this would generate a newngrok
URL as well, which would be annoying). The integration examples should ensure thengrok
process is only started in the “main” thread so it is as long-lived as the development server’s “main” process (and only started once).