Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Webapp launcher page #301

Closed
tuscland opened this issue Sep 5, 2024 · 2 comments · Fixed by #421
Closed

Webapp launcher page #301

tuscland opened this issue Sep 5, 2024 · 2 comments · Fixed by #421
Assignees
@augustebaum
Labels
enhancement New feature or request

Comments

@tuscland
Copy link
Member

tuscland commented Sep 5, 2024

When the webapp is launched, we would like to open a browser so that the user can start using the application without intervention.

Serving the webapp is a blocking call, therefore the browser must be open before. But this order is inconsistent with the availability of the webapp, therefore the browser displays an error.

Instead of opening a connexion directly to the webapp, we suggest that a local HTML file is open instead, acting as a launcher. This HTML file would contain code to poll until webapp availability, then switch to the target URL.

Here is a naive implementation of such launcher page:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Loading Application</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            display: flex;
            justify-content: center;
            align-items: center;
            height: 100vh;
            margin: 0;
            background-color: #f0f0f0;
        }
        .loader {
            text-align: center;
        }
        .spinner {
            border: 4px solid #f3f3f3;
            border-top: 4px solid #3498db;
            border-radius: 50%;
            width: 40px;
            height: 40px;
            animation: spin 1s linear infinite;
            margin: 20px auto;
        }
        @keyframes spin {
            0% { transform: rotate(0deg); }
            100% { transform: rotate(360deg); }
        }
    </style>
</head>
<body>
    <div class="loader">
        <h1>Loading Application</h1>
        <div class="spinner"></div>
        <p id="message">Please wait while we connect to the server...</p>
    </div>

    <script>
        const mainAppUrl = 'http://localhost:5000/'; // Replace with your app's URL
        const checkInterval = 2000; // Check every 2 seconds

        function checkServerStatus() {
            fetch(mainAppUrl, { method: 'HEAD' })
                .then(response => {
                    if (response.ok) {
                        window.location.href = mainAppUrl;
                    } else {
                        setTimeout(checkServerStatus, checkInterval);
                    }
                })
                .catch(() => {
                    document.getElementById('message').textContent = 'Still trying to connect...';
                    setTimeout(checkServerStatus, checkInterval);
                });
        }

        checkServerStatus();
    </script>
</body>
</html>

Query parameters could be used to parametrize this page, passing the target URL.
@tuscland tuscland added the enhancement New feature or request label Sep 5, 2024
@tuscland tuscland added this to the PyData Paris milestone Sep 5, 2024
@augustebaum
Copy link
Contributor

In practice, a sleep statement of 0.5 seconds before opening the browser is always enough for the webapp to start, so the blank screen is never seen. Therefore I think this is low priority.

Apart from that, @rouk1 may have found a way to let uvicorn start the browser itself, which would solve the issue more directly: lifespan events.

@tuscland
Copy link
Member Author

Nice! So, I let you close this issue and open another one if you would like to investigate lifespan events.

@tuscland tuscland removed this from the PyData Paris milestone Sep 26, 2024
@augustebaum augustebaum self-assigned this Oct 1, 2024
@augustebaum augustebaum mentioned this issue Oct 1, 2024
Merged
rouk1 pushed a commit that referenced this issue Oct 1, 2024
@augustebaum
refactor(launch): Replace thread with lifespan event for opening the …
188b502 
…browser (#421)

Closes #301
@rouk1 rouk1 closed this as completed in #421 Oct 1, 2024
thomass-dev pushed a commit that referenced this issue Dec 2, 2024
@augustebaum
refactor(launch): Replace thread with lifespan event for opening the …
75f99bd 
…browser (#421)

Closes #301
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@augustebaum augustebaum

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

refactor(launch): Replace thread with lifespan event for opening the browser probabl-ai/skore
2 participants
@tuscland @augustebaum