 Yeah, so you mentioned earlier the mercury project. Can you tell a bit more about it? Yeah So when we rehearsed it, I kind of thought that that would be the part where you cleft your hands for Josh It's a good question Amitai actually because the mercury project originated at a time When we had a lot of questions the community about can Drupal scale you know this was an unknown there was a lot of fud going around and What that project was for me Was was really I didn't invent any of it. It was me just taking Existing best practices from around the community and putting them together in a way that we could all kind of agree upon and And I think it it basically, you know, I can't claim any real credit for it It was just the really the packaging of existing best practices that really delivered a lot of the value Did that make sense? Yeah, you know, I love that question. It's a really I Actually, I really love that question and kind of makes I get it tingly Don't do my wife is out of the country. So if that question and I could meet in the hotel room That's a subject in question. Do you want to come up here and maybe like do some presenting with me? Kind of unorthodox, but sure. Yeah, okay. Oh, why don't we I think it's really gonna go better with you Gonna do, you know, I'll feel much straight safer and stronger So the couple Drupal what why when and how? We're gonna start off with where we have been Which is the monolithic architecture this is that architecture that has existed in software for decades Drupal didn't invent it But Drupal is a monolith It's typically deployed as one big Wack of code and if you want to scale it you deploy multiple monoliths Horizontally and it's all kind of plugged together in one application And this is the way that a lot of software has been built throughout history There's nothing wrong with monolithic architecture It is one of many ways that you can build Applications and it has some advantages and the fact that like it's all self-contained and you can train on one thing And there's general consistency. This is like 2001 and the apes looking at the monolith, right? And you might say to yourself hey now that's not really true We have a separation in Drupal between the theme layer and modules in core Those are two different layers in the application. So what take your monolith and shove it buddy and My perception is well, it's true that we do have these different layers But that's more a matter of convention than an actual architectural Boundary it's a highly permeable boundary if you think about the way that modules stuff can emit fully rendered HTML into the theme and themes can run queries inside the template file It's a really it's not like a strongly observed architectural saturation. And so when you have a A permeable boundary you end up with an exciting and awkward game of chance as to what will happen I told a joke We find often is that Drupal isms leak to the front end This is a recurring theme in the kind of work that we do and one of the reasons that front-end developers are sometimes So frustrated with Drupal and you have to look no further than things like this, right? This is something that like all of us old hands the Drupal so it's like well obviously of course It's telling me so much about what this template is doing. This is a rich This is rich with data, but if you don't have all the lore of Drupal and the experience crammed in your head This is nonsense. This is kind of difficult to decipher. It's it's obtuse and it's also kind of ugly And you know what happens in 2001 with the monoliths and everything else in the beginning of that movie The apes get really ragey and they start smashing everything and I think that explains some of our front-end developer community's behavior over the past several years You can sense that you know that things are boiling over in their heads and and I don't think that they're wrong I think that they have a lot of legitimate critiques of what Drupal has done So in contrast to the monolithic architecture We have a movement in the web and again It's much bigger than Drupal, but we could consider ourselves a part of that as well Which is the microservices architecture and it's this idea that you can break down your actual Application that you want to deliver to a customer into lots of smaller things that talk to each other and can be deployed and operated independently and this has this kind of potential to be like more elegant and more flexible and potentially more scalable in certain ways and As certain downsides in that you're gonna have heterogeneous combinations of languages and platforms and debugging things that are failing because of network Issues is like the worst thing ever, but there's a lot of excitement about microservices and rightly so because if you think about an architecture that works like this where there is a clear and distinct boundary between the client and The back end the thing that holds all the data and then the client that is consuming that data And it's talking over an HTTP API You suddenly a world of possibilities open up that would have been very difficult to imagine previously and most importantly to me As developers it lets us collaborate in new and powerful ways with a wider audience of potential partners Or you could say everyone gets to rock their own jam So I assume this was remedial for everyone in the room But I thought it was important to mention so that we're all on the same page as we go forward because this is a terrible idea So many things will go wrong if you decouple your site the risks are just enormous and they're huge and they need to be considered so for instance Three words for you, baby search engine optimization It's no longer the case that like a Google won't be able to understand your decoupled site because our page ranking overlords will Execute the JavaScript and render the final results. That's what they tally. That's important Also to prevent people gaming the system. So that's kind of cool But in Drupal we have all of these Modules and contribs and extensions and techniques that we've grown accustomed to which are how we kind of create a compelling output for a search engine and things that happen automatically because the content has been entered correctly and the Modules have been enabled will no longer happen automatically So even though you don't have to worry about Google not understanding your site or having to have some weird static version of your site Just for spiders you're giving up a lot You're giving up a lot and SEO is really important for almost every site on the internet Maybe not an internal dashboard, but anything publicly facing This is a huge concern and you're taking on that responsibility Whoever the front-end developer is to continue to ensure that all those bases are covered And that's really a subset of a larger problem that occurs when you decouple from Drupal Which is you lose a lot of the value of Drupal you leave it behind. So this is the I forgot my password form A quick show of hands I assume we're all developers in the audience who prior to coming to Drupal invented their own quote-unquote content management system Okay, how many people have written a I forgot my password routine How awesome was that not at all And so if you you we can easily take for granted in our rush to the couple and get in with all like the sexy JavaScript stuff We can take for granted all the things that Drupal has been doing for us like providing very like stable and robust Workflows for everyday things that every site needs like what happens with the user forgot the password who wants to write this code again Nobody it's just not exciting There's also this weird sense that in the community floating around that perhaps Drupal and like these new front-end frameworks have just some kind of amazing plug-and-play aspect And you know you just turn on the rest API module and then put angler on your front end And it all just it all just kind of works And I mean obviously when he tells you that you know to like sort of like huh because that's not even how Drupal works Like you don't just plug-and-play Everything together like it's exciting like it as a kid who plays with Legos This is the best Lego set ever, but it's like you step on the Legos and it hurts your feet And you got a hunt for the I got a trade with your friends like I need to I need a three wide too long Well, I'll give you some castle walls for that It's difficult and it's and it's only more difficult when we imagine a front-end that is entirely You know is entirely ignorant of what Drupal is in and of itself that plug-and-play capability Will not be there and we shouldn't expect it to be there That's something that we have to get used to is we want to enter this realm of De-coupled websites or headless Drupal and I start to think that maybe like we're just being led down this like you know a path towards a Rocky edge and this siren song of you know sexy user interfaces and and new things and mobile apps like this all sounds really cool But we're leaving all the beauty of Drupal behind and and we're just gonna all end up reinvending the wheel over and over again We're gonna just build these crappy front-end applications And it's gonna be like we wasted the last 15 years of Drupal development and I think maybe actually I just talked myself out Oh, this whole presentation I think maybe yeah, I think you're not talking straight really I mean, I think you're a little dehydrated. So maybe sit zip some water and you know, just give me a minute So when we So when we are talking about the couple Drupal We're basically talking about there is a Drupal in the back end and some fancy JavaScript library in the front-end And when we're talking about the J the JavaScript world then this to-do app This is like the hello world example. That's the standard example. So what we've done here We've taken the angular JS example. We changed just one line Even that could have been avoided and we hooked Drupal with the rest for a risk for resource in the back end and This is probably an overkill, but this is just an example to show what we are able to do Now don't get me wrong form API is amazing I mean, it's extensible and you get security without even thinking about it And Drupal is already providing you all the forms and and everything But we need to remember that that's 2015 and our clients. They want to have fancy UI So sometimes, you know the node forms are just are just not enough and they want to have you know to streamline the UI and You know we could do it with Drupal I mean We all know inform API limit validation errors And we know that we shouldn't completely remove the title We should make it invisible and I know that there is the C tools adjuncts that I can make those things But let's say that the fact that I'm bold is 95% genetics and 5% related to forms API so So basically what we're saying is that form API shouldn't dictate the experience It's just another tool in our tool set in our toolbox. So instead of those bulky-looking Drupal forms even though we're talking about decoupled Drupal It doesn't necessarily mean completely decoupling you can go that that route But you can also have hybrid meaning that Drupal is actually serving the page and we have like fancy-looking AngularJS components that are communicating with the server through a restful through a restful interface and actually Different interfaces that could not be done or could not be easily be done are now possible Through this idea of decoupling Drupal. So again, this is 2015 These are what these kind of dashboard is what our clients are expecting from and again Maybe you're a super awesome themeer and you could pull it off in Drupal and yet it's probably going to be super complicated But let's get not get ahead ahead of ourselves with new shiny UI JavaScript library Before we are tackling this thing. This is a completely imaginary function Even if you're not a developer don't feel bad about it it's basically a function that gets some entity and Returns true or false meaning it checks if the user has access to that entity and that piece of code is working perfectly There's no problem with it But it's kind of violating some of Drupal coding standards. So let's look at the second version We organized the bits the PHP docs and we changed the true and false to be capital letter And then we noticed that this four liner could actually become in version three one liner And then in version four we actually completed and we had we had proper PHP docs And we even added a third argument called account because we are now thinking in a more API and this version four which Is acting exactly as version one is perfect, right? If I would submit it as a patch, I will Get all the glory and the money that we know that we get when we're submitting a patch and Any little typo over here the wrong indentation I will have to do it again and again That's that's the way we do it in Drupal and then we enable a rest model and BAM we expose our our JSON and Drupal is leaking all over the place. So we have this fill underscore prefix in the tags We have NID which I mean, I don't know what it signifies if I'm not coming from the Drupal world Oh, NID is a node ID and see what is a node. I have to know all that information So one of the things that we've done in RESTful and this presentation isn't about RESTful just showing those concept is Trying to avoid the fact that I don't want the client who is consuming My API to even know that what we have in the back end is Drupal Because imagine it could be no GS go line whatever so When I'm looking at the that I see that it's an ID It's not an NID and it's not a title It's a label and another nice thing about the thing that we have in RESTful if we're going earlier Sorry, we saw API slash articles one again I don't know if it's a node or not know that shouldn't care about it Another fancy thing that we have in RESTful is the slash API Which is actually the discovery of all the web services and this is somewhat very similar to those PHP docs that we have meaning I don't as the consumer of this API of this web service I don't need to go to another site to figure out what are the different resources? What are the different endpoints? I can figure it out here, or if I'm going to a specific resource API slash article with the option 8th HTTP method I'm getting much more information again similar to this PHP doc I'm getting the information about each property which kind of data required not required even the form element So basically I could have a JS front end to dynamically create the forms that will in the end create or update The entity and so what we're talking about here to take a step back the reason to step through the code Is this notion that aesthetics are actually very important for the coupling and because we're thinking about interfaces Between clients and backends or between two different applications and typically in web development when you say interface or user interface Particularly we're thinking of something that's on the client side of the browser That's it's something between a human being and a website It's like the web browser rendering HTML and making something visual that I can see and type and click But actually any user experience any user interface is a stack There's a stack of things that build up to being able to deliver that user experience, and I think about one of the things And and and every output throughout this stack should be nice And we care about this a lot in our own internal development in Drupal core and in well-maintained Contrib modules whereas Amatai showed we can be pretty particular about the structure of the functions and that functional signature And the way that you do the documentation because that's important If we want to use those fundamental pieces to build great things on top of them the interfaces that they explore Expose the way that they communicate further up the stack should be clear and should be expressive I think about one of the things My homeboy Mark Sonobom says when he picks a bone with PHP in general is that the biggest problem with PHP Isn't that there's wonky things in the language and triple equals and variable variable candy flipping and whatnot The biggest problem is that there's just a lot of code that's written in poor taste and that we don't have a great sense of Aesthetics and I think in internal to Drupal We've got some of those things right, but I think as we begin to confront the headless Drupal the decoupled Drupal movement the Possibilities we have a chance here and now to get something really right so that we can build really beautiful things in the Future when we think about that layer that when you stop playing twister and start having a real Interface between your back end and your front end. We don't necessarily just want to throw all of Drupal through that interface That's not very kind to the people who are on the receiving end of of that of that Communication and if we want to empower people who will be on that receiving end who are you know developers potentially from other Disciplines and other walks of life to be very successful We want to make it so that they can kind of understand what's going on And it feels good and natural to them not that they feel like they have to go and learn Drupal in order to write a front end for it And I think if we can keep this consciousness as we begin to explore and develop how and when we decouple our Applications our future selves will thank us for it quite a bit Because what we're gonna build is gonna be amazing right? It's gonna be like so Unbelievably mind-blowing it'll be like we've gone through the looking glass and new things are possible and old People you know people will be saying oh back in my day We used to have an admin interface and you would have to click every time something happened And that will no longer be the case because we'll be we'll be through the looking glass And and we really need to open our eyes to the possibilities the insane Possibilities of what's possible as we imagine Drupal's place in a wider ecosystem of software And we are gonna be opening our minds with the help of a tie through java script not through drugs correct So a year back in Drupal con When we discussed headless Drupal, I was asking the question or raising a question Which is if I would tell anyone in the audience over here a developer or a site builder What is the proper way of creating a list of nodes in your Drupal sites? Then the de facto answer is views because that's the standard and then my second question is What is the standard for or which library should I use to do a login in a fully decoupled? Headless Drupal and obviously there was no answer because there's no standard So what we've done is we've attempted to create such a standard through a yo generator a yo man generator Which basically this is something that is used in the JavaScript world We're typing yo Hadley. This is the name of this project. It asked me a few questions. It what it's doing It's actually scuffles a full Drupal backhand a full Front-ended client with Angola JS with some nodes and examples And it's ready to work with with one with one command It's a fully working example and what we're getting is actually you're seeing here the client side where I have this login So this is in a way maybe not the standard the final start that that the community will agree on But this is a suggestion and invitation for two community to collaborate. Thank you And basically you log in and you have this application Which is working in those markers are actually representing nodes and this switch companies actually organic groups in the back It's all those nodes and those different models that we're using and this is actually opening the doors Not just for the standardization, but also for our crazy experiments like for instance when I Ask when after I've done it I asked myself. Well, I have a decoupled Drupal Fully the couple do I actually need the browser at all because you know I I like working with the terminal So I hooked up a few JavaScript libraries and over here. It's asking me. Where's this Hadley Drupal sitting? I give it an answer and I have this terminal Information you see here. This is real This is going into the Drupal server and it's asking it the information and if I would change the location on the node So it will be updated on the map and seriously if you even if you have just one percent of geekiness in your body This is experiment would probably make you super excited. Even though this experiment is probably completely Absolutely useless. I don't know Maybe and I'm not sure maybe there is some value in in such an experiment I would actually go so far as to say there's a lot of value in this type of experiment Because I think what we're at talking about here writ large is not just some awesome technical demos And some some great stuff and then we resources will post to the the session so you guys can run You know Hadley in your own sites We're actually here to talk about the future of the web and Drupal's position in the future of the web I think that it is unquestionable that the future of the web is a world with an increasing number of APIs that are integrated and increasing variety of devices that are used and if you think about the I mean if you're skeptical you can look at the way that things are moving towards this sort of internet of things Context and there will be more and more things and people and devices and stuff out there both emitting and consuming data as part of the work that we are all involved in and Drupal's place in that is different than Drupal's place in the past Drupal's place is is more as a hub and more as a connector and more as an integrator of these things and not as the monolithic Drupal does it all. I think if you had to ask yourself If I were starting web development from scratch today, would I start with Drupal? And for me it's very hard to answer yes to that question to be honest because if I was starting web development today I would start with some like crazy new JavaScript stuff because that's where a lot of the action is happening and you look at like statistics from github and JavaScript projects have the most active committers the most active projects the most sort of Development work being done and it's not like Drupal's fallen by the wayside or anything The internet is growing the number of web developers are growing and people are naturally drawn to the cutting edge of things But if we think about the future of the web as one in which monoliths are Concreasingly looking like dusty relics from the past Drupal's role in this future is is to be a connector is to talk to different things And that's why this model of decoupled Drupal or headless Drupal is so exciting And and it's an exciting time for Drupal because we'll be able to build more interesting things I was actually It's funny this guy over here is wearing the t-shirt. I was in Las Vegas earlier last week and there was a AngularJS conference there and I had a really interesting time talking to all the developers They were showing showing off some really awesome stuff That was like, you know offline data synchronization So you could be disconnected from the internet and use your app and then when you got back on the internet would sync everything up looking at you know tools to embed these these UI that you build for the web directly into an app without having to go through some super bulky phone gap nonsense So there's a bunch of exciting stuff happening in that space And they're working out all these all these amazing problems, but then when I talked about what they use for their back ends They're like, well, you know kind of got this Mongo thing that I hacked together or somebody had you know just tried out this this node.js thing. I hope it works and There's a there's a real gaping For everything that we're talking about where we want to standardize how Drupal becomes decoupled We want to standardize how we interface with front ends and sort of make some of these questions settled on the front-end development side They are desperately or badly in need of good solid answers for how to standardize on their back-end needs And when I talked to them, I'm like, oh, if you thought about using Drupal, they're like now what Drupal? That's some kind of old website tech, isn't it? And I explained Yeah, it's been around for a few years. Okay, but this is cool Uh Still got it But I explained oh no because they're actually quite good Interfaces now for Drupal that expose it as a as a REST API goods, you know It's like elegant expressive restful API and if you use that as your back-end, you know You get an administrative interface for free because you've usually had to build that at the last minute because you never thought your client wanted it until right and And and you get something that's actually kind of battle-tested that has like a pool of Thousands of expert practitioners that can help you with it if you need that rather than some custom hack sauce that you know an intern put together for you You get some ability to utilize security access control There are back-end capabilities for doing advanced things like internationalization Even though you'll probably make your front-end smart to think about that and and then they get really interested like Oh, I'm gonna have to really take this Drupal thing seriously They don't even know that this stuff is possible And it's because we are like we're still in the early days of Drupal figuring out how it wants to be decoupled and what that means for other people And I think that this is super exciting because I think we actually can legitimately make Drupal a like as we talk about Angular and you know yeoman and these other tools become weapons of choice for us We can make Drupal a weapon of choice for the emerging front-end development community And we can become good partners with them in open source and that'll take us into new markets It'll take us into really exciting use cases and it'll let us build some really fun freaking awesome stuff And I think that that's you know as somebody who's been involved in Drupal for going on 13 years The you know I know a lot about Drupal at this point maybe more than I want to know and I know what I love about Drupal And I know what I hate about Drupal and it's okay to have things that you don't like about Drupal because Drupal is not amazing at everything the the kind of the the the the most Destructive expression of the monolithic mindset is that like you've got a Drupal hammer and everything looks like a Drupal nail And that's not the real world like I think that's what's so great about what we've been doing with this latest release cycle of Getting off Drupal Island and thinking about like decoupled architectures Is that we realize that there is a much wider community that we are a part of like we are not the internet we are an important part of the internet and We recognize where we're strong and where we should actually look to partner with others to build things that are gonna be You know more and more and more exciting So you have something important you want to talk about though Yeah, so let's talk about live monitoring and visual regression for testing for a second and bear with me for 70 seconds It will it will make sense so one of the problems that we figure out we have in In Gizra is that well we write tons of tests and we have Travis and we do a lot of work to make sure that every Comet is properly tested and then we deploy our site on the live site And then we just hook up ping domain to it or a similar system that basically just ask the site every minute Are you okay? It's getting a 200 response and all is great in the world But if something is breaking on this on the site, you know just because bad code or even you know If the kids Balai has hacked your site like they did for Drupal dot org. I L Pink dummy. Yeah, sure. Everything is fine. I mean what can possibly go wrong? And this is something that we figure out that we we want to solve so we've taken also this path of the visual regression testing and The visual regression testing is basically the theory is very simple. You take a screenshot of your site over here We can see a screenshot of a tweet a Twitter page and basically we are removing this Dynamic part or excluding them meaning this this black rectangle and then I'm we can compare it this baseline Images to new screenshots We are taking all the time and in theory it sounds really really great But in practice what we found out that it's really really hard. It's so hard that in a sense. I think well, we've I Think nobody's actually doing it. We didn't do it up until now just because it's so hard And the reason it's hard is because let's say you're taking the baseline images of let's say ten different pages And you want to compare those pages on different browsers on I Chrome and Firefox And you also want to check different breakpoints of responsiveness and suddenly you have like 200 images that you need that you need To maintain so this shoe is about helping you to maintain those images So whenever there is a Regression which is a legitimate regression you just changed your code and you know You moved the logo a bit in two pixel and this is actually the something fine Then you're able to select the new image and to create a pull request it's tightly coupled with github and the thing is that This is super powerful This is a super powerful tool, but nobody's using it just because it's so hard So what we've decided is to have this shoe this shoe dot IO? Fully open sourced project put out there just so we try to get a solution and try to get standardization meaning the An approval from the community that this is the right way to do it and in a way What we see about shoe and what we see about mercury and what we see about headless Drupal It's it's kind of a mindset. So if we're looking at mercury So a couple of years ago Josh and his folks realized that there is a problem, right or Drupal can't scale or is not fast enough and what they've done They didn't invent everything. They just bundled together Different best practices and they contributed a few best practices and then 20 million dollars later We have Pantheon, but it's not to just Pantheon because because in fact we have different hosting Providers and actually Drupal itself is already using some of the information that we got there So in a way all those problems that we have or we can actually call them challenges When we fix them meaning when we ever when we read the point that the community has validated Validated them as a proper standard then we actually can advance as a community and once we solve it We actually it leads to the to it leads us to the next is exciting things right now It's you know because the couple Drupal But once we'll solve it once everybody in the audience when we ask them What's the proper library to log in into a fully the couple Drupal once we'll have that answer? You'll no longer see five sessions about headless Drupal on every Drupal con because the community will advance to the next Exciting thing that we would like to solve And so for those of you who were hoping to come to this session in here on hittamata And I explain exactly how you do all this stuff successfully every time. I apologize That was probably maybe our session title set a little bit lofty even expectation What we're trying to do is show what is possible and and what is meaningful and what is worthwhile and in the spirit of these Other projects that we've talked about in the past kind of a call to arms to Standardize as a community on a way of doing things and we're proposing certain values that we think are important in Standardizing around the way that we'll do decoupled Drupal the idea of an aesthetic and expressive API that it is in some ways You know the achieves these values of self documentation and so forth We think that's important for us to gain traction The idea of building tools that allow you to rapidly scaffold the applications at least for prototyping and testing so that we can put This power in more people's hands and not have to have them go through a really long and painful learning curve to start to see Some of the wind the idea of putting together a compelling case for Drupal as a back end of choice as a weapon of choice For the emerging front-end use cases that are out there in the world Those are all things that we think are fairly important if we want to see these types of use cases thrive, right? We'll still regardless of whether we are not we do that as a community Like regardless of whether or not you know I had I never put together project mertury tag on consulting the ex the true and acknowledged experts in performance would still have been able to make any Drupal site scale and Whether or not we do this as a community the great shops like Lullaby could still build you an amazing decoupled website But I think we want to get to a place in the future where many of us are able to build amazing De-coupled websites where this is something that the Drupal community actually has down cold It's not a question of this is like the cutting-edge rocket science that only Superstars can do this is something that all of us have our hands around and we have accepted community best practices as to how you get started and the types of things you want to do and so in terms of the Conclusion of this it's really a call to arms to all of you to join us whether it's on the Drupal group Whether it's in a boss session here at the conference or whether it's just online on Twitter. You can tweet it up And at this point I'd like to introduce this is Amitai. He's from Gizra. Hello And this is and this is of course Josh from thank you And and we're happy at this point to take any questions if you want to go to the microphone there that we showcased at the beginning Somebody has to go first because because then it's easier for other people to go if you can close the door, please We have ten minutes and nobody's allowed to live So It is you're good. So you touched on the restful login earlier as a good example of Something that we could potentially benefit from And it was funny because I was actually talking to a co-worker earlier who was in another session and basically had that exact question of You know you're talking about EPI sort about login and of course the answers well Drupal handles that and it's like well What if you're not using a Drupal front-end? So it was really nice to see that this is a common problem. So what other Issues besides login. Do you think we could potentially be encountering when it comes to headless Drupal that we can solve in a Standardized way that maybe we haven't even thought about yet Yeah, so Tons of problems basically I think what just illustrated earlier with this silly example about forgot my password You don't even think about it because you know when you install Drupal It just works and suddenly you need to take care of everything So it's definitely headless Drupal is not the silver bullet that well everything will will work properly What we're trying to do in terms of standardization is that instead of you know each company Solving and reinventing the wheel over and over again. We know how to collaborate. We have the means of doing that So whenever you solve that the first time they forgot my password we can all learn from that and basically Be friends now, I'll extend that a little bit. So Amitai is a You know in the best way of the Drupal community doesn't try to promote himself But the module that he and his colleagues created restful drew for Drupal 7 I think really industry illustrates a better way of putting restful APIs on Drupal for the future because they have it has that expressiveness to it It has a great developer workflow around it It has the idea of versioning built-in and it's not just exposing Drupal over Jason And so I think that's something that we should think about for Drupal 8 because the core rest module Doesn't quite go that far yet and we'll have to think about as a community thinking Well, what if we want to do more than just expose Drupal's internals over Jason? We need to think about like a good processes for making that easy for us to manage as developers The other thing that I would throw out as a major challenge that it goes back to form API is Figuring out a way to try to capture some of the value of form API Especially from a security standpoint So like coming up with standard ways to be able to deliver the form token to the front end so that a submission can be Validated on the back end you probably want you want client side validation too because I should fail fast if stuff is missing But from a security standpoint that token validation process if we can come up with like a dialed in way that we all just use That stuff to solve data submission from the coupled front ends. That's gonna save like Hundreds of thousands of people hours over the next couple years as we build more of these sites So we didn't discuss it what but we actually have a solution There's entity validate and it's integrated with restful and yeah, so it's there again. That's So you're saying it's just plug-and-play and it all just works and we just That's the thing Nobody knows about entity validate or very few people know it's not like the views It is the standard it is the the proven solution only once the community Accept it as the as they accept it as the proven solution. So So maybe we'll try that more yes So you kind of just answered my question, but I'll still say it just just in case But so the call to arms that you just guys basically just had Asking you know we need to standardize these things is it are you Where is the work to be done is is the work to be done on exposing more things that Drupal can do to the client side? Or is it standardizing the client side how we do things? It sounds like it's on the Drupal side, right? I think for the most part it's on the it's well like look if I'm making the call to arms here at Drupal Con like raise your hands if you can you can develop Drupal really well Right now raise your hands if you can develop decoupled front-ends really well So a few people so that's the audience right and so the thing is like To be honest if you look at like take a step back and look at the market The front-end space is just moving so super fast that like I don't think there are so few experts in this community of They're like at the angular thing They're like they're getting ready for a major upgrade But maybe angular isn't even where it's at maybe it's all about ember or maybe it's about react or maybe it's about backbone And all like these are all great answers So I think we just have to show what we can do and do so in a compelling way first amongst Ourselves to get our story straight and then I think we promote it more so the outside world Like I was really super stoked to see the to-do Example that that Amitai put together that was just an idea that I threw out like six months ago Where I was like, hey, you know if we wanted to really make Drupal and decoupled Drupal Resonate with these people. There's like the to-do mvc.org or dot.io Web page is like that is their standard There's like 47 different JavaScript frameworks that you can implement a to-do in but none of them include a back-end Right and so if we can say here's a way you can start to include a back-end in these kinds of things Then that's a very simple way for us to like take up a non-trivial but still very bounded use case and Learn ourselves what we want to do with it But then also showcase that to the front-end community and say hey Maybe there's something over here and I think internally also one of the things We have to do is the Drupal community is raise up our front-end developers very frequently front-end developers have kind of gotten a little bit of a short shrift and I think we need to reverse that and that starts with all of us to say we need to take the front-end really seriously That is where a ton of innovation is happening and front-end developers should be heavily respected within the Drupal community So it's mostly on us. That's what I'm saying And then If I could just spam it spam the mic one more time real quickly just for advertising purposes But if people want to get involved in helping this kind of stuff, where do they go? Yeah, so I'm Really good in delegating stuff You'll come to me and six months later when you provided tons of pull requests and stuff like that We can talk about the next assignment We there's a there's a group on Drupal that I mean that this is one of the things where we've talked about this And I've talked about this other people like there's a there is a movement occurring But it doesn't actually have a center of gravity yet And that's one of the things maybe coming out of this conference. We will create so it could happen right here tonight Well, probably not tonight, but tomorrow it could happen. I have a specific question on shubhio the tool for automated UI testing What is powering that and specifically what is the algorithm behind hiding certain page elements from the comparison? Okay, I go over it quickly because it was just more about the even though I'm super excited about shubhio I could talk about it one hour or less I'll do the last part So basically shubhio is itself headless headless Drupal, but that's just an implementation detail It's completely agnostic to the to the technology you use to do this this visual regression testing It's just a container for you to push the images Specifically right now. It's integrated with web drivers CSS This is something that's an open source solution that's developed by sauce labs And there are quite a few if you look we have maybe the links of the resources or we'll add it in the Gisra blog There are three different posts that shows repository examples Code examples that you could use just starts there and if there are questions you can tweet or catch me and I'll answer it directly When you were talking about What would be the views of decoupled Drupal? I thought I thought you're going to talk about You know views in the sense of lists of you know results coming from database or something We Has anybody here used xjs? we've used a lot and I think it has first of all a very a pretty mature decoupled data exchange model, you know between the server and and the client and caching and bi-directional exchange of data and so on for multiple providers And it also has a pretty nice Forms certain equivalent of the client-side forms API and it's an open source project. So it's just It's the interesting thing to look at for what what you're thinking about for this Yeah, so even though I think highly of myself I'm still not a community meaning The fact that I'm standing here doesn't mean that I give the the validation to things in a way It's like everything in open source. It's the popularity So if people right now angular is the popular what would be the next thing? I don't know so and I think people will consider it only when they're real examples So if you think about it if you want to use another JavaScript library Go ahead hook it into into a Drupal back-end put a blog post and then we can start talking about the smaller details So outside of this community I've spoken to other people who have negative impressions of Drupal based on previous experiences They've had or things other people have said or blog posts that they've read that a lot of the time are out of date Or maybe they are you know true What's the way we can piggyback on up-and-coming cool stuff like angular and get Drupal out there again The Drupal name as something that people want to use I think we'll do that by piggybacking on cool stuff like angular No, but seriously that that's part of the opportunity here I think that Tactically we need to showcase more of the capabilities. I think that we need to present Drupal And that's one of the reasons again why I love the restful module because I it's the first time I've seen something that presents Drupal in a way that front-end people will actually be enthusiastic about rather than grudgingly accept perhaps like and that doesn't just talk about like decoupled use cases like the From the keynote this morning the Mark Bolton redesign of Drupal 7 Do you remember like the epic rant about how there were just too many divs and he couldn't even can't I can't even And it's because like you know for for me. I'm over back and develop. I'm like that's just some extra divs It's not really doing anything, but to a front-end developer. That's just like you've just like yeah Let me just put extra keyboards on your desk and like pile some shredded paper you can still do your work right and And it's not good for them It is it's a bad experience because there's all this cruft in their way And so I think for us it's about showcasing that Drupal can be a really fun thing for front-end people to work with and then Building some really sexy examples like that go beyond the to-do like that the example I think where you should with the head Lee hooked up to the terminal that like you got spontaneous in clause because whoa your eyes your pupils dilate when you see something like that and And that that's true for for front-end builders to and and with examples like that we can grow our community We can start getting more people from the angular Vegas conference to come to Drupal con and build those I hate to keep calling you about it. Just ironic And we can build those alliances build more cool stuff cool stuff turns into blog posts and tweets blog posts and tweets turned into more People looking at it and that's just you know That's the virtuous cycle that we want to have in an open-source project. So we got to just execute basically Hi, I'm brand new to Drupal and we are thinking of going with Drupal 8 headless and Also deploying an application in a headless mode, which is we have our angular apps deployed on our ships And on the shore sides So we don't know whether Drupal 8 is the right way to go But we're thinking by looking at all this and all the session that we have attended Drupal 8 is the way to go because as you mentioned There is no good back-end even though you have a good UI or good presentation layer But there is no good content management saying so do you think like it's a good idea to go with that? Yeah I think if you're billed like unless you're planning if you're planning to launch in the next month Drupal 8 might be a risky decision, but it sounds like you're just starting now So that's probably that you're gonna have a multi-month development cycle And you're gonna be able to take some time through that and Drupal 8 does include in the core of Drupal a rest module That's okay, and it does a lot of great things out of the box more importantly I think for this context that's a proof of cons I would look at the rest module and core is kind of like proof of concept implementation of what having a real HTTP router in Drupal is and there's like a ton of possibility like I I spent a lot of my The last couple two three years actually writing a bunch of Python code because I had to write a giant API With my team at Pantheon and the what you're capable of doing when you are writing with an application that actually talks HTTP rather than responding at paths with blobs of HTML is like light years better And you know you've basically back ported a bunch of functionality with the restful module to 7 But I think having it in core in Drupal 8 will allow us to build you know That's kind of like we're building for the future with that So I think if you're thinking the long term about your application you are in a good space to be thinking about Drupal 8 Do you think like it has a good push mechanism using like an active mq rabbit mq or something like that? What you'll need to do for that. Yeah, you you need something else Yeah, so if you can push to a q or you push to like a You can push to red is you could push to node there are a bunch of people that do push notifications off of Drupal sites That's a fairly common use case at this point. Okay. All right. Thank you sure Okay, two last two questions So There was the real maintainer of restful model. I'm just taking the credit, but this is the real maintainer of restful model Mateo from Lullaby So my my question is that I saw slide that I like particularly But then when you said that decoupling is not such a great idea because you're missing things like I know Translating your UI we have the defunction, but we don't have it when we when we decouple so and on the other hand we talked about Getting an API that is Drupal agnostic so we can separate all these concerns about how to do things So my question is we are getting these Conversations started on how to make these standards on doing these these problems like logging Passing in meta tags back and forth or translating the UI But at the same time we're saying that we are not going to be opinionated on what the Backend is because we're building good API. So where should these communication communication channels happen To to get the like all these cool JavaScript technologies like react angler whatever I Realized that I said that English cool again But yeah, so where should this happen should this happen at Drupal con should this happen at other higher spheres or So I think that there's a conversation that we are trying to start or really we're trying to continue this conversation It's already happening. We're trying to continue and and energize this conversation that happens here about what our role as Drupal is in this and and our role as developers who maybe can also learn these new front-end frameworks And I think that we are it's maybe a little bit early for us But soon if we can get stars our story together and get our demos on straight Then we can actually take this conversation to those communities and we can start reaching out to them We can say hey look at this example. What do you think? Could you build a better example than this using this back end and I there are a bunch of tricky things about how much we Want to standardize one of the things I would throw out as an idea is One of the things that won't work is we try to figure out all the problems right away we should probably pick a subset of the most common problems and Then find like the intersection of the highest value and easiest to solve and just focus on nailing those so that really like we can Take a serious step forward Rather than trying to imagine the ultimate way of doing a decoupled Drupal or the ultimate answer to all the questions Of what do you do with the missing functionality from the Drupal back end? I don't know if you I Told you you just need to invite me to Mallorca and we can discuss it Over there, but yeah, I totally agree with Josh I think I think what's what we're doing with restful for example is Trying to set the standards By you know, just putting it there and We just and I think we reached the point that the community is already picking up restful And we're seeing more poor requests and stuff like that So if nobody asked us about translation, maybe there isn't such a need yet So I don't know. We're on the same boat there. All right last question. All right Okay, so last year I was in the boff with you I was there and I talked about a Drupal 7 site that I was building at the time that was using headless and So that's launched since then and it's been successful I think Rather than this isn't a question This is more of I wanted to give some ideas around why what will help us promote this is you know I think like you're talking about making Drupal kind of like a standardized back end for for this sort of stuff is selling the The idea of I know this is kind of counter to how Drupal is intended to be used these Content and configuration living together the power of field the field API And the UI behind it with content gives you the ability to quickly and rapidly build a back end That can expose how you want the front end to render it And I love what you're talking about with with basically turning Drupal into a a neutral API that doesn't expose Drupal, but exposes the content And in the same way the configuration can be exposed in there, too I think One of the greater things that we need to deal with is routing routing is a big problem because people want to be able to route things Variety of ways and you've got Drupal's own issues with you know How paths are generated and you've got to be able to expose that in a natural way to the front end so Having a lockdown standard for that I think would get us really far because that was one of the questions that people are following me and around the Asking me was how do you deal with routing? How do we know what nodes? How do we get you know? How do we have pretty URLs that make sense and work with path auto and all this good stuff, you know And you have to think about it. It's not hard to do But you have to you know having those answers That's that's something we need to have locked down and I'm glad that you've handled login because that's another question I got asked today actually for this. How'd you deal with login? Well, actually never got around to it I didn't need to But I'm glad you've done that because that gets back to form API, you know having Solid documentation behind how we integrate with web forms or entity forms or whatever We need those things. I Fully agree, but this can all be only be done not through theory But through you know people sitting geeking out and producing code and others reviewing that and that's how standards are created Yes, absolutely. So yeah, those are some of the things I think we need to work on and Yeah, I saw some of that in my own projects, but I was Drupal 7. I didn't use Rest of us. I actually wrote my own module that does something similar, but I love rest of us too for other things So this is all good. I mean, it's awesome to see this went from a little boss in a tiny room to you're doing a presentation on it Who would have imagined? So keep it going. Yeah, no, obviously this is again, we'll keep this conversation going We're happy to chat not on microphone with people and otherwise, you know people want to get up and stretch your legs You're free to go now. Thank you again. Thank you Do the dance again. Yeah, you were in the zone Worked out pretty well well done sir I Yeah