What is the standard or fast way of delivering dynamic stylesheets in ASP.NET / MVC5?

Question

For a big single page web application using ASP.net, MVC5 and Angular JS I'm looking to serve dynamic generated stylesheets. The application will have an big amount of users (> 1000s) that individually can set about 10 variables. These include a few colors and logos. These colors and logos will be used in the less stylesheet to generate lots of classes/styles. The stylesheet is compiled from a lot of files, about 50 .less files.

I'm planning to use the following approach:

1. On loading index.html, after user login, I call an ASP action to load the stylesheet <link href="Give/Me/My/Dynamic/Stylesheet/For/User/12122312">
2. The controller action will do its magic and gets the 10 user variables from the database
3. The server will than use .dotless to compile the less to css
4. Server returns string

This approach will work, but I'm afraid the performance will be not so good. My questions:

1. Is dotless the fastest way to compile less?
2. How long will the databasecall + compiling take?
3. Is this the way other application do this?
4. I'm looking if there's a way to cache the css request - maybe check if there has been a change since the last time the css was compiled.

What will not work:

1. Compile the less to css and then change the variables in the css (saves a compile every time). Some of the colors in the stylesheet will be based upon on of the variables. (eg lighten(#333, 0.3) etc).
2. Use a static stylesheet and then override these in the head of the HTML doc. There will be a whole lotta custom styles involved!

Some other thoughts:

This solution seems to do the same, but compiles on build:

This solution saves the variables to a static file and uses that for compiling. This saves a database call, but the directory gets crowded with lots of users.

Answer 1

Your planned approach sounds fine. As far as your specific questions go:

1. Is dotless the fastest way to compile less?

   "Fastest" is relative and debatable. The only way to know would be to run this and any available alternatives on your production machine using some sort of benchmarking. Even then, outside factors such as how much load the server is getting, how many requests are being handled simultaneously, etc. can affect those benchmarks. For example, maybe one solution is "faster" handling an ideal scenario, but has a large overhead that causes it to run much slower than another solution when the server is actually being taxed. Overall, it's impossible for anyone to give you any sort of definite answer to this, and really, it's probably too early to even be that concerned about the question. If it becomes a problem in production, then you can start investigating alternatives.

2. How long will the databasecall + compiling take?

   Also completely impossible for anyone to give a definitive answer to. There's way too many variables involved in that relatively simple question. What database are you using? What version? What are the specs of the server it's running on. What else is running on that server? How have you configured the database server? What kind of query are you running? How many tables are involved? What's the size of the resultset being returned? What type of network infrastructure is in place? What's your latency? How capable is your network infrastructure at handling load? There's probably more questions I could ask if I though long enough and that's just about the database call portion. I don't expect answers to those questions; I'm merely trying to point out 1) there's no way anyone can answer that for you and 2) you're going to have to do a lot of research to come up with those answers yourself.

3. Is this the way other application do this?

   This is highly speculative. First, it assumes this is somewhat common, when it's probably anything but. In my 20-some-odd years of doing web development, I've yet to encounter a scenario where I needed a dynamic stylesheet. Granted, for a large part of those years stylesheets didn't even exist or at least weren't heavily used yet and just because I haven't had a need doesn't mean there's not still a perfectly valid business-case for this. I understand the desire to want to find an accepted pattern or best practice to follow, but the sample set here is probably so small that no such thing exists. Trust your gut. Build things in a way that makes sense. Then test, refine and refactor. That's really the best advice I can give you.

4. I'm looking if there's a way to cache the css request - maybe check if there has been a change since the last time the css was compiled.

   This one is pretty easy. Just make sure to set the appropriate response headers before returning your response. Expires is really your go-to here. If the stylesheet virtually never changes for the user, then you can set a far future Expires header and the client's browser should cache it requiring all this infrastructure to not have to do its thing again for a while. If the change-ability is variable (any time the user updates a setting, they need a new version, and this can happen at a whim), then you can still use a far-future Expires header and employ a cache-busting querystring param that will force the browser to get a fresh copy. A good choice might be adding the last modified date for the settings when rendering the link for the stylesheet. If the user hasn't modified anything, then the date won't change and the original cached version will be used. But if the date has changed, it will look like a new URL to the browser, and it will be fetched fresh.