Docker Support - Liquid File Changes Not Reflecting immediately in Live Environment

[dhawaldenny]

Problem: When changes are made to any Liquid file in the project, they do not take effect immediately.

Steps to Reproduce the Issue:

1. Create a New ASP.NET Core Web App (MVC) Project using Fluid

   • Install the NuGet packages: Fluid and Fluid.MVCViewEngine.
   • Add a controller and view, and create a view file named Index.liquid.
   • In the Program.cs file, add the following configurations:

     builder.Services.AddMvc().AddFluid();
     builder.Services.AddControllersWithViews().AddFluid();
     app.UseStaticFiles();

2. Add Docker File

   • Include a Dockerfile in the project.
   • Add the following key-value pair to the Dockerfile to enable file change detection:

     ENV DOTNET_USE_POLLING_FILE_WATCHER=1

3. Build the Docker Image

   • Use the following command to build the Docker image:

     docker build -t your_image_name .

4. Run Docker with Volume

   • Run the Docker container with a volume for dynamic updates using this command:

     docker run -p 5050:80 -v "dynamic_volume_path:/app/Views/:rw" your_image_name

5. Reproduce the Issue

   • Navigate to any Liquid file in the project.
   • Make text changes in the Liquid file.
   • Open the application in a browser (at the specified port). Notice that changes do not reflect immediately; however, after waiting for approximately 5–10 minutes, the changes are visible.

Reason for the Issue:

When changes are made to any Liquid file in the project, it triggers a full rebuild of all files, which causes a delay of around 5–10 minutes before updates appear. This delay is due to the current configuration where any single file modification initiates a complete rebuild, which is influenced by the volume size.

Issue Details:
● Affected Files: Liquid files.
● Current Behavior: A single file change causes the entire codebase to recompile.
● Impact: Average delay of 7–8 minutes per change as Per volume size, which accumulates over multiple changes and significantly affects development speed.

Demo Web App : https://github.com/dhawaldenny/Fluid_Demo_WebApp
Sandbox : https://codesandbox.io/p/github/dhawaldenny/Fluid_Demo_WebApp/main?import=true&workspaceId=676874cf-90d2-4548-bef7-f3da912431ea

Note: The number of view files in the folder will increase the delay before changes take effect.

For example, if there are only 4-5 view files, changes will typically take 30 seconds to 1 minute to load. However, if there are around 100 view (Liquid) files, it may take up to 5 minutes for changes to take effect, even if only one file was modified.

[sebastienros]

Thanks for the detailed explanation.

A single file change causes the entire codebase to recompile.

Do you suggest the full dotnet app is compiled? Liquid templates are only interpreted and it should take a few milliseconds or in less per file to be parsed.

What is the CPU sizes allocated to your container?

[dhawaldenny]

Do you suggest the full dotnet app is compiled? Liquid templates are only interpreted and it should take a few milliseconds or in less per file to be parsed.

What is the CPU sizes allocated to your container?

Hi Sebastien Ros,

Thanks for your quick response.

1. Yes, it seems like the time taken depends on the number of views. Fewer view files take around 30 seconds, while more view files take longer based on their size and quantity.
2. There is no specific CPU size allocated, which means the application can utilize the full node's cores (8-core CPU), as no other applications are deployed except for the kube-system namespace.

[sebastienros]

Liquid views are not compiled. Only razor ones, and it has nothing to do with fluid. Have you tried the same report without calling AddFluid and other fluid apis?

…

On Fri, Nov 15, 2024, 1:16 PM Dhaval T ***@***.***> wrote: Do you suggest the full dotnet app is compiled? Liquid templates are only interpreted and it should take a few milliseconds or in less per file to be parsed. What is the CPU sizes allocated to your container? Hi Sebastien Ros, Thanks for your quick response. 1. Yes, it seems like the time taken depends on the number of views. Fewer view files take around 30 seconds, while more view files take longer based on their size and quantity. 2. There is no specific CPU size allocated, which means the application can utilize the full node's cores (8-core CPU), as no other applications are deployed except for the kube-system namespace. image.png (view on web) <https://github.com/user-attachments/assets/c281d00c-cc86-43d5-995d-e326a37ffc61> — Reply to this email directly, view it on GitHub <#715 (comment)> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI4T3K6K3Z2B7LMUX6IVRT2AZQDFBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVA4TGNZYGY2DINMCUR2HS4DFUVUXG43VMWSXMYLMOVS2UMRWGU4DQMJRGAZTBJ3UOJUWOZ3FOKTGG4TFMF2GK> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

[dhawaldenny]

Have you tried the same report without calling AddFluid and other fluid apis?

Hi @sebastienros,

Yes, I tried the same report (Link to Razor repo: Demo_WebApp_Docker_Volume) without adding AddFluid and other Fluid APIs, but with:

builder.Services.AddRazorPages();
builder.Services.AddRazorPages().AddRazorRuntimeCompilation();
app.UseStaticFiles();

changes are reflected immediately.

The issue I observed is that Liquid files still do not reflect changes immediately. Instead, modifying a Liquid file triggers a full rebuild of the entire codebase as its not HTML or CSS file (see attached screenshot and link why it triggers build by watch command), which significantly delays the process (approximately 5 to 10 minutes, depending on the project size).

This delay in reflecting changes creates an efficiency bottleneck in the project. Razor files, as expected, reflect changes instantly, but Liquid files don't, and the rebuild process seems to be independent of whether the Fluid APIs are used or not. but it happens as liquid files are not HTML/css as per Microsoft documentation.

Let me know if you need any further clarification.

[dhawaldenny]

Hi @sebastienros ,

I hope you're doing well. I’m following up on the issue mentioned above. I was wondering if there’s been any progress or if there’s anything I can assist with to move it forward?

Please let me know if you need further details or support. Thanks for your time and efforts!