Enable Response Buffering by default in Umbraco v9

[mattbrailsford]

This is really going to polarize people (I know it already has in the Discord channel) but I want to see if we can discuss enabling response buffering by default in Umbraco v9.

Background

I've recently been setting up Vendr in Umbraco v9, building out a site and getting things working when I hit upon a problem. Something that worked in v8 didn't work in v9 anymore and this ultimately boils down to calling a method in my view that performs a task and then attempts to write a cookie. In v8 (NF) this all works fine, but in v9 (NC) this threw an exception.

Headers are read-only, response has already started

After some investigation this appears to stem from the fact that in .NET Core the response is now returned in chunks, with the headers thus being the first thin that gets sent down the line, meaning that when the view starts to render, the headers have already been sent and so can no longer be modified and so the code from the view errors. This differs to v8 (NF) where responses would be buffered by default and so nothing would be sent until the whole page is rendered and thus anything could be changed right up to the request being sent.

In my investigations I found there were 2 ways to solve this issue:

1. Move all logic calls to a Controller / Component such that only static variables are sent to the view.
2. Install the package Microsoft.AspNetCore.Buffering and add app.UseResponseBuffering(); to the Startup.Configure method to re-anable response buffering.

After a lengthy discussion on Discord, even though option 1 is the better practice, I'm now wondering if we should go with option 2 and enable response buffering by default?

Chunking vs Buffering
Currently the default in v9 / .NET Core is for responses to be chunked and so a response is sent to the browser as quickly as possible. This has the advantage of creating a great Time to First Byte (TTFB) response and allows the browser to start loading client resources as quickly as possible. With buffering though, nothing reaches the browser until the whole page is sent down the line and so it can take pages that little bit longer to start loading those resources.

There is also the argument that streaming takes up less server resources than buffering which needs to load the whole page into memory before sending it down the line.

Why enable buffering?
Considering the above, why would we even consider enabling buffering by default if chunking is more optimal? Well, my answer to this is Developer Experience (DX), and specifically beginners and "implementors".

With chunking, whilst it offers the best performance, it comes with some side effects. Because some resources get sent before views start to render, it now starts to pose problems for those that write logic into views. Yea, I know, we shouldn't be writing logic in views, but some times you just need to do something fast, or you just want to learn how something works, and other times you just need something done now. Umbraco has long had a history of supporting these devs and I think it is worth continuing with this.

But should we really introduce a perf issue for the sake of some devs following bad practice? Well, the question really is "how significant is the perf difference?" and from some historic issue on this, it appears not massively dotnet/aspnetcore#3100

This is a pretty old issue though so I don't know how this stacks up today, but it really shouldn't be getting any worse than this.

In addition to this, there is already something logged for .NET 7 to improve this in some way (either bring back buffering, or better handling, it's not clear) dotnet/aspnetcore#27470

Proposition
My proposition then is that given there may be improvements coming, and it's clear there are side effects to chunking that require more developer centric knowledge to deal with (ie, moving code to controllers / components), could we enable response buffering by default such that people just starting with Umbraco get a simple and friendly dev experience but then expose a means of disabling buffering once they are at the best practices stage or if it's being worked on by a dev team that know how to manage the new approach and already follow those best practices.

There is an argument that we should maybe make it configurable to "enable buffering", but I personally think this would be a mistake as you are then requiring beginners to do this, before they can have a nice experience. I really think it would be much better for them to get the simple experience, and those in the know wanting to get maximum performance can then disable it and handle the side effects.

Well, there it is, now how do I mute this thread? 😂

• Thanks to Dave de Moel for finding the perf / .NET 7 issues 👍

[protherj]

OK, I'm coming around to have this enabled by default. That would make a better experience to those new to Umbraco or looking for a more flexible experience.

I wonder if Umbraco could have a configuration of "mode" that would enable the things behind the scenes (like buffering or whatever else we find) that allows devs to use Umbraco like Matt indicates. Like a "strict" or "flexible" setting. By default it would be set to "flexible" which would enable buffering.

Just an idea because it may be more friendly for devs to find and be aware of a mode or configuration than the "buffering" .NET configuration setting which is a bit hidden IMO and it could include more of these type of "gotcha" settings in the future.

Thanks for listening :)

[bergmania]

IMO the power of Umbraco is that it can be used for both enterprise solutions and also hobby projects.

In the real world, there is really 'quite a lot' in-between 'enterprise' and 'hobby', it's brave to only see it in those black and white terms.

I of course also mean everything in between

[hfloyd]

From the perspective of someone who spends all her time in that broad place "in-between"...

I work with many different types of developers and teams at various sizes of organizations (both "end-user in-house" as well as "agency"), so I have got a pretty good sense of the various levels of skills of people who are working on Umbraco sites. Additionally, most of the projects I work on I didn't get to design from the beginning - I am being brought on because the existing site isn't working well, or the original developers are no longer available, so I see how others are building sites.

Out of the dozens of site I have looked-at/worked on, I think only one had separate Controllers defined for each View (incidentally, this is also the most problematic site I have worked on - buggy, overly complicated, non-standard Umbraco practices, and difficult to change).

For the majority of website projects, there is a big risk associated with "over-engineering" (which adds costs, complexity, and inflexibility) - which is why I think so few Umbraco websites I have encountered tend to use a "pure" MVC setup.

Personally, when I am involved in a project, I create a separate ".Core" class project next to the Web project, and I use ModelsBuilder + a site-wide "Base" interface to put a fair amount of general logic into the models that come into a View... but I rarely have "per-view" separate Controllers.

Partly this is because I can't always count on my developer colleagues on any given project to be comfortable with editing / re-compiling a class project just to slightly change the filtering or sort order of the items displayed in a list on a page, etc. And partly because I don't want to over-complicate things as development moves along swiftly - If I add a new Doctype, a quick ModelsBuilder re-generation/re-build and I can work with the new data in a view immediately.

So, I strongly stand behind the idea that Umbraco Developers should NOT be forced to create 1-1 Controllers-Views. That being said, usually I don't need to manipulate things "outside" the visible rendered page (cookies, session, headers), so if this issue of "buffering vs chunking" only affects those items, then I am more open to the possibility of making the chunking the default option - with some nice documentation to describe the issue and how one would go about setting a cookie properly, for instance. If the issues affects basic things one might do in a View, then I would be against it.

BTW - From the preceding paragraph it should be obvious my level of ignorance regarding this specific issue of buffering in .Net Core. Keep in mind that probably 80%+ of other Umbraco Developers will have a similar level of ignorance, and plan accordingly. 😉

[protherj]

I love the discussion on this. I agree that if this cookie / buffering issue is the only instance like this that could be hidden frustration, then having a strict/flexible mode doesn't make a whole lot of sense. For now it seems like documentation and perhaps addressing it in training is the best idea.

Package devs should probably be developing defensively and always assume buffering is off so it works both ways for implementers.

If we find lots of edge cases like this during the process of upgrade packages and sites, then perhaps revisiting a simple "mode" would make sense. That would reduce the burden of documenting all of them effectively (who reads the docs anyways, right? ;) ). But I agree with Matt that it is likely premature for that kind of feature for just a single issue.

[JasonElkin]

I think that's an important point to bear in mind. We're not talking about the virtues of code in views vs. viewmodels/controllers, we're talking about the fact that some methods that could be called in views in v8 can't in v9.

It'd be helpful to understand the scope of what methods are not longer available and whether that warrants such a significant change.

We've always been in a situation where there are some methods/APIs that we just can't use in views. Sometimes this is an Umbraco decision, sometimes a framework decision.

What I'm worried about is reversing a framework decision that affects every single HTTP request in a site for the sake of a few methods that will likely be used very sparsely in any given site.

Selectively enabling this feature on a per-request (per template?) basis seems a much more sensible way to enable the now broken APIs than changing how HTTP responses work everywhere.

[kjac]

I'm sorry if this comes off as elitist or unfairly favoring experienced devs... but I truly believe that implementors bear the responsibility of knowing and understanding their tech stack; in this case be knowledgeable enough of .net (core or not) to construct a controller based solution to something like this.

In my opinion we should never compromise on any critical parts of Umbraco (i.e. performance, security, ...) to cater for bad practices. Instead we should be concerned with helping devs through documentation of common pitfalls (if this is indeed a common pitfall).

[JasonElkin]

As we're talking about the API the browser uses to fetch the website I think we need to be super careful to make sure we understand the real-world performance implications before a decision is made.

i.e. testing with sites with realistic frontend payloads and server-side code, across HTTP/1.1, HTTP/2 and... 🥁 HTTP/3! I suspect if there are performance considerations HTTP3 is where they would show up as that actually multiplexes the frames and sends them asynchronously.