From Flask to Gunicorn + Nginx: Improving Backend Performance and Stability

Recently, I've been facing a recurring issue: after running for a while, my backend server becomes unresponsive. Restarting the process temporarily fixes it, but this is a serious problem once the user base grows. One night before going to bed, I opened my app and, once again, the backend was unresponsive. I decided to fix it before sleeping. Since I had no prior experience in this area, I asked ChatGPT for help. It first suggested checking the logs for errors, but I found nothing—no errors, not even records of service calls. Then, I showed AI my app.py file, and it identified the root cause: I was running Flask with its built-in development server (app.run(...)), without configuring Nginx as a reverse proxy. This meant the frontend was directly connecting to port 5000. The development server is single-process and single-threaded, so whenever a slow I/O operation occurred, the only worker thread would get blocked, causing the service to freeze. Although this didn't immediately solve the issue, I realized I would eventually need a production-ready setup. So, with AI's help, I replaced my app.py and backend routes to run under Gunicorn, enabling multiple processes and threads. Next, I configured Nginx as a reverse proxy to handle all routes. Finally, I updated my frontend JavaScript requests from https://<domain>:5000/<route> to simply /<route>. After testing, I found that both /readdata and /login responded much faster. As for stability, I'll continue monitoring it over time.

Fix Logging Issues

After switching my backend to Gunicorn, stability improved a lot. However, I ran into a development-time issue: inside my route handlers I used print to write logs, and I started the app with this command to redirect all stdout/stderr to a file:

exec python3 src/backend/app.py > ./log/app.out 2>&1

In theory, everything printed should land in app.out, but nothing showed up. A quick search told me this is pretty common. I asked ChatGPT how to log "properly," and it suggested using Python's logging library.

So at the top of app.py I added:

import logging

And also, I add:

handler = RotatingFileHandler("./log/app.out", maxBytes=5_000_000, backupCount=3, encoding="utf-8")

With that in place, I can call logger in my route functions and use levels like info and warning to make searching easier. Now, checking logs is much smoother.

Compatible with Android devices

Today, I successfully adapted my app to the Android system. Since my app is essentially a web page, the adaptation was relatively simple — it only required opening a link through the app. However, as I had never worked with Android development before, the process still felt quite challenging. Compared to Apple's development, Android involves many more configuration items, which at times left me overwhelmed. Fortunately, with the help of AI, I was able to complete it. But when I tried to add a splash screen, I unexpectedly discovered that Android does not support playing videos with an alpha channel. This means I couldn't create the same startup animation as on iOS. In the end, I decided to skip the splash animation altogether.

Adapting to App Store Guidelines with Capacitor

Recently, while reviewing Apple's App Store guidelines, I realized that purely wrapping an H5 web app inside a shell makes it impossible to pass the review. Some native functionalities are required, such as notifications, widgets, or integrations with Apple Health. Since my current H5 frontend could not achieve this, I started exploring new solutions. That's when I discovered Capacitor, a framework that can package JavaScript-based apps into cross‑platform native applications, while also providing a rich plugin system for interacting with native features. I also learned there is a UI library named Ionic, which automatically adapts to iOS and Android design languages. Initially, I tried migrating my existing UI into Ionic, but the results were unsatisfactory, so I abandoned that path. Instead, I use Capacitor only. After installation, I could control app behavior directly from the terminal and use plugins like vibration, which worked seamlessly across both iOS and Android. Soon, I added vibration feedback to most buttons, greatly enhancing user immersion. With this framework, adapting system‑level features and accessing Apple Health data became much more approachable, and I finally felt confident about aligning my app with App Store requirements.

Building a Medication Reminder Feature

Over the past few days, I updated quite a few features, such as the mood selection interface and the record page. These updates didn't carry much record‑keeping value; they were mostly about UI tweaks and refining the interaction with AI, which handled them excellently. After that, I decided to build a medication reminder feature. Since it was logically independent and didn't rely on a database, I thought it would be quick to implement — though it turned out more complex than expected. Capacitor made it easy to support iOS and Android push notifications via plugins, but the web version posed challenges. In the end, I removed the feature on web and guided users to download the app if they needed reminders. I completed the environment judgment with the following code:

function isCapacitorApp() {
  try {
    // Check if the Capacitor object exists
    if (typeof window.Capacitor === 'undefined') {
      return false;
    }

    // Check if it is a native platform
    if (typeof window.Capacitor.isNativePlatform === 'function') {
      return window.Capacitor.isNativePlatform();
    }

    // Fallback check: verify the basic structure of the Capacitor object
    return !!(window.Capacitor && window.Capacitor.Plugins);
  } catch (error) {
    console.warn('Error while detecting Capacitor environment:', error);
    return false;
  }
}

The basic notification sending worked quickly, but to make it more useful, I added recurring reminders like daily and weekly schedules. While AI generated much of the code, I struggled to understand the overall structure. A bug appeared: switching pages caused duplicate notifications and reminder cards wouldn't clear. AI failed to fix it despite many attempts, so I dug into the code myself. Eventually I found that reloading index.js triggered the duplicate requests. After I reported this root cause, AI instantly gave a working fix: assigning each reminder a random ID that can only trigger once. This solved the bug neatly. Later, I polished the feature further with extra options. Through this process I realized that while AI can write code very efficiently, its context limitations prevent it from fully grasping project architecture. A skilled programmer's role is still crucial — to understand the logic, direct the development, and collaborate with AI for maximum efficiency.

Start building the user health database Sep 18 2025

After completing a series of functions, I finally encountered the most difficult part I had always thought - storing users' dietary, health status and other information in the database. As I have designed many health-related sections and my knowledge of MySQL is quite limited, I initially intended to store data through table associations, but I felt it was quite challenging. Suddenly, an idea struck me: Why not convert the information filled in by users each time into JSON format and then store it in the database? I thought this was a feasible solution, so I began to put it into practice. Since the data to be stored mainly consists of three parts: diet, health and medical records, I have decided to create separate tables for each part. I created an uploadjson.py file in the back end and created a database table through the following code:

function isCapacitorApp() {
          ddl = f"""
          CREATE TABLE IF NOT EXISTS {table_name} (
          id VARCHAR(64) PRIMARY KEY,
          user_id VARCHAR(128) NULL,
          username VARCHAR(128) NULL,
          file_name VARCHAR(255) NOT NULL,
          content LONGTEXT NOT NULL,
          created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
          INDEX idx_user_id (user_id),
          INDEX idx_username (username),
          INDEX idx_created_at (created_at)
          ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
          """

Subsequently, I asked the AI to write the code for JSON conversion in the JavaScript file for me and unified the file naming format. At this point, the entire process is basically completed, and the user's health data can be smoothly stored and managed.

Completing the Daily Page and App Store Submission Sep 19 2025

Now that I had completed the most challenging part—data storage—I began working on the daily page's information display. I added the same functionality to the diet logging page and then focused on presenting the data in the daily section. This part was honestly quite straightforward, similar to the readdata functionality but with added categorization and JSON data processing capabilities. I completed it quickly.

After implementation, I encountered some UI issues, such as the page still being scrollable when modals were open, which created a strange user experience, and limited vertical scrolling distances. I had AI help fix these problems, and they were resolved successfully.

Looking at the entire project, I felt the functionality was essentially complete, so I decided to try submitting to the App Store again. I remembered my first App Store submission when I had only completed the page framework using a shell app approach with no native support or content implementation. Comparing that to the current app, which now includes native features like messaging and a well-developed database, the improvement was substantial.

I asked AI to calculate the probability of approval, and it estimated around 85-90%. I logged into App Store Connect, filled out the necessary information similar to my previous calendar app submission, and submitted for review. I'm hoping the review process goes smoothly!

Meeting Review Requirements and Successful Launch Sep 26 2025

As I mentioned earlier, I had uploaded my app to App Store Connect, but unsurprisingly, it was rejected. The first rejection was because I hadn't provided test account credentials for the reviewers. This was relatively easy to fix—I simply added test accounts to the backend database and shared the login information with the reviewers.

The second rejection was more concerning. I discovered the rejection notice at 1 AM when I got up to use the bathroom. The reason was a bug in my AI chat feature. The news completely eliminated my drowsiness, and I spent half an hour fixing the issue before resubmitting and finally going back to bed. However, when I woke up, I found it had been rejected again. This time, the reason was that Apple requires AI-generated health information to include citations.

This left me feeling somewhat helpless, as my AI model doesn't have internet search capabilities and couldn't find web sources. Following AI's suggestion, I manually found several authoritative websites and implemented a keyword-matching system to determine which citation to display. Users could click the links to open these authoritative sites in their default browser. I submitted again, but it was still rejected.

Feeling frustrated, I replied to the Apple reviewer, explaining that my AI model lacks internet search capabilities. I also mentioned that I had already added citations from authoritative websites and included a disclaimer at the end stating that the advice was for reference only and that users should seek medical attention if they feel unwell. Surprisingly, the reviewer immediately approved my app after reading my response.

Now, this app is live on the App Store at here. This experience taught me the importance of clear communication with reviewers and the value of being transparent about technical limitations while still meeting platform requirements.

The process of making the app is not over yet, I will continue to update this passage, thank you. Because this post is already quite long, I will open a separate page for the next post. You can click here to view the next article.