Tag: Vue 3

Part 1: Understanding Request Flow and Caching in a Rails + Vue + Nginx Setup

Introduction

When building modern web applications, performance is a critical factor for user experience and SEO. In setups that combine Rails (for backend logic) with Vue 3 (for the frontend), and Nginx + Passenger as the web server layer, developers must understand how requests flow through the system and how caching strategies can maximize efficiency. Without a clear understanding, issues such as stale content, redundant downloads, or poor Google PageSpeed scores can creep in.

In this series, we will break down the architecture into three detailed parts. In this first part, we’ll look at the basic request flow, why caching is needed, and the specific caching strategies applied for different types of assets (HTML, hashed Vue assets, images, fonts, and SEO files).

🔹 1. Basic Request Flow

Let’s first understand how a browser request travels through our stack. In a Rails + Vue + Nginx setup, the flow is layered so that Nginx acts as the gatekeeper, serving static files directly and passing dynamic requests to Rails via Passenger. This ensures maximum efficiency.

Browser Request (user opens https://mydomain.com)
      |
      v
+-------------------------+
|        Nginx            |
| - Serves static files   |
| - Adds cache headers    |
| - Redirects HTTP → HTTPS|
+-------------------------+
      |
      |---> /public/vite/*   (hashed Vue assets: JS, CSS, images)
      |---> /public/assets/* (general static files, fonts, images)
      |---> /public/*.html   (entry files, e.g. vite.html)
      |---> /sitemap.xml, robots.txt
      |
      v
+-------------------------+
| Passenger + Rails       |
| - Handles API requests  |
| - Renders dynamic views |
| - Business logic        |
+-------------------------+
      |
      v
Browser receives response

Key takeaways:

  • Nginx is optimized for serving static files and does this without invoking Rails.
  • Hashed Vue assets live in /public/vite/ and are safe for long-term caching.
  • HTML entry files like vite.html should never be cached aggressively, as they bootstrap the application.
  • Rails only handles requests that cannot be resolved by static files (APIs, dynamic content, authentication, etc.).

🔹 2. Why Caching Matters

Every time a user visits your site, the browser requests resources such as JavaScript, CSS, images, and fonts. Without caching, the browser re-downloads these assets on every visit, leading to:

  • Slower page load times
  • Higher bandwidth usage
  • Poorer SEO scores (Google PageSpeed penalizes missing caching headers)
  • Increased server load

Caching helps by instructing browsers to reuse resources when possible. However, caching needs to be carefully tuned:

  • Static, versioned assets (like hashed JS files) should be cached for a long time.
  • Dynamic or frequently changing files (like HTML, sitemap.xml) should bypass cache.
  • Non-hashed assets (like assets/*.png) can be cached for a shorter duration.

🔹 3. Caching Strategy in Detail

1. Hashed Vue Assets (/vite/ folder)

Files built by Vite include a content hash in their filenames (e.g., index-B34XebCm.js). This ensures that when the file content changes, the filename changes as well. Browsers see this as a new resource and download it fresh. This makes it safe to cache these files aggressively:

location /vite/ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

This tells browsers to cache these files for a year, and the immutable directive prevents unnecessary revalidation.

2. HTML Files (vite.html and others)

HTML files should always be fresh because they reference the latest asset filenames. If an old HTML file is cached, it might point to outdated JS or CSS, breaking the app. Therefore, HTML must always be served with no-cache:

location ~* \.html$ {
    add_header Cache-Control "no-cache";
}

This forces browsers to check the server every time before using the file.

3. Other Static Assets (images, fonts, non-hashed JS/CSS)

Some assets in /public/assets/ do not have hashed filenames (e.g., logo.png). Caching these too aggressively could cause stale content issues. A shorter cache period (like 1 hour) is a safe balance:

location ~* \.(?:js|css|woff2?|ttf|otf|eot|jpg|jpeg|png|gif|svg|ico)$ {
    expires 1h;
    add_header Cache-Control "public";
}

4. SEO Files (sitemap.xml, robots.txt)

Search engines like Google frequently re-fetch sitemap.xml and robots.txt to keep their index up-to-date. If these files are cached, crawlers may miss recent updates. To avoid this, they should always bypass cache:

location = /sitemap.xml {
    add_header Cache-Control "no-cache";
}
location = /robots.txt {
    add_header Cache-Control "no-cache";
}

🔹 4. Summary Diagram

The diagram below illustrates the request flow and caching rules:

Browser Request
      |
      v
+------------------+          +-------------------+
|      Nginx       |          | Passenger + Rails |
|------------------|          |-------------------|
| - Serves /vite/* |          | - Dynamic APIs    |
|   (1y immutable) |          | - Auth flows      |
| - Serves .html   |          | - Business logic  |
|   (no-cache)     |          +-------------------+
| - Serves assets/*|
|   (1h cache)     |
| - Serves SEO     |
|   (no-cache)     |
+------------------+
      |
      v
Response to Browser

Let’s bring in some real-world examples from well-known Rails projects so you can see how this fits into practice:

🔹 Example 1: Discourse (Rails + Ember frontend, served via Nginx + Passenger)

  • Request flow:
    • Nginx serves all static JS/CSS files that are fingerprinted (application-9f2c01f2b3f.js).
    • Rails generates these during asset precompilation.
    • Fingerprinting ensures cache-busting (like our vite/index-B34XebCm.js).
  • Caching:
    • In their Nginx config, Discourse sets: location ~ ^/assets/ { expires 1y; add_header Cache-Control "public, immutable"; }
    • All .html responses (Rails views) are marked no-cache.
    • This is exactly the same principle we applied for our /vite/ folder.

🔹 Example 2: GitLab (Rails + Vue frontend, Nginx load balancer)

  • Request flow:
    • GitLab has Vue components bundled by Webpack (similar to Vite in our case).
    • Nginx first checks /public/assets/ for compiled frontend assets.
    • If not found → request is passed to Rails via Passenger.
  • Caching:
    • GitLab sets very aggressive caching for hashed assets, because they change only when a new release is deployed: location ~ ^/assets/.*-[a-f0-9]{32}\.(js|css|png|jpg|svg)$ { expires max; add_header Cache-Control "public, immutable"; }
    • Non-hashed files (like /uploads/ user content) get shorter caching (1 hour or 1 day).
    • HTML pages rendered by Rails = no-cache.

🔹 Example 3: Basecamp (Rails + Hotwire, Nginx + Passenger)

  • Request flow:
    • Their entrypoint is still HTML (application.html.erb) served via Rails.
    • Static assets (CSS/JS/images) precompiled into /public/assets.
    • Nginx serves these directly, without touching Rails.
  • Caching:
    • Rails generates digest-based file names (like style-4f8d9d7.css).
    • Nginx rule: location /assets { expires 1y; add_header Cache-Control "public, immutable"; }
    • Same idea: hashed = long cache, HTML = no cache.

👉 What this shows:

  • All large Rails projects (Discourse, GitLab, Basecamp) follow the same caching pattern we’re doing:
    • HTML → no-cache
    • Hashed assets (fingerprinted by build tool) → 1 year, immutable
    • Non-hashed assets → shorter cache (1h–1d)

So what we’re implementing in our setup is the industry standard. ✅

Conclusion

In this part, we established the foundation for how requests move through Nginx, Vue, and Rails, and why caching plays such an essential role in performance and reliability. The key principles are:

  • Hashed files = cache long term
  • HTML and SEO files = never cache
  • Non-hashed static assets = short cache
  • Rails/Passenger handles only dynamic requests

In Part 2, we’ll dive deeper into writing a complete Nginx configuration for Rails + Vue, covering gzip compression, HTTP/2 optimizations, cache busting, and optional Vue Router history mode support.

⚡ Understanding Vue.js Composition API

Vue 3 introduced the Composition API — a modern, function-based approach to building components. If you’ve been using the Options API (data, methods, computed, etc.), this might feel like a big shift. But the Composition API gives you more flexibility, reusability, and scalability.

In this post, we’ll explore what it is, how it works, why it matters, and we’ll finish with a real-world API fetching example.

🧩 What is the Composition API?

The Composition API is a collection of functions (like ref, reactive, watch, computed) that you use inside a setup() function (or <script setup>). Instead of organizing code into option blocks, you compose logic directly.

👉 In short:
It lets you group related logic together in one place, making your components more readable and reusable.

🔑 Core Features

Here are the most important building blocks:

  • ref() → create reactive primitive values (like numbers, strings, booleans).
  • reactive() → create reactive objects or arrays.
  • computed() → define derived values based on reactive state.
  • watch() → run side effects when values change.
  • Lifecycle hooks (onMounted, onUnmounted, etc.) → usable inside setup().
  • Composables → reusable functions built with Composition API logic.

⚖️ Options API vs Composition API

Options API (Vue 2 style)

<script>
export default {
  data() {
    return {
      count: 0
    }
  },
  methods: {
    increment() {
      this.count++
    }
  }
}
</script>

Composition API (Vue 3 style)

<script setup>
import { ref } from 'vue'

const count = ref(0)
const increment = () => count.value++
</script>

<template>
  <p>{{ count }}</p>
  <button @click="increment">+</button>
</template>

✨ Notice the difference:

  • With Options API, logic is split across data and methods.
  • With Composition API, everything (state + methods) is grouped together.

🚀 Why Use Composition API?

  1. Better logic organization → Group related logic in one place.
  2. Reusability → Extract shared code into composables (useAuth, useFetch, etc.).
  3. TypeScript-friendly → Works smoothly with static typing.
  4. Scalable → Easier to manage large and complex components.

🌍 Real-World Example: Fetching API Data

Let’s say we want to fetch user data from an API.

Step 1: Create a composable useFetch.js

// composables/useFetch.js
import { ref, onMounted } from 'vue'

export function useFetch(url) {
  const data = ref(null)
  const error = ref(null)
  const loading = ref(true)

  onMounted(async () => {
    try {
      const res = await fetch(url)
      data.value = await res.json()
    } catch (err) {
      error.value = err
    } finally {
      loading.value = false
    }
  })

  return { data, error, loading }
}

Step 2: Use it inside a component

<script setup>
import { useFetch } from '@/composables/useFetch'

const { data, error, loading } = useFetch('https://jsonplaceholder.typicode.com/users')
</script>

<template>
  <div>
    <p v-if="loading">Loading...</p>
    <p v-if="error">Error: {{ error.message }}</p>
    <ul v-if="data">
      <li v-for="user in data" :key="user.id">{{ user.name }}</li>
    </ul>
  </div>
</template>

✨ What happened?

  • The composable useFetch handles logic for fetching.
  • The component only takes care of rendering.
  • Now, you can reuse useFetch anywhere in your app.

🎯 Final Thoughts

The Composition API makes Vue components cleaner, reusable, and scalable. It might look different at first, but once you start grouping related logic together, you’ll see how powerful it is compared to the Options API.

If you’re building modern Vue 3 apps, learning the Composition API is a must.

🔄 Vue.js: Composition API vs Mixins vs Composables

When working with Vue, developers often ask:

  • What’s the difference between the Composition API and Composables?
  • Do Mixins still matter in Vue 3?
  • When should I use one over the other?

Let’s break it down with clear explanations and examples.

🧩 Mixins (Vue 2 era)

🔑 What are Mixins?

Mixins are objects that contain reusable logic (data, methods, lifecycle hooks) which can be merged into components.

⚡ Example: Counter with a mixin

// mixins/counterMixin.js
export const counterMixin = {
  data() {
    return {
      count: 0
    }
  },
  methods: {
    increment() {
      this.count++
    }
  }
}


<script>
import { counterMixin } from '@/mixins/counterMixin'

export default {
  mixins: [counterMixin]
}
</script>

<template>
  <p>{{ count }}</p>
  <button @click="increment">+</button>
</template>

✅ Pros

  • Easy to reuse logic.
  • Simple syntax.

❌ Cons

  • Name conflicts → two mixins or component methods can override each other.
  • Hard to track where logic comes from in large apps.
  • Doesn’t scale well.

👉 That’s why Vue 3 encourages Composition API + Composables instead.

⚙️ Composition API

🔑 What is it?

The Composition API is a set of functions (ref, reactive, watch, computed, lifecycle hooks) that let you write components in a function-based style.

⚡ Example: Counter with Composition API

<script setup>
import { ref } from 'vue'

const count = ref(0)
const increment = () => count.value++
</script>

<template>
  <p>{{ count }}</p>
  <button @click="increment">+</button>
</template>

👉 Unlike Mixins, all logic lives inside the component — no magic merging.

✅ Pros

  • Explicit and predictable.
  • Works great with TypeScript.
  • Organizes related logic together instead of scattering across options.

🔄 Composables

🔑 What are Composables?

Composables are just functions that use the Composition API to encapsulate and reuse logic.

They’re often named with a use prefix (useAuth, useCounter, useFetch).

⚡ Example: Reusable counter composable

// composables/useCounter.js
import { ref } from 'vue'

export function useCounter() {
  const count = ref(0)
  const increment = () => count.value++
  return { count, increment }
}

Usage in a component:

<script setup>
import { useCounter } from '@/composables/useCounter'

const { count, increment } = useCounter()
</script>

<template>
  <p>{{ count }}</p>
  <button @click="increment">+</button>
</template>

✅ Pros

  • Clear and explicit (unlike Mixins).
  • Reusable across multiple components.
  • Easy to test (plain functions).
  • Scales beautifully in large apps.

🆚 Side-by-Side Comparison

FeatureMixins 🧩Composition API ⚙️Composables 🔄
Introduced inVue 2Vue 3Vue 3
ReusabilityYes, but limitedMostly inside componentsYes, very flexible
Code OrganizationScattered across mixinsGrouped inside setup()Encapsulated in functions
ConflictsPossible (naming issues)NoneNone
TestabilityHarderGoodExcellent
TypeScript SupportPoorStrongStrong
Recommended in Vue 3?❌ Not preferred✅ Yes✅ Yes

🎯 Final Thoughts

  • Mixins were useful in Vue 2, but they can cause naming conflicts and make code hard to trace.
  • Composition API solves these issues by letting you organize logic in setup() with functions like ref, reactive, watch.
  • Composables build on the Composition API — they’re just functions that encapsulate and reuse logic across components.

👉 In Vue 3, the recommended pattern is:

  • Use Composition API inside components.
  • Extract reusable logic into Composables.
  • Avoid Mixins unless maintaining legacy Vue 2 code.