We have moved to GitHub Issues
Created by Pete Duncanson 02 Mar 2018, 15:59:48 Updated by Andy Thompson 04 Jun 2018, 23:00:52
Relates to: U4-11047
Parent for: U4-5576
Parent for: U4-11041
Parent for: U4-11044
Parent for: U4-11045
Parent for: U4-11046
Parent for: U4-11047
Parent for: U4-11048
Parent for: U4-11049
Parent for: U4-11050
Parent for: U4-11051
Parent for: U4-11060
Parent for: U4-11067
Parent for: CON-1509
Parent for: U4-11069
Parent for: U4-11074
Parent for: U4-11395
This issue is a thread about the possible reasons for wanting to do a back office rebuild, what it might look like, what we'd want it to do and how we might go about doing it. Consider it a wish list for now but ultimately what gets created needs to be pragmatic in the sense that we have to deliver something that helps many rather than something super technical no one can use or is so big it can't be finished (we've done that before).
More initial thoughts are on the blog post here: https://offroadcode.com/journal/dev-talk/thoughts-on-rebuilding-the-umbraco-cms-back-office/
Lets try to NOT have this become a framework battle just yet, please focus on what we want it to become, if we want it at all and how we might go about it. Other cases could be spun up under this if needed.
Pete, love the post and I think this is a good time to start the conversation.
I'm going to jot down some initial thoughts while I still have them:
While I agree its too early to talk frameworks, I think it would be useful to identify other CMSs that are using frameworks that may be a potential fit and see how it worked out for them. Just a thought, and there's obviously work there to discover this information and research the results. However, it may give us some great ideas.
I agree that the effort is big and risky. Since we're spending the time, could we at least consider features or perhaps a slight reorganization to give some value to clients? Maybe we create a list of our clients biggest pain points or complaints and see if we can address some of them?
I really love the approach of simplicity for people who want to extend Umbraco. Make people new to the system feel powerful.
Is the back-office API generic enough to simply build a new SPA on top of it? Or are there a lot of areas/services/APIs that know that Angular is being used and simply does it a certain way? Seems like we should address this first.
Much obliged @peteduncanson, I'm with @Prothero on this, brilliant write up at the right time!
A few points from me as well, and while I know there will be great gnashing of teeth for this, there's a lot we could do to make the developer's experience better, namely:
I've spent a little time this weekend creating cases for some of the performance tweets we've found. See all the linked cases to this one.
Some we have done, some we are wanting to do and others are still up for grabs. This is all stuff that will make whats already there right now faster, smaller and better to work with for everyone so all good stuff to be doing now. I've got some more on my list but they are more client dependant and some others that need some more digging.
Having pondered the feedback from my blog post I think this is screaming out for a session at Code Garden (now roughly 7 weeks away) to get some brains in a room with post-its and start documenting a plan and needs/wants/wishes so we having something concrete to work towards and make choices about.
Not sure an Open Space is right for it though but at a push that would do, danger is we discus it plenty before then at the bar (aka the "back channels" or "bar channels") and no one writes anything down and we are all a bit spent come Open Space day. Open to suggestions/ideas.
I personally think the backoffice is great, and just needs iterations. Unless of course someone comes up with a great new UX. The current codebase is good, and can be nudged to a new direction. The codebase for the backoffice will get increasingly easier to modify/improve as the APIs get more mature.
Keep in mind that no matter what is discussed, HQ has said that they are concentrating dev time on getting the .net side all the way to .net core, and that’s realistically going to take the better part of 2 years. Add to that the ideas/features that might get thrown into the mix (eg. tours).
@Dang And first getting the server-side to .NET Core would also bring other opportunities, like better integration with client-side frameworks using
Package authoring and installation could also benefit from this, because some packages now have to provide an Umbraco (for actions like adding document types) ''and'' a NuGet package (for adding IntelliSense or other library dependencies). The Umbraco actions can be done the way
[Chauffeur|https://github.com/aaronpowell/Chauffeur] does this, so packages would only need a NuGet version that could be installed from the back-end or Visual Studio ([Orchard|https://orchardproject.net/] uses this type of [packaging|https://gallery.orchardproject.net/] and already has a [.NET Core v1 beta|https://github.com/OrchardCMS/OrchardCore]).
@peteduncanson, @firstname.lastname@example.org Great thoughts and conclusions. I am currently think about combining users and members and addressing the different functionality just by roles or groups (what ever you prefer to call it). I had just my first insight into ASP.Net Identity. At the moment I have the impression it would be possible to leverage Identity and its role capabilities to distinguish frontend vs. back office usage of currently logged in user/member. This separation always occurred un-logical to me and I still realise this when I explain the concept to none-Umbracians (umbbles? like muggles :-D).
@dseefeld The separation of members and users is actually a benefit to many of my more security conscience clients. I personally think its a feature that is a good thing.
Would it be a start in the .NET Core direction to take the smaller assemblies and convert them to .NET Standard? It could be done slowly and incrementally by using facade classes and some redirection so existing code doesn't have to be relinked (yet). Converting the assemblies would be a great opportunity to also clean the code. Plus, if it doesn't seem to be working it's less to roll back.
Staying compatible with the current targetted .NET Framework 4.5 would require using .NET Standard 1.1, but once there the .NET Standard version can be incremented.
When .NET Core begins to be used the other assemblies would already be on their way to being compatible.
Backwards Compatible: True
Due in version: