Daylily-Informatics / bloom

Templated Abstract Polymorphic (and opinionated) LIMS
Mozilla Public License 2.0
0 stars 1 forks source link

Change From Cherrypy to ... ? #20

Closed iamh2o closed 2 months ago

iamh2o commented 7 months ago

Hi Adam!

I think this might now be top of my list :-)

First Priority

Moving Bloom from using cherrypy to another more scalable framework needs to happen soon. I'd like to maintain all of the jinja2 template behavior currently exposed, and add in more robust user auth and session data tracking. So, basically, replicate what is working now, but in a framework we can then move to expose more solid REST apis, and so on.

Next Steps

Rest, etc.

adamtracy commented 7 months ago

Seems like this and #19 are related.

We want to decouple the JINJA template loading from the REST APIs/actions. Not sure yet what this could entail, but my initial thought is that

  1. the page/template loads with a URL callback assigned as a jinja template variable.
  2. On page load, some minimal JS code in the template would then fetch this data and update the page with it.
    i suspect this separation of template rendering from data retrieval will be hte harder part of the problem. whether we continue using Cherrypy or FastAPI, i envision either will apply a similar approac.
adamtracy commented 7 months ago

via our friend gpt I'd like to decouple the template rendering from the data retrieval. what do you think of this approach:

  1. the page/template loads with a URL callback assigned as a jinja template variable.
  2. On page load, some minimal JS code in the template would then fetch this data and update the page with it.

Decoupling template rendering from data retrieval is a great approach, especially for dynamic and interactive web applications. It allows for a clear separation of concerns — the server-side handles rendering the initial page structure, while the client-side handles dynamic data fetching and updates. Your proposed approach aligns well with this model. Here's a breakdown of its benefits and some considerations:

Benefits

  1. Improved User Experience: With asynchronous data loading, your page can render quickly with the initial structure, and data can be populated as soon as it's fetched, enhancing perceived performance.

  2. Scalability: Separating data retrieval from rendering makes it easier to manage and scale the frontend and backend independently.

  3. Flexibility in Frontend Development: Frontend developers can work on the data presentation and interactions without being tied to the backend logic for data fetching.

  4. Reduced Server Load: Offloading data fetching to the client-side can reduce the processing load on the server, as it only needs to serve the initial page template.

  5. Real-time Updates: This approach facilitates implementing real-time updates using JavaScript, allowing the page to dynamically update content without a full reload.

Considerations

  1. JavaScript Dependency: Your application will rely on JavaScript for data loading. Ensure that this doesn't negatively impact users with JavaScript disabled or in environments with limited JavaScript support.

  2. Initial Load Content: Consider what content will be shown during the initial load and how you will handle the user interface while data is being fetched.

  3. SEO Implications: For pages that require good SEO, ensure that the initial HTML sent from the server contains sufficient content and metadata, as search engines might not execute your JavaScript.

  4. Error Handling: Implement robust error handling for the JavaScript fetching data. If the data fetch fails, the user should be appropriately informed.

  5. Security: Ensure that data fetched via JavaScript is done securely, especially if sensitive information is being retrieved. Implement necessary measures like API authentication, authorization, and data encryption.

  6. API Design: Design your API endpoints to efficiently deliver the data needed by the frontend. Good API design is crucial for performance and usability.

Implementation Example

Here's a simple example of how this might be implemented:

Jinja Template (HTML)

<!DOCTYPE html>
<html>
<head>
    <title>My Page</title>
</head>
<body>
    <div id="data-container">Loading data...</div>
    <script>
        fetch("{{ url_for('get_data') }}")
            .then(response => response.json())
            .then(data => {
                document.getElementById('data-container').innerHTML = JSON.stringify(data);
            })
            .catch(error => console.error('Error:', error));
    </script>
</body>
</html>

FastAPI Backend (Python)

from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()

@app.get("/get-data")
def get_data():
    # Fetch or generate data
    data = {"message": "Hello, world!"}
    return JSONResponse(content=data)

In this setup, the Jinja template renders a basic HTML structure with a JavaScript snippet to fetch data from the server and update the page content. The FastAPI backend provides an endpoint to serve this data. This approach is clean, modular, and in line with modern web development practices.

iamh2o commented 2 months ago

FastAPI and Jinja2 have been fully adopted at this point. Great suggestion @adamtracy !