I'm working with a client who does not wish to expose any database to the outside world. [It's a hard requirement that cannot be argued away.]
My thought is to prop up the umbraco back end within their network, and then publish out the site (without the DB and connection string) to the public server.
Umbraco headless isn't an option, as they want to self-host.
I've read Jason Deacon's blog article (https://www.wiliam.com.au/wiliam-blog/decoupling-umbraco-and-asp-net-mvc-5) and found it helpful.
If I understood correctly, it is very proper separate the frontend application (umbraco app) from the core app that will hold all the logic for your client. Just use UmbracoApiControllers to talk to your frontend app.
I have had the same issue as you where clients want to self host and decouple the front end from the backend, and for that I have begun developing my own version of a headless api: https://github.com/deMD/UmbracoContentApi
Currently the Nuget package contains the Core project with the converters that can convert all default umbraco editors (except Grid) to something that is easy for clients to consume (for example I resolve crop urls, and convert content pickers to a specific object), as well as support to extend or replace converters. Inspiration for the document structure comes from Contentful.
This is not an Umbraco issue but a networking issue. Just develop the website like any other Umbraco website. If they want to self-host the website then there should be a network (or system) administrator who can set up the required network infrastructure for you.
The more I look at these requirements, the more I'm thinking I need either a hybrid approach or the ability to publish a static version of the content stored in umbraco. The content management team needs access to templating and document type features. There may be some need for some more advanced programming (search and the like), but that could likely be handled with JavaScript and JSON files.
Again, you are overthinking this. You don't need to do anything special with Umbraco. This is what your customer is asking for, lots of hosting companies work in the same way:
Kinda depends on the definition of "publicly accessible".
If it's just blocking people from accessing the dB in general, this is fine, but if you want no dB at all on your public server for security reasons, then static site generation is a viable option.
Heck, beyond security alone, static site generation has many other benefits including faster page loads and cheaper hosting infrastructure.
Funny you should ask, I'm giving a talk about static site generation at DUUGFest in a couple of weeks (dunno where you are located whether you could come along?).
Ultimately you'll want to convert Umbraco into a headless system. You can either do this writing your own API controllers, or you could use something like my headrest package https://github.com/mattbrailsford/umbraco-headrest (which is what I use).
With that, you could set the site up locally and then build your front end using a static site generator. I'm a vuejs guy so I've been using gridsome for my demo https://gridsome.org/
With this, you'll have it connect to your local site instance to grab the data and compile to static html. From there you can deploy those independently. You can either do that manually or you could setup some kind of build server to trigger automatically on publish to build and deploy. Not sure if it would work for your needs, but I'm a big fan of netlify for deployments, but your CMS would need to be externally accessible for this.
This looks great, Matt, thanks! Unfortunately, I'm over in the States, and just started this job last week, so I doubt international travel is in my immediate future. Any chance your presentation will be streamed or posted later?
Quick question for you: which branch of umbraco-headrest should we be pulling to work with v8? I went with develop by default, which is clearly the wrong choice. Is wip/v8 viable?
Do we need to stand up an Umbraco 8 instance and then apply your code to see how you handle the backend? I don't see anything Umbraco in my initial look.
I'm using an Umbraco cloud site so the code for that is separate. All of my custom code though is in the backend GitHub repo and is compiled and copied to the cloud project.
You'll need to customise my code though as it's all specific to my doctypes. It also uses the models builder plugin to generate my model classes.
The code isn't meant to be used as is, rather its an example of an implementation.
In a traditional Umbraco site, the organization of content in the back office is all about the page. Does that go away with a decoupled site? How do you organize your back office? Does it become more about related fragments of content? Especially if your goal is to reuse the content across multiple front ends?
As is often the case, the answer is really "it depends".
For building decoupled "websites" where you want the editor to be in control of the site structure, the existing hierarchical structures will work well enough.
If however you want editors to only be responsible for creating content and the structure is fixed, or you want to connect to an app and you want to treat the data more like content repositories, then yes, you may move away from tree structures into more content repositories instead.
Both are possible within Umbraco and so it will depend on how you want to use that data.
I do see the pattern though in other CMSs that are predominantly built for headless access that they tend to be more repository based. So I do wonder whether that is a more flexible approach. It does require you and your content editors to think differently though, thinking in "content" rather than "pages'.
Best practices for decoupling Umbraco
I'm working with a client who does not wish to expose any database to the outside world. [It's a hard requirement that cannot be argued away.]
My thought is to prop up the umbraco back end within their network, and then publish out the site (without the DB and connection string) to the public server.
Umbraco headless isn't an option, as they want to self-host.
I've read Jason Deacon's blog article (https://www.wiliam.com.au/wiliam-blog/decoupling-umbraco-and-asp-net-mvc-5) and found it helpful.
Any thoughts, suggestions, or best practices?
Hi Andrew,
If I understood correctly, it is very proper separate the frontend application (umbraco app) from the core app that will hold all the logic for your client. Just use UmbracoApiControllers to talk to your frontend app.
Hey Andrew,
I have had the same issue as you where clients want to self host and decouple the front end from the backend, and for that I have begun developing my own version of a headless api: https://github.com/deMD/UmbracoContentApi
Currently the Nuget package contains the Core project with the converters that can convert all default umbraco editors (except Grid) to something that is easy for clients to consume (for example I resolve crop urls, and convert content pickers to a specific object), as well as support to extend or replace converters. Inspiration for the document structure comes from Contentful.
It might be of use to you as well :)
Thanks, Dave! I'll take a look.
This is not an Umbraco issue but a networking issue. Just develop the website like any other Umbraco website. If they want to self-host the website then there should be a network (or system) administrator who can set up the required network infrastructure for you.
The more I look at these requirements, the more I'm thinking I need either a hybrid approach or the ability to publish a static version of the content stored in umbraco. The content management team needs access to templating and document type features. There may be some need for some more advanced programming (search and the like), but that could likely be handled with JavaScript and JSON files.
Any thoughts?
Again, you are overthinking this. You don't need to do anything special with Umbraco. This is what your customer is asking for, lots of hosting companies work in the same way:
Kinda depends on the definition of "publicly accessible".
If it's just blocking people from accessing the dB in general, this is fine, but if you want no dB at all on your public server for security reasons, then static site generation is a viable option.
Heck, beyond security alone, static site generation has many other benefits including faster page loads and cheaper hosting infrastructure.
Exactly. I cannot have the DB on any public server. Sorry for the confusion, Steve.
Hey Andrew,
Funny you should ask, I'm giving a talk about static site generation at DUUGFest in a couple of weeks (dunno where you are located whether you could come along?).
Ultimately you'll want to convert Umbraco into a headless system. You can either do this writing your own API controllers, or you could use something like my headrest package https://github.com/mattbrailsford/umbraco-headrest (which is what I use).
With that, you could set the site up locally and then build your front end using a static site generator. I'm a vuejs guy so I've been using gridsome for my demo https://gridsome.org/
With this, you'll have it connect to your local site instance to grab the data and compile to static html. From there you can deploy those independently. You can either do that manually or you could setup some kind of build server to trigger automatically on publish to build and deploy. Not sure if it would work for your needs, but I'm a big fan of netlify for deployments, but your CMS would need to be externally accessible for this.
I've not written my solution up yet, but I build a demo site using these techniques https://nullorwhite.space/ the code for which is on GitHub. The backend code to configure headrest is at https://github.com/mattbrailsford/nullorwhitespace-backend while the front end code is at https://github.com/mattbrailsford/nullorwhitespace-frontend
I'll try and write up a blog post after my talk, but in the meantime, you know it's possible and you've got some code you can now poke around.
Matt
This looks great, Matt, thanks! Unfortunately, I'm over in the States, and just started this job last week, so I doubt international travel is in my immediate future. Any chance your presentation will be streamed or posted later?
I think it might be recorded, but failing that I'll try and write up a blog post afterwards.
I'll keep you posted 🤘
Hey, Matt-
Quick question for you: which branch of umbraco-headrest should we be pulling to work with v8? I went with develop by default, which is clearly the wrong choice. Is wip/v8 viable?
Good luck at DUUG!
Andrew
Hey Andrew,
Yea,
wip/v8is the branch you want. It's the "work in progress" port over to v8 so will be merged into the dev branch once I'm happy it's ready.Thanks for the "good luck" wishes :)
Matt
Hey, Matt-
Any update on the blog post? I saw your slide deck, but am hungry for more...
Do we need to stand up an Umbraco 8 instance and then apply your code to see how you handle the backend? I don't see anything Umbraco in my initial look.
Yes.
I'm using an Umbraco cloud site so the code for that is separate. All of my custom code though is in the backend GitHub repo and is compiled and copied to the cloud project.
You'll need to customise my code though as it's all specific to my doctypes. It also uses the models builder plugin to generate my model classes.
The code isn't meant to be used as is, rather its an example of an implementation.
Matt
In a traditional Umbraco site, the organization of content in the back office is all about the page. Does that go away with a decoupled site? How do you organize your back office? Does it become more about related fragments of content? Especially if your goal is to reuse the content across multiple front ends?
As is often the case, the answer is really "it depends".
For building decoupled "websites" where you want the editor to be in control of the site structure, the existing hierarchical structures will work well enough.
If however you want editors to only be responsible for creating content and the structure is fixed, or you want to connect to an app and you want to treat the data more like content repositories, then yes, you may move away from tree structures into more content repositories instead.
Both are possible within Umbraco and so it will depend on how you want to use that data.
I do see the pattern though in other CMSs that are predominantly built for headless access that they tend to be more repository based. So I do wonder whether that is a more flexible approach. It does require you and your content editors to think differently though, thinking in "content" rather than "pages'.
is working on a reply...