Do you use a load balancer that isn’t tightly integrated with your orchestrator and therefore doesn’t know upfront when the orchestrator has to stop an instance of your ASP.NET Core application for an upgrade / a scaling action / a restart?
Does this result in a few failing requests until the load balancer has finally figured out that the instance is gone?
If so, this blog post might be for you!
These are the requirements for our app:
The best way to solve these requirements in Flutter is to use flavors. There are also some other tutorials for this linked on the official Flutter docs which might be helpful.
The code for this guide is stored on GitHub and changes for each section are separate commits that are linked in the section below.
The first step in our process to a better folder structure for our MVC projects is to make sure, MVC can resolve our Controllers and Views. This is our target structure:
Of course, if you don’t want to use “areas” you only need the “Features” folder in your project. This also means, that if you move to this new structure, you can completely remove the old “Controllers” and “Views” folders.
Which of these requirements is more common?
I guess we are on the same page if we see the second one as more common. I would go as far as to say that if you have the first requirement you’re either working on a major relaunch or you’re not using layout pages, css, abstract classes, [insert random reusability gadget here] correctly.
