Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would do that as a query string, it's easy, accurate enough and doesn't need any complex layers to achieve. Simply put the last modification of the file as query string on their links. That will force the browser to refresh the file.</p> <pre><code>&lt;link rel="stylesheet" type="text/css" href="/css/style.min.css?v=&lt;?= File::modified(path('public').'/css/style.min.css') ?&gt;" /&gt; </code></pre> <p>To simplify this, you could create a simple class that generates links to files and caches the last modification for increased performance. It's also achievable with custom functions on LESS compiler if you use it.</p> <p>Now, about server caching, if your application has that many users to really benefit from it, you should be looking into CDN's, which also handle worldwide distribution and will work wonderfully with that query string system.</p> <p><strong>Edit:</strong></p> <p>It's also possible to approach that with RewriteRules on Apache (don't have any experience with nginx to help on that tho). The same technique used to generate the query strings, you could use to generate a prefix (or suffix) to the URI.</p> <p>Another thing you could try is to define a subdomain mainly for handling static assets like <code>assets.example.com</code>. This domain can be entirely handled by a webserver without the Laravel stack. But it depends a lot on how your assets are developed, compiled and used across your project.</p> <p><strong>Our Approach:</strong></p> <p>On our company we use CloudFront and S3 for database entities assets. Each entity has it's own S3 directory and each asset is versioned through an unique filename (generated by md5, which avoids duplication on reuploaded assets). Something like:</p> <pre><code>/posts/876/060b90d67ac0c5e24da6de6ae547e3b1.jpg </code></pre> <p>We also defined 10 subdomains on our CloudFront, so browsers don't reach the limit of 6-8 concurrent requests for the same domain:</p> <pre><code>cdn0.example.com cdn1.example.com cdn2.example.com ... and so on </code></pre> <p>Each entry on our database uses an exclusive subdomain picked by calculating <code>resource.id % 10</code>, this is extremely fast and always returns the same subdomain for each entity (helping with client and CloudFront caches). This is the best you can get for serving images.</p> <p>UI images are stored on a exclusive subdomain <code>assets.example.com</code>, and those are not versioned so far, because we don't change design that much and if we do, we would probably put the new assets inside something like a <code>/v2/</code> or <code>/newthemename/</code> folder. This approach helps a lot with rollbacks and even user chosen themes.</p> <p>CSS and JS are served by Apache from within Laravel <code>/public</code> directory. This is not the fastest way, but since we are focused on development right now, having automatic compiling of LESS and Closure is far more important. When we launch for end users, we will probably think of an automated deploy system which compiles assets, publishes them on S3/CloudFront with a timestamp prefix and caches their last timestamp for view rendering.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload