 All right, well, thank you everyone. Everybody can hear me okay, right? Good. All right, I have four kids, so I'm very allowed. If it gets too loud, just let me know. So thank you everyone for attending the Ain't Nobody, Not Your Mama's Headless Drupal Showcase. During this showcase, we will be discussing and demonstrating some of the remarkable ways that Drupal can manage, operate on, and display distributed domain and non-domain content regardless of how and where it is stored. So before we get started, I just want to take a quick poll of the folks in the audience. How many developers do we have here today? My people. How about project managers or program coordinators? All right, you guys are all right too. And finally, do we have any business development people here? Not a one, so I can keep talking fast. All right, so although today's focus is going to be on bodyless Drupal, I just want to take a few minutes to talk about the sort of headless Drupal we will be touching on this a little later. A headless Drupal application, as many of you may already know, does not deal with the display of the content. Authors and editors populate the Drupal database and file systems with content. And they also use other internal, external, or third-party applications to display that content. Drupal 8 makes this very easy through core support of RESTful web services and contrib modules like JSON API. I do want to make one very quick promise to everyone. I'm going to do my very best to work in every possible David Lee Roth reference that I can think of, and now it all makes sense, right? Okay, so now for the moment, you have all been so eagerly waiting for. First a little... You guys left that in there on purpose, didn't you? That's not supposed to be there. But now I look at this guy, I think I prefer the first one better. So just a little bit about me. In addition to these stellar credentials, I'm a developer with quotient, Inc. I'm 15 years into my 40 years to life sentence. I mainly work with federal clients, but I've also done some hard time with educational institutions and some commercial customers. All right, so is everybody ready? Ready? Yeah. Wait. Look, I know it's only 11 o'clock in the morning, so I'll give you a pass on that one. So is everybody ready? Yeah. Okay. That's how we do it. All right, so what we're going to cover today is we're going to start our epic adventure by setting the stage with a cursory overview of one of our clients. We're also going to delve into the major problems we addressed. We'll take a look at the setting or the constraints, and finally we're going to work our way through the typical solution, the alternative, and extend the alternative to incorporate a little bit of headless action into the mix. And finally, we will be taking a look at our experiences in implementing bodyless triple. All right, so first, a little bit about our client in a very nondescript, non-informative way. So IT in general is not an inexpensive endeavor. Costs extend beyond dollars spent buying hardware, building or buying new software, and managing systems evolution. They also include user training, lost productivity, morale. So think about the last time when you had to learn yet another system. They also include integration support, and the list goes on. So when one of our clients came to us with a not so unique problem, we began to think a little outside of the box. The client had invested a substantial amount of time, money, and resources into creating a centralized data repository containing millions of digital records. These records were contributed and managed by departments across the entire organization. All of these departments also had their own databases, flat files, static websites, and were using their own non-drupal content management system. So to answer the problem, we're actually going to begin with a very few important questions. First, how are we going to leverage all of this domain content to build a website that not only provides the best investment of their existing systems and storage solutions, but also minimizes the disruptions typically caused by introducing new systems into existing processes? We don't want content maintainers to have to learn yet another content management system that they don't have to. So how can we also accommodate all of these external systems? And can this solution offer clients who maybe haven't a way to transition to an interim, intermediate, or long-term Drupal solution? And we all know that's what they really want. Okay, so for the setting, we've got our data. Oh brother, do we have data? And it's everywhere. But the client already has well-entrenched processes around this data. So in this instance, wholesale migration is not an option. Remember that ROI and disruption stuff we talked about earlier. Finally, we are bound by the client's infrastructure. Fortunately, that infrastructure supports Drupal. So let's take a look at a typical vanilla Drupal solution. That looks pretty familiar, right? So the typical solution is to go all in with one system. For example, we would do a mass migration of existing data into Drupal. But that can be disruptive, expensive, and can waste those previous investments. It could be a good idea on the other hand, if the client needed or wanted to deprecate legacy systems. So how's everyone doing so far? Are we bored to tears yet? No? I saw some so-sos. So we'll keep going. Feel free to throw things. If you have a question, I want to make this more of a collaborative thing. I hate talking to people. I like talking with people. So just raise your hand, yell. I do a lot of things. All right, so let's go ahead and shake this typical solution up and look at the alternative. So a quick word of warning here. Don't get hung up on the names. We've given things names that we find mildly humorous, kind of like this presentation. But they're useful. So trust me, it could have been much worse. I wouldn't be able to stand up here and give a thought-provoking session about something that I called topless. So what we're talking about at an architectural level is different ways that Drupal can be used to solve problems. So so far, this looks exactly like the typical solution. Vanilla Drupal, right? Thank you. I'm going to wake you up. But we are missing one key ingredient to this recipe. Remember all those gobs and gobs of data that we talked about? So a bodyless Drupal application does not store or manage the domain content. Rather, it accesses domain content and data that is stored in some other location. So it makes no difference whether your data is retrieved from a repo, a database, a file system, API or even that terms of service violating server you connected using grandma's ISP connection. I see some guilty faces out there. So while I'm standing here with my back against the projector screen I bet you want to see what I mean. So we might as well jump into a brief demo. David Learoff nailed it. So we're going to take a few minutes to dive into the code here and what I really want you to focus on is how few lines of code this actually takes. We're doing all of this. This base example with around about 100 lines of code and all of these examples will be available through the GitHub repo. I failed speaking when I should have done that. So first we'll take a look at the back end of Drupal and this is going to support our bodyless solution. What we've done is we have a very small module that uses the form API and this provides us content editors and authors a way to edit external data. So what this example is using we're going to use a text file that lives outside of Drupal and that's going to be a representative of our external data. If only it were that easy. So what we have here is the typical Drupal admin form to edit the content and we will go ahead and just edit it slightly. So what happens with this is that we've actually edited the source data that lives outside of Drupal and when we go into Drupal we're going to use the front end to render it which is the bodyless component of this. So when I refresh the page we are actually pulling in our external text file and now we can see that forever more David Lee Roth will be a rock god. So that's a pretty simple solution there. Representative visually of how we're doing things you guys want me to go ahead and dive into the code a little? I'll leave the choice up to you. I thought so. So we can see in our bodyless solution here all we're running with is a controller we have a very small template and the typical Drupal 8 setup files we have routing an empty module file and the info file. So we'll start with the routing first. Very standard way of doing it we will let Drupal drive the path to our bodyless application reference our controller and in this instance that blanked out the title. As we can see here for the module that is just a simple theme hook and the standard info file we also have the extent of my front end experience in this template I mean this is pushing it really pushing it and the important part that we're going to look at is the controller and this is it. So you can see within 33 lines of code and about 14 lines of comments how many of you get paid by line of code? This is perfect. We can see the one function that we call is just using the rudimentary PHP function to read in our external file and then pass that on to our wicked awesome template. The thing you want to obviously customize in this solution is adding in the way you get the content so this is where you would put all of your logic to connect to the external systems APIs and things like that. You're going to have to speak up. The admin form. That is down in the bodyless and headless section. So this is where we're going to get the content from. So setting up the form is also very easy. Just because this was a text file we needed one text area to edit. So we have the typical form API set up here. We're also doing extensive validation. And our submit form all it does is write the data back to the flat file. So while this isn't a complete example of what we're doing I'm going to keep begging you until somebody asks a question. Do we have any questions yet? So we've gone through our bodyless demo and that's good if your client wants to continue using Drupal as the front end. But we want to extend this a little bit and to include some of the headless stuff that we've been hearing about yesterday, the rest of today and some tomorrow and Friday. So what if your client asks for more beyond the typical Drupal website? Maybe they need things like kiosks, interactives, IVR or another lightweight framework they want to put on top. So in this instance an application can be both bodyless and headless. And there's a running joke in our office that this is what we call soulless Drupal. So let's take a moment to explore how we can stretch Drupal even further. And what we're going to do is we're going to cherry pick the pieces of Drupal that we want to use. Drupal is the framework. But the framework is only used for performing CRUD applications. So those are your create, read, update and delete actions on domain data. The domain data is stored elsewhere which makes it bodyless. And it's delivered via non-Drupal front ends which makes it headless. And they access the content via restful web services API, or bypassing Drupal entirely. So now we're going to take a look at how these types of application level Drupal. I do apologize I couldn't think of a good David Lee Roth reference for this transition. So if you're still humming jump in your head we'll just go ahead and stick with that. So let's dive right into the bodyless and headless Drupal demo. First I'm going to go ahead and show you how that works. You remember our form here and the bodyless example. What we're going to do is edit that one more time just to prove to you that it works. And we'll go ahead and submit that. Now powering this bodyless and headless application I just spun up a very quick Node.js app. I'm not a Node.js developer so if anyone else is here please don't judge me. And we can see we have our Node application here and with the simple refresh now we can see that yes David Lee Roth actually is a rock god. And it's proven by Node.js. So let's take a a little deeper dive into this example here. So we've seen the form for the administrative side already so I can skip over that one. This one is a little bit deeper. Now we have the routing which allows us to edit the external file and creates the form or gives us a route to the form. We also have a path in case we wanted to check this against Drupal just to make sure. We've also added some permissions to this one so now we will limit the people that can actually edit the content as well as view the content. We've added in links to the admin and what this one does is it adds that tab to the content page so if we go back to Drupal editing content, sometimes it's easy to give users authors and editors a visual cue if we're dealing with a lot of data we will segment these into tabs across the content screen so it's just a little bit easier to get to than routing through all the content. And of course we have our info file. So this is the main meat behind our bodyless and headless application on the Drupal end. So you can see we're pulling in the text file and we're leveraging the form builder again down here to create the form and then when we look at the we've already seen that one but you know what why not do it twice. This one is actually for the bodyless one. So the only thing that's required for this one is the form API because we are not using Drupal to render it, we're not using Drupal to store the data. We have our sample JSON file here, see I told you I don't do Node.js. All this one is doing is it's going out and rendering the file through a file read. And that's pretty much it. We have now completely torn the soul out of Drupal. I hope you're happy with yourself. Okay. So those examples look awesome but the real question is does this really work in the real world? So if all this seems a little far-fetched like a bunch of geeks just trying to have fun here's a very condensed version of some of the real client work we've done for the past four years at Quotient. As you can see Drupal 8 is not required though it certainly does make the job much, much easier. We've been doing this for years using Drupal 6 and 7 and this was long before headless and bodyless were known as things. So the answer to does this really work is yes, of course it is, why wouldn't it work? So the beauty in bodyless solutions is that you do not have to migrate every project you encounter and quite often you don't have to reinvent the wheel, you can just swap out that hub. Excuse me. So if you find yourself looking at rebuilding one or more legacy applications or working with distributed or disparate data take a look at leveraging that existing data first and wow your clients with the efficiencies you can achieve by going bodyless. That was very exciting wasn't it? Thank you. So I know we have tons of time left again it's because I have four kids I yell a lot I talk fast I have to. So if there's any questions out there sure actually we have a microphone. Four, yeah. Oh well that was your one question. We've done that. The good thing about this solution is very flexible. So you can link nodes to external content. We've done that for repositories so we'll have sample nodes in the database and they link out to external content in other systems. You can also leverage existing APIs for multiple locations at the same time. What we would typically use the Drupal database for in that instance is we'll do some pre-processing of the data in the business logic and Drupal basically stores the throwaway display data. So it can get refreshed and it doesn't matter it doesn't become the organizational content that the organization relies on. This is actually out on github if you come over to the booth after we're done I'll be there for a while we can go over in some more detail. I'll show you where the repo is and it's out there now so nice little starting point sure well that was one of the major problems that we had discovered along the way into crafting these solutions there's a lot of time and effort and training that goes into learning a content management system so when you have things users using like SharePoint there's a ton of processes around those as far as checking in and out files managing workflows and it really gets into any content management system as well not just a document repo. So what we do is we leverage the APIs that are available through those systems and we link to them through Drupal we do our pre-processing post-processing in there the benefit of that is that there is minimal disruption to the user community that's already using these content management systems so you don't have to retrain them on Drupal they can take their Excel spreadsheets and upload them to Excel's spreadsheets go in the ether and things like that so it's highly flexible in keeping the existing processes in place we come in and provide the solutions that kind of bolt on top of those so it's not as disruptive as coming in and ripping and replacing the entire system. So my question is if you click on the content tab there will be a list of all pieces that are leveraging the bodyless piece and then there's a separate tab that you go into the node element or whatever and then there's a piece that's rendering that content but you can also edit the existing body tag and wrap around that as far as in the admin or in the display well in the display so you click on your node edit you'd have two tabs one for the actual content stored in Drupal and for the content stored in your text file is that possible? Yes you can definitely do that but what we wouldn't do is edit the external content directly we have done that on certain occasions but if you're editing the content it's best to edit the things that are going to be from the front end forward and leave that external data alone that's why we import the things we need to import apply the business logic, stick it in Drupal and then dump it and not have to worry about it we can just re-import it again through whatever nightly process we're using yes what we're doing is we are leaving the proprietary organization data where it is so if someone's using SharePoint for instance we'll stick with that one all of the documents and the data live in SharePoint what we're using Drupal for is pulling that data in for display purposes only and in certain instances we will apply some business logic to it and that's the data that we store so it's a version of the data of record but it's not the data of record it could be the other benefit of this solution is that the authors and editors and marketing people can still use Drupal to use their marketing stuff so that kind of data will live in Drupal but the organizational data will be outside of Drupal this is Mike by the way there's too much invested in working with that people are used to it you have decades of folks who have invested the time it's part of their performance evaluation part of their review process to be efficient to use that it's the mechanism of leveraging that investment that kind of as Paul said not being disruptive so we've seen it in a couple of forms we've seen it in Java applets that folks are using off their desktops we've seen it in access forms working against SQL servers or ODBC connections we've seen it in weird frame maker workflows where they've got a process that's taking information out of SQL server processing that for publishing the actual printed publishing workflow getting it in the frame maker pushing it through they can't change it, they can't touch that they would disrupt everything and on the website they want it to be accessible they want it to be usable, visible this is a way to avoid kind of duplicating it we had it, we're already paying for SQL server let's put an interface together let's get it up there let's do what we need to do we can do some text processing maybe there's some compliance stuff accessibility stuff that we need to do before we render it so those are kind of the use cases where this solution has made a lot of sense Paul's also kind of mentioned that throughout these processes there is this inevitable question of at what point do we start to put or store some of that content into database into Drupal's database we've seen a couple of different situations where it starts to make sense maybe the stuff we're getting out of SQL server isn't written the same way that they want the content to appear on the website with a few edits to the modules we can flip a switch where they can start to change that content so the workflow goes from just being displaying it to actually storing a version of it in Drupal that can be manipulated maybe we add a sub-process to actually send that back to SQL server there's lots of different ways that this can grow iteratively as the workflow for our customers evolves and changes and embraces it kind of the other thing that Paul alluded to was what we have found is this works really well for large enterprise government, higher education institutions that have a lot of data tens of millions of records that are stored in systems that it's just not cost-effective to change but as they hire new people to join their team with more of a web focus those folks are comfortable with web-based CMS's they're comfortable with Drupal or WordPress or what have you this is a way to get that ball in motion to formally reorganize the workflow and process over time so what we've also done is we use this to set up authoring environments that use Drupal's interface something that they're already familiar with from websites or something they participate in outside of work we can actually give them that interface that modern interface browser-based to manage the content in the official domain repository and over time that may become the preferred way to manage the data so there's a lot of different kind of branching out points the examples that we put together here are really meant to serve as just basic examples of the idea it's not meant to be a reproducible module that everyone can put out there but it's something that for us has been really powerful going back even to Drupal 6 and Drupal 5 is a great way to develop interfaces for folks so that's where the strength of this alternative to the traditional migration comes from that's all right now we have a line of questions I think he answered a lot of my what I was really going to ask is what's the business value in doing this what does the company hope to get out of this and you mentioned that are comfortable with the CMS what are the business value permissions central management of permissions what is this type of migration by a company the beauty about this solution using Drupal as the framework is that you can customize and cherry pick any piece that you want out of it so you can continue using the permissions you can continue using routing if you want to any of the APIs the only thing that we're most part getting rid of is the MySQL database that's the disposable piece of it so in your example you're taking out a particular piece of content and you know exactly what that content is going to be I assume you've had examples in the past where you needed the Drupal site to say filter a specific subset of content or perform some sort of dynamic logic I'm sure it depends on the system you're connecting to but in general in your experience you've done this a lot of different times with a lot of different systems have you found it easier to perform sorting and business logic on the Drupal site or to try to hook into whatever that other system's business logic is in order to pull back only the data that you wanted so it depends great answer I knew it so in some cases we take advantage of middleware we do a lot of work that involves Apache Solar Lucene as middleware but we've also done a lot of work with kind of handling those types of routines on the data repository side so using the example I mentioned earlier, Framemaker and SQL Server and all that we actually ended up writing a very thin .NET application that gave us a web service interface to the content but gave us a framework to do some of the other applications that we wanted to do by doing them on that back end side we took the load off of the front end servers we made it easier to kind of scale horizontally we've had situations a few years ago we were working with a customer they had a massive archive of discussion lists and they use various technologies every time mail in, Piper all sorts of different things like the Oracle record going back to the really 90s of these discussions and they didn't want to lose that but it wasn't cost effective for us to come up with a migration pack to put that into Drupal and there are some limits to that there are some efficiencies to be gained like we can search it and that kind of thing if they were to be nodes but the return and the cost wasn't quite there this was back in Drupal 6 days we left those files alone we left them on the file system we wrote a module not this similar to what Paul has here that read those files off the file system did some cursory clean up so as you can imagine going back to the 90s HTML has changed we were able to kind of clean it up sanitize it make some compliance and accessibility changes it was fast enough we didn't want to fly but we also elected to actually write those files back to disk and in that way we kind of dynamically grew a replacement over time and as soon as Google or Bing or somebody searches it and crawls it it's going to generate it for us anyway but it kind of allowed us to take what would have been a month long process of iterating over a migration script and condense that down to a few days of work so thank you so Drupal relies a lot of the views and displays and layouts and all that stuff it relies on really highly defined fields and when you look at something like say something horrific like co-fusion where you got as an editor sorry the person that tends to jam everything into a big HTML block and I've dealt with trying to migrate this content and it's a real nightmare so how do you deal with going from a very loosely defined loosely defined data to bringing it in in a useful way into Drupal yeah we've done the static content migrations as well but I think what Mike had just spoken about kind of speaks true to that if we take co-fusion that's going to output HTML so what we would typically do is use a crawler to determine what the rendered output files are and then dip right into the process including those external files doing the preprocessing cleanup or anything like that and using Drupal to display those and theme them what we try to do in these situations is go back to the faster components of PHP so any of the C standard library string functions you know we try to solve the problems with those first you know regex is kind of if we can't figure it out but if we need to do a lot of manipulation to structure content XML, HTML then we'll use DOM processing library the nice thing is because of the way that we kind of structure the solution if it's something that we can't do efficiently in PHP we can usually do it on the data repo side since typically that's going to be Oracle Java .NET C sharp SQL server some cases co-fusion so what we've done in the past and we had one example of this many years ago they continued to run the co-fusion site behind the scenes on their network, off the DMZ off the internet and we actually just edited the templates for that site so that it spit it out in a structured way and that actually allowed us to grab that content as if it were a web service without it being a web service it allowed them to continue to use that site, that's what they were used to using but we were able to put some structure into it that we could hook into much easier much more easily on the front end and in some cases we do pull it into Drupal as well back then Drupal 6 it was CCK but fields you can use field formatters you can use entities if there's something that makes sense to break out and to kind of put into Drupal the first sort of party citizen we can do that otherwise you're kind of left with having to come up with weird views books or search API books to kind of integrate everything together so there's not one best way I guess I would say that it happens it's a value content platform we've got to weigh all of that together sorry took your time my question is around GBI so have you guys implemented this so most of our customaries most of our customers use Google search appliances even today or they're using digital dev search so they're using hosted search solutions so most of the time what we're working against is an external crawler indexer we have and we did this a while back for customer leverage gosh this was not before I think search API so it was the Apache solution module and we used Tika and so we actually we're still able to even though that content didn't live in Drupal as nodes we were still able to use the modules to push it into what the Drupal search in this case which was a solution index but those hooks exist they can be used the real question that we've had to ask is and again this is more Drupal 6 Drupal 7 but is the Drupal full text search an accurate or the best way to track the data typically there's already extenuating circumstances for our projects and solars in the picture or there's some other service that's in the picture of course I know I was not prepared for that question I should have been come meet me down at the booth and we'll talk about it a little more because that's what I know alright looks like everybody's as brain dead as I am so thank you all for attending thank you enjoy the rest of the conference we'll discuss any more with us we're downstairs booth 125 all the way against the wall almost all the way down we'll be there through the ranger we'll be there I don't feel tired we'll be there we'll be there