RFC 0024 - Implement The New Backoffice #34
Replies: 11 comments 30 replies
-
|
Very impressive RFC! Agree this is the best direction - and fits nicely with the two prior RFCs. Likes: backoffice as separate package from core CMS, Web Components, documentation. Concerns: TypeScript (that’s just a pill I’m going to have to swallow), number of dependencies (Lit, etc...). Looking forward to following along. And to be clear, I have no real concerns with the RFC, more just my own lack of experience with the tech stack proposed. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your sentiment, @paulsterling. TypeScript is useful to convey meaningful types, just like we do with JSON schemas today, and there might be convenient functions to use in your extensions as well, however, it is not obligatory to use in your own extensions where vanilla JavaScript is perfectly reasonable to use. We will have to make sure that all of this is documented adequately for the helper tools made available to extension developers, as we talk about in the RFC 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I'm not a huge fan of Lit because [insert Google's history of just dumping things], but I admit it does really help reduce web component boiler plate a ton, and without something like it vanilla components just take forever to code. But genuinely I think this is going to be a very welcome change, and should keep the back office from growing stale due to a framework choice causing problems down the road. (I for one usually like TypeScript, but I get why folks might find it tedious if unfamiliar.) |
Beta Was this translation helpful? Give feedback.
-
|
I'm just reading through the RFC now, so please forgive me if I only add to the confusion above. However, my understanding from past conversations was that whether you used Lit or not, all UI components were simply web components. If one wanted to, it should be much easier to "integrate" with modern Angular, React, Vue, etc.? I'm thrilled to see this come to fruition. The back office has a lot of low-hanging fruit for substantial performance gains. |
Beta Was this translation helpful? Give feedback.
-
YES, Google's history is unfortunate. That's kind of how we ended up having to replace AngularJS, all right. The key point here is web components. They won't go out of fashion anytime soon and whatever library (Lit) that glues stuff together can theoretically be replaced easily. Or perhaps Web Components evolve making Lit obsolete. This is an exciting future!
Yes, well, usually I find strict eslint rules to be more of a nuisance than TypeScript itself - you can really make life hard for developers with that. I just want to stress the point that going with TypeScript for backoffice development does not restrict extension developers in any way. In fact, the only requirement we may have for extension developers is that they ship their frontend code as an esmodule, but even that is undecided as of yet ¯_(ツ)_/¯ |
Beta Was this translation helpful? Give feedback.
-
Absolutely correct. The runtime version of the backoffice UI is simply a bunch of Web Components/custom elements. Use them in any way you see fit with any library you want. That is the idea at least 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
This may be out of scope, but I had hoped to see a local caching strategy for the Umbraco backoffice. Did any of these teams (internal or community) discuss utilizing IndexedDB as a layer of cache? This isn't a simple request, but done right could reduce the number of repetitious & redundant calls made during the editing experience. Low hanging fruit: caching just a few things like the trees for content and media could end up saving editors a lot of time. |
Beta Was this translation helpful? Give feedback.
-
|
@markadrake Yes, we want to do that, or at least lay the foundation for something like that in the future! The most important thing for the first release is to migrate the old backoffice to get out of the technical debt pit that we are in. We want to investigate how we could prepare for this during development, e.g. making sure that we base the services around repositories so that a cache layer might be injected. But we excluded it from the RFC to keep the scope down and focus more on migration. Some problems need to be solved for caching to work:
|
Beta Was this translation helpful? Give feedback.
-
|
@markadrake caching is an excellent thing to build on top of a great implementation; it does require a great implementation for starters, though, so caching doesn't a crucial corner stone for the entire application. I'm certainly not bashing caching (rhyme unintentional), but I do believe that caching is an implementation detail to be worked out down the road, once a solid implementation foundation has been built. Therefore I think it's a bit premature to start defining caching strategies at this stage. |
Beta Was this translation helpful? Give feedback.
-
|
Before I dig in to the RFC, does it explain why unification of the technology for both platforms using something like Blazor wasn't chosen? It would be great to stay within the .NET world as much as possible. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @argentini Thank you for your question. I have just published another answer to the more generic "why don't we choose my favorite framework" - please give that a read as well. Specifically for Blazor, I can add that there are other reasons as well:
I hope that answers most of your questions. |
Beta Was this translation helpful? Give feedback.
-
Why we are NOT choosing X frameworkI just want to put an answer out there to the question: "Why don't you go with X framework?" as we have been asked that question many times. Umbraco CMS is a piece of software that you install for perpetuity on a given computer/server. It is built with Microsoft's .NET technology, and the .NET Runtime can function on this machine for a prolonged period, eventually failing due to major updates of the OS, which can also be postponed. The current backoffice is built using a series of frameworks and libraries to produce custom elements for the browser. The libraries also control other aspects of the browser such as navigation, animation, and hooks into various APIs of forms and validation. All these tools depend entirely on the browser of the visitor at any given time - now and in the future. All these browsers exist in and consist of a dynamic environment, and that is bound to change. This means that, even though you may be able to install Umbraco CMS on your server and be ensured that the backend keeps working, there are no guarantees that the backoffice frontend will work 5 years from now, simply due to the nature of browsers and their maintainers. Security is another issue; any external library that we install must be maintained and updated regularly whenever a new CVE is published. This is more easily done on an auto-updated product such as a SaaS product, but with Umbraco CMS being an installed product, we do not have that luxury. Umbraco 7 was released in 2013 using the new-at-the-time AngularJS framework. This framework is now considered end-of-life as of January 2022 and will no longer receive updates. We can and we will build a new backoffice, but there are a lot of old installations out there essentially risking their safety due to a choice (albeit a good one at the time) we made 8 years ago. We can do better than that. JavaScript frameworks are all doing essentially the same thing: Producing custom elements with syntactic sugar, and also added benefits of having built-in routers, state machines, and stores. The latter can easily be abstracted into a series of minor libraries (if not already supported by the browser). The former (custom elements) now exist as a native browser API known as Web Components. Many frameworks also now support exporting their components as Web Components ensuring, that all components can communicate through a common API. Building our software with Web Components - a native web standard - ensures that our software works and will keep working for at least a longer period than any external library will. The APIs will keep getting updated along with the browser itself, patching any security vulnerability along the way. So why are we not choosing a framework? Because we do not have to 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
Some great resources on Web Components: Build and publish your components as isolated modules All the ways to make a Web Component using your favorite framework |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
Thank you so much and thanks for the feedback! |
Beta Was this translation helpful? Give feedback.
-
|
If you're not using any form of framework, then how are you going to deal with things like data binding, routing, filtering etc. Basically all the features that frameworks provide that handle this? For instance, currently AngularJs makes filtering of data in real-time and two-way binding very simple to achieve. Won't you inevitably end up writing your own framework? Then you'll have to document it so people extending the back-office don't keep reinventing the wheel. This is all non-trivial. Then you'll have to maintain it, fix it etc. before you can even start doing the "proper" work. And if you don't, then people will just start throwing in their own favourite frameworks to packages, which will make the back-office bloated. How are you going to avoid that? I would have thought picking an existing lightweight framework to "glue" the components together and give people something common to use would be a better idea than rolling everything yourself. |
Beta Was this translation helpful? Give feedback.
-
@DanDiplo did you mean VueJs?
Picking one that has a high adoption rate already will prevent that.
Given the choice developers will stick to what they know, so its a given that more frameworks will be used in the future. Maybe it helps a bit if there are examples for the lightweight variants like vue-petite etc. Not saying its the wrong choice, just highlighting some other viewpoints. Also, did you evaluate FAST, the webcomponent framework from microsoft? Since a lot of dotnet devs will trust a choice like that and its already integrated with the various popular front-end frameworks out there: https://www.fast.design/docs/integrations/introduction |
Beta Was this translation helpful? Give feedback.
-
Are you thinking about the fast-components here as standard UI elements, or the fast-element to build new UI elements? We are going to leverage the Umbraco UI Library to build the UI, which is a set of web components designed specifically for usage in the backoffice and other Umbraco products.
Developers today are already adopting a platitude of libraries and frameworks in the backoffice to build their packages, unfortunately. The nature of such an open ecosystem (as the Umbraco backoffice) allowing any arbitrary HTML/javascript to execute makes it possible to both customize to your heart's extent and abuse the system. We want to set a good example by building our own documentation with a limited set of tools, e.g. TypeScript and Lit, and shipping a package-helper-tool to help developers get started building packages/extensions for the Umbraco backoffice. Hopefully, this will calm down the waters regarding having to "learn something new". Our hope is that people will adopt the Web Components standard and get to learn, that you can build Web Components with many different frameworks without having to ship the entire runtime of them as well, so you can in many cases stick to what you know. In any case, just as today, whatever the actual backoffice is being built with will have no effect on what extensions are built with. The runtime that extension developers work up against will be pure javascript and Web Components. The source code of the backoffice will not be shipped with the runtime version of Umbraco and any libraries we have chosen will not be leaking outside our code due to encapsulation, and we will also be running the runtime code through a tree-shaker which will leave only the functions that we ourselves use in the backoffice. Therefore extension developers will have to bring their own libraries and tools to build their extensions (or just build them with vanilla javascript). We will be shipping a package that makes it easy to request a service/context from upstream, though, and we are experimenting with import maps to open up for sharing dependencies, e.g. Lit or SignalR or something else that we might use in the backoffice, so extensions at least won't have to include dependencies multiple times. |
Beta Was this translation helpful? Give feedback.
-
|
I meant fast-element, because I believe that's an alternative to lit. (Again, nothing wrong with Lit, just curious if options from microsoft were considered).
Thats important to have indeed!
Some of the runtime is shipped, depending on how good the treeshaking works. |
Beta Was this translation helpful? Give feedback.
-
Yes, you are right. This blog post contains a comparison between different frameworks and their bundle size to export a Web Component. Lit is something like 5 KB and Svelte ~2 KB for example. By the way, we see it as acceptable if extensions to the backoffice have a 5 KB runtime overhead, but as I said, maybe some of it can be mitigated by import maps, which is still an experimental technique. |
Beta Was this translation helpful? Give feedback.
-
|
That's certainly acceptable. And overall I think a major improvement in general and especially coming from angularjs |
Beta Was this translation helpful? Give feedback.
-
|
React? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @biapar - did you intend to write this as a reply to one of the other answers? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, yes. Will be always Angular the Umbraco BackOffice? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @biapar. The RFC proposes moving away from AngularJS in favor of a web component based architecture. Lit will be used for convenience when building the web components, but the resulting backoffice will be framework agnostic. |
Beta Was this translation helpful? Give feedback.
-
|
Ah ok. I use IBM Carbon React that used Lit Inside. |
Beta Was this translation helpful? Give feedback.
-
|
Great, @biapar. React also allows you to build Web Components. Check out this example :) |
Beta Was this translation helpful? Give feedback.
-
|
This is why I asked about Blazor. It's built-in, and is a .NET/C# technology. We've built whole apps with it, in production, and it's great. |
Beta Was this translation helpful? Give feedback.
-
|
We don't want to have the backoffice being dependent on a web server in the background to run, which leaves out Blazor server-side mode. And in my opinion, Blazor WebAssembly mode is not desirable in a dynamic runtime mode and would make it hard for extension developers to interface with our services unless you rebuild the backoffice every time you install a new extension. |
Beta Was this translation helpful? Give feedback.
-
|
The front-end is always going to be dependent on a website, otherwise it won't be able to do anything anyway. And you still have to build the project every time you add packages since they're all in nuget now. So based on what I know at this point, Blazor Server is still a good option. |
Beta Was this translation helpful? Give feedback.
-
|
There's a number of places I could make this comment related to the new backoffice. So first want to say that I totally support the idea of a web-component based backoffice - which I've been a fan of for some time and also presents some great opportunities. As someone who has engaged recently with a lot of elements with the backoffice and how it's constructed - the idea of just a general wholescale rewrite is very appealing. When I've been diving into the code of the backoffice I generally spot a lot of inconsistencies and areas where things have been pieced together primarily because they 'work' to some extent but haven't been consistently labelled or applied in the same way. Take for example the different sections from Content through to Settings - inspecting the left hand column and reviewing the code really highlights some of these inconsistencies where components that look the same and do the same thing - are not coded in the same way. So this approach is really most welcome...but.. What I would like to see is more methodology in the approach. By this I mean adopting a set of principles on how the components and hence backoffice is written. I've already seen some areas that to me, represent problems going forward. I'm a huge fan of BEM for example which represents a method of providing a descriptors to a components respective parts and if done well - how it fits together - something that really makes for improving the experience of trying to identify how things are scoped and put together. I'm not arguing necessarily for BEM - but I am suggesting a similar approach be adopted. I totally support the idea of avoiding frameworks - but methodology is distinctly different to framework (although often some can conflate the two). Lastly putting my accessibility hat on - and very much related to the previous point - everything needs to be built according to accessibility principles. This will impact upon the direction you may wish to take with areas - and will require some real thinking 'outside the box' - but at the same time it represents a real opportunity to put Umbraco ahead of the pack. The point being - and something that after chatting with some people who just don't 'realise' the ambition - is that the whole backoffice should be usable.. not just the editor experience.. but everything. Being blind or having some other impairment - shouldn't be something that prevents you from being a developer - and hence we need to remove anything that may represent a barrier to that ambition :) |
Beta Was this translation helpful? Give feedback.
-
|
Hi @tiffy74 Thank you so much for your feedback! Accessibility is top of mind for us as we proceed with the project. We will also be involving the Accessibility Community Team along the way Regarding methodology. I hear what you are saying. We are currently not far enough to put any method into the RFC, but we will work something out that fits our needs. Working with Web Components and shadow DOM has its ups and downs in this regard; with the isolation of CSS we do not have to worry too much about the problems that something like BEM fixes, but naturally, we have to stick to some guidelines. One thing we have experimented with is splitting components into container components (with business logic) and view components, which allows for much easier testing access and UI documentation. We are very much open to suggestions in this area. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to give my point of view regarding security. I would like to request to research the possibilities of having the new backoffice fully Content-Security-Policy compliant. If we can do this, then Umbraco will be the first CMS (99% sure) that can be used for even the highest security requirements and this will be of huge benefit to the Cloud and Heartcore services as well. Google paper (and bible) |
Beta Was this translation helpful? Give feedback.
-
|
@PascalIcatt this is super interesting 👍 and super awesome to raise awareness! Would you happen to know if web component isolation on its own helps along this way, or if we should be doing additional things to achieve this? (Disclaimer: I'm vacationing and didn't dig into the "bible") |
Beta Was this translation helpful? Give feedback.
-
|
Hi @PascalIcatt Thanks for bringing this to our attention. I'm pretty sure you can already set a pretty strict CSP header on whatever web server that hosts Umbraco/the backoffice, but "unsafe inline" in particular is probably not going to work on the current backoffice. Using new tech for the frontend and separating the server and client with the new backoffice allows us to avoid doing stuff inline with the new backoffice. I will make sure that we add an item to the backlog to research the possibilities of different CSP values. |
Beta Was this translation helpful? Give feedback.
-
|
The RFC has been accepted and merged 🎉 Thank you all for the input and feedback - it's been fantastic to see the level of engagement and you've really helped sharpen the RFC for implementing the new backoffice. It's a good foundation for the work ahead of us. You'll hear a lot more about the project in the coming months! |
Beta Was this translation helpful? Give feedback.
-
Request for Comments: The new backoffice
Read the full RFC document here.
Back in March, we began talking about the implementation of the new backoffice. We also promised that there would be an RFC concerning the project, so today we are happy to announce that the final RFC (Request for comments) for the new backoffice has been published!
How do I contribute?
You do not have to understand the proof of concept or any of the technologies to contribute. The most important thing is that we don’t want to miss anything, so everything goes in terms of clarifications, questions, suggestions, and so on.
Please do the following things if you want to contribute:
A little bit of history…
This RFC is the culmination of three other RFCs where we initially outlined the project, then went on to describe the need to build a UI library, and lastly, defined what the extension API would look like.
Read more here:
This RFC is the final one for the backoffice, and you could say we are finally gluing everything together to present how to do the actual implementation of the new backoffice.
The new RFC
This RFC consists of a document with the specifications and a proof-of-concept application you can download and try out for yourself.
The RFC document
This document touches on a lot of subjects regarding the implementation of the new backoffice. A lot of choices need to be made for a web application, and we have tried to talk not only about those choices but also about what it means to the CMS as a whole.
The proof-of-concept
We have decided to publish a proof-of-concept application along with the RFC document this time around. The application can be installed and run on your machine, and you can read the source code freely. The application demonstrates a few things on how to implement the backoffice, namely:
Read the RFC in its entirety here and make comments down below 👇
🗓 The RFC will be open for comments and considerations until Friday the 29th of July 2022 and will be evaluated (accepted/rejected) thereafter
Beta Was this translation helpful? Give feedback.
All reactions