 help for you to do your homework. You can log on to this site and some volunteers will be available for you to get help with whatever you need. And for this, we built a queue system and a chat system where you can talk to some advisors. And originally, we built this on triple six and it worked fine for a while. But as we got more and more users, we were seeing a really intense load on the database. And I'd like to walk through a bit of why I'm supposed to speak into that now. There are some situations where PHP and the model, its execution model is really not a good fit. Drupal is slow. That's hardly a controversial statement here. As anyone who's needed to have a large scale Drupal site has known there are performance challenging aspects of all the nice stuff that Drupal does for you. It's not that Drupal is bad, it's just that all the advanced functionality you get from Drupal comes at a cost. And PHP doesn't scale for certain things. And I'm going to go a bit into computer science here, but I'm going to try to explain what it all means. But basically, PHP is synchronous, it is single threaded, and it has a shared nothing mode of operation. And synchronous single threaded is like, you could say, the worst of both worlds. It is a very simple way to do things, but it also tends to eat a lot of server performance. Any modern computer is like a four lane highway. You can see each car is like something being done on the server. And it's not very, it's very common to see your highway looking something like this. It's actually just standing around doing nothing. It's not really using all its capacity. The same goes for PHP, actually. This is what you might see if you inspect what a PHP process is doing at any one time. The dark blue areas is where PHP is actually doing anything, and all the other stuff is where PHP is not actually doing anything. And it spends time waiting for databases, waiting for web services, waiting for the request to come from the Apache server. And all the while, it actually, the PHP process is running and it's eating your memory doing nothing. So the main thing that Node.js does is actually to try and fill in the spots where one part of your program is not doing anything, allowing another part of your program to do something in the same time. So it's trying to use your resources more efficiently. And hopefully, that also means that your server will run faster. This is a picture of another large website we are running. This is what the server is spending its time on. And you can see the large green areas is waiting for external web services. I don't know if you can read the bottom text, but basically, on any given Monday, we have like 150 Apache processes standing around and using 16 gigabytes of memory. And most of the time, they're actually just twiddling their thumbs. Like a third of the time, they're actually not being used because they're waiting for something else to happen. And that's, you know, that's a huge waste of resources. Anyone could tell you that. And the picture is about the same if you look at the CPU. We're not really using the resources we have to. And conversely, to run the site, we have to use a humongous server to have all the RAM we need for doing this. She had nothing. That's the PHP way of doing things. It's like your server is completely retarded. Every time you ask it a question, it's like give me page two of the front page. It starts all over again asking, hey, who are you? Where are you coming from? What's the side name I'm on? What database am I supposed to talk to? Okay, let me go talk to that database. And all this happened every single time anything happens on the page. A whole lot of work. And yes, it can be a good thing. Yes? Are you trying to ask a question? No, she's just counting. Sorry. Right. Well, yes, that is not specific to PHP. But it is a problem of the way PHP works. And it's many, in many ways a good thing because you don't have to worry when writing PHP programs about memory leaking or anything like that. Because whenever your request is done, the PHP Apache server throws everything you've done away. All the hard work you had of asking the database for something or whatever you've done, it's like, you know, some offices, they have shared desks. So every time you leave, you have to clean up all your stuff and put it in your back and go away. It's a bit like that. It's a very simple model, but it also brings a lot of overhead. And the reason it was made this way was that PHP was originally not intended to have all that much going on on a single page. So you didn't need to keep all sorts of state and logic around. But when you're building something like a chat service, you actually need to have a lot of stored states about what users are online and where they are in the queue and what's going on and what chat messages are waiting for someone else to pick them up. And for all that, you have to stick stuff in the database and get it back out again. And at the chat site, in example, it was peaking around 1400 MySQL queries a second when we had like a normal evening with homework help. And that's about the pain point for MySQL. It's hard to scale it much further than that without, you know, and at the same time, we were actually getting complaints that the updates were slow because we were only pulling back to the PHP server every five seconds to see whether there were any new messages. So you actually, if someone wrote to you, it could take up to five seconds before you actually saw what they wrote to you. And when you're chatting, that can be kind of inconvenient. And of course, if we decreased the polling time, we would just increase the server load. So that wasn't really a good way to go. And PHP was never designed for this. One of the more exciting new developments that's been on the web is something called web sockets, where your browser makes a persistent connection to the server. And the server can then send stuff back to your clients without your client having to ask it again. Anyone who's built anything like a chat service in PHP knows that you have to continually ask the server, hey, what's going on? Hey, what's going on? Hey, what's going on? But with web sockets, you can actually do it the other way around and actually just open a socket and wait for the server to tell you, hey, something new has happened. I think that stands to reason that that is much more efficient. It's like taking a drive with your car and having your kids screaming all the while in the back, hey, are we there yet? That is actually very rare for you to answer yes to that question. So it wouldn't be nice if you could just make the kids be quiet and then just tell them when you're there. That basically is what we're doing with web sockets. I know the point in favor of doing stuff with Node.js, and this is very specific for Node.js because Node.js is written in JavaScript. So imagine any one of you has probably dealt with having a forum on a website and having to validate the input to that forum. And as we are getting more and more dynamic and age-action and stuff like that, you actually need to have validation on the client because it's annoying to have to fill out the whole forum and click submit and wait just to have it tell you back, hey, you missed this field or the address must contain a number or whatever, whatever. So more and more, we're starting to implement validation on the client, but we actually still need validation on the server because when you're doing your validation in JavaScript, anyone with just a little bit of knowledge about JavaScript can actually cheat that. So you want your validation to run both on the server and the client. And with Node.js, you can actually do that. You can use the same exact code on both sides, and everything just works as it's supposed to. And you can do this with all your business logic, basically. So it's also when you are having performance problems, you can look into what kind of work your server is doing. And if you're doing a lot of string parsing or juggling XML or whatever, you can actually push some of that work to the client and say and send some more raw data back to the client and make the client do all the hard work for you. That's actually free resources in your server center right there. So that can be pretty sneaky. And that's all very nice, you know. But how do you get it to talk to Drupal? Having just a separate server abby thingy is not really all that helpful. So we've actually helped build some tools for that. The simple way, of course, is to just communicate with the Node.js server via the REST protocol. That use case is actually also kind of common. Imagine you have a third-party web service that you need your site to integrate with. You need to provide some data from a third-party source. So you could actually just load that over to Node and make Node do all the hard work with that. Because PHP really has a lot of overhead for doing stuff like that. Imagine if you're just taking the incoming parameters from the client side and passing them on to a server somewhere else. And if you do that within Drupal, you'll actually have like 300 milliseconds of Drupal starting up. And a lot of waiting while the web server responds. And a lot of, you know, and it's all using memory at the same time. So that's the, yeah, that's more or less the same cases as in the beginning, I explain. Using your resources more efficiently. But if you want your Node installation to actually interact with Drupal, you need some way of actually checking that the user you're looking at is actually the one. I don't know, can you read this? More or less? Well, the gist of it is that we've made a Node.js module that actually is able to interact with some parts of the Drupal database. Mostly the simple parts. We don't get into, you know, fields and constant types and stuff like that. But looking at users and permissions in our experience actually gets us what we need. Because most of the time we're just interested in finding out who is the user and is he allowed to do whatever it is that we're actually doing on this page. And this is some example code that does just that. If you want, I can dig into the Node.js module for Drupal a bit later. And a demo of that. My code, well, basically, you can see the website here. Long passwords, great thing. This is not very exciting, anyways, but the thing you can actually see behind the scenes if we look what's going on down here. It contacts our Node.js instance. And here we have our Drupal session ID. And that is actually used to authenticate the user. And because I, in this, lots of fun. Because in this instance, I'm logged in as an admin user, I get this interface that you can see here, that's a list of helpers online and a list of users waiting for help. This is actually not very exciting without any actual users online. That's the basic gist of it. And we have the same code here. Where was it? Yeah, down basically here, we use the admin flag to grant the user more permissions. And this is the Node code that actually runs this site. A more complex example is actually a product we've been working on in the last few months. Basically, it's a DNS control panel powered by Drupal. And imagine, let's bring up the network control panel so we can see what's actually going on here. And you can see this is not a joke. We're not fooling you or anything here. This is actually the actual response time of our Node.js servers from this very location. We're going out on the internet to a server here in Germany and asking for something and actually getting a response back in 43 milliseconds. That's more or less, you know, 10 times less than we would have taken if we were using it inside Drupal. That's the main, you know, the main interesting point about it actually. Let's try something a bit fun here. And you can see consistently across these requests to our API server, which is running Node.js, they all take less than 100 milliseconds. And the main, most of that time is actually talking to the database itself. And, you know, that's beyond the scope of this demonstration tuning that. And you can see, oh, yeah, wrong domain. Fun like that. Any moment now. The internet here is a bit flaky. But you can see actually the few actions I just did in there are updated real time across our network of DNS servers. And all this is actually powered by Node.js. Node.js is really powerful for doing all sorts of small simple tasks. We have like three or four different Node.js apps, one that handles syncing to the web servers, one that handles rendering the zone files and all kinds of stuff like that. So that's, that's, well, we're, I'm very excited about, you know, being able to provide my users with an interface that's so responsive that you don't actually have to wait. You know, if you can get beyond, get below like 200 milliseconds, it'll feel instant to your users. Other exciting thing that we actually haven't done much in practice is what they call RPC. You might think that is a very nasty word. And some RPC systems in the past have actually been really nasty and complex. But when doing RPC with Node, you're basically just creating a small server that is prepared to, you know, provide some, some functions you can call from the other side. So if, in this case, we are creating a transform function that, you know, replaces all the vowels with a double O, I don't know for what purpose it's, but, but you can imagine doing something on your server that is a lot more complex than this. And you want to, you're wanting to expose that to another server because doing it this way will actually save you from having to write an API on the one side and having to write a client on the other side. So this is a way of side-stabbing all, all that hard work. And you can see the results of doing it in, calling the same function in PHP. It's, it's pretty simple. You just connect to the, in this case, we're using a library called Dnode. And it has language bindings available for, besides its native Node.js, it has bindings available for Python and PHP and Ruby and Java, I think, and other obscure languages. And that actually means that you can build some functionality on, on one thing and, and have other machines using it without having to make, do a whole lot of work around it, basically. And you can pass errors back and it's, it's a, when you were, it, you might not have, have done all that much of, of this kind of stuff. But when you have like five servers that need to do something together in concert, this is actually pretty powerful because it goes both ways. So when you're, when PHP connects to, to the Dnode server, the Dnode server can actually call back to the PHP server and tell it, hey, what's going on? You know, I just updated the, the whatever record. So for distributed systems, this is awesome. See how much time I have left. Other implementations of this kind of, this kind of thing. And the example I showed you before, we're actually using something called now JS, which is a precursor to what is now called bridge. And you can see the basic logic of, of all the stuff is here we are assigning, we have a, you know, there's need to be larger, I can see that. You can see we're creating groups. We can assign users to, and then we're saying that everyone in that, that group has the function clear queue available. I don't know if you noticed before. This is this, this button, it says clear queue in Danish. So we, we, we with a little bit of JavaScript on the front end, we have wired up this function to this button. And the, this function is running on the server. And it cleans out, you know, the database table and the state we have got about who is in line for help. And, and that is really a powerful way to do stuff like that. More or less. Yeah. That is basically the, the gist of it. I've put page A lot of time for questions, I think this is a really interesting subject. And if, if you want, I can dig into more, more examples of, of how to do simple stuff with no, no JS. Anyone? Yes. Yeah, that could be, you know, anything where you're doing, well, I should repeat the question. That's right. Your question was that if you have like a web app where you have like a continually scrolling content, like on Twitter, where you scroll down and more content appears, if Node.js would be a good way to fetch that content. Yes, I think almost any place on your website where you're doing something simple via JavaScript or Ajax to call back, to do something that simply fetches stuff from the database and returns it back as JSON or whatever, is a really good candidate for replacing stuff with Node.js. Because doing so in PHP is really inefficient. Yes, well, it is closer, I'd say. But it depends heavily on your use case, of course. But in the case with our chat system, we really needed to get to do at least four or five queries to determine who is this user, does he has access to this page, what messages are waiting for him, what is his spot in the queue, is he actually banned from the system. And those queries need to happen no matter if you have the Jupyter Bootstrap or not. But you can keep that state around if you have like a user persistent connection like a web socket. You can just attach that info to that so you don't have to do the lookup for every little thing that happens. Yes, that's of course true. Well, your argument is that Node.js is mainly faster because it has to do less work. And that is completely true. But many of the ways Node.js has to do less work is actually not really possible to do if you want to work inside Drupal. And the example I showed from our own web app, we're actually not just, you know, transforming a string. We are actually doing a couple of lookups, several lookups in the database and updating a table and formatting the data that is sent back to the user. But yeah, that's true. JavaScript, the Node.js runtime is a bit faster than PHP's, simply because the Google engineers that are working on V8 has spent so incredibly much time tuning and tweaking and doing all sorts of magic stuff on the runtime. Yes? Yes, the question was, aren't we missing all the hooks? Yes. This is not something you can build a module of. This is, well, you can't build extensible stuff in Node.js, but doing so is very much different than you would do it in Drupal. So you wouldn't use hooks or anything like that. So this is mainly for, you know, the end line scenario. I need to build something, a finished thing. It's hard. There is actually a Node.js module for Drupal. It's not, I didn't write it myself, so I won't say too much about it because whatever I'm saying might easily be wrong. But the basic thing they're doing with that module is that they're providing a way for your PHP code to push notifications to any user who's online on the Drupal site. And for that, they have a separate Node.js application that listens for connections from Drupal and passes those messages down to the clients. Yes? Yeah. Well, the main point is actually what you call stateful interaction. Like you're connected to a chat room. You're talking to Michael. You just need to know what's changed since I was last here. But you need to keep all that state of what's going on at the moment in memory so you don't have to look up into the database. And another thing is actually much of what Drupal does is just acting like a proxy for the database, fetching stuff from the database and just slightly transforming it and sending it back. And that's usually what you're doing if you're building an AJAX-powered interface. Yes? Well, it depends a bit on how comfortable you are with JavaScript in the first place. If you've worked a little bit with JavaScript, you know that everything is a bit different. It's more like function-oriented programming and you have callbacks that get back to you later. It's a bit like when you're calling an AJAX-request in your front-end JavaScript code, you get a function that is called later when the response is ready. And that's how almost everything happens in Node.js. If you call your database, you pass a function along and when the database response is back, that function is called. So Node.js code looks more like this, where we have deeply wrapped stuff. This is actually not a very good example. Like this, you have functions wrapped in functions, wrapped in functions, because they're called at different times throughout the execution. This is actually some testing code we've written for the DNS service. But that's the basic gist of it. On top of that, you have to, you know, setting up Node.js on a web server is really not all that complex. You can Node.js runs as its own process and you can either, you know, use Apache's mod proxy or nginx proxy support to have it on the same IP address as your main website. Or you could use it, you can run it on its own IP address or a different port number. But it runs as a standalone web server and you just have to keep that running. As long as the Drupal application is running. And getting to learn all that, I think, depending on what you need to do, but it's, you know, the hello world of Drupal, Node.js is actually starting a server. Here it is. This is how much code you need to make your own web server, web service with Node.js. So the simple stuff you can learn in a day or two, I would say. Yes, well, to the extent that you're actually accessing Drupal's database from within Node.js, you have to take the same precautions as you do in Drupal. You know, use parameterized queries and, you know, check who the user is before, you know, allowing him to change roles of Drupal users or, you know, but there's, I don't think there's anything surprising security-wise. Yeah, if you want your queries to do any support in any of the stuff that happens in Drupal with hook query also, you would have to do that manually yourself. Yes? Yeah, I think in this instance, we're actually not using Backbone. We are using something, a different framework called mba.js. And the Drupal, for this application, Drupal is simply a shell that we use to, you know, reload a bit of markup and all the magic, all the data pulling is actually happens through the Node instance. So they aren't really two streams here. Drupal is mainly passive. It just helps load this page. Helps authenticate the user. Helps us check access, you know, for who owns the stuff. You know, for a system like this, it's pretty important that the users can change each other's data and can only see the data that they own themselves. So that's why we use Drupal for this down there. It depends a bit on what kind of load balancer you are. Well, the question was persistent connections to Node.js. Is that troublesome with the load balancer? And it depends heavily on if your load balancer actually supports it. We use it with a simple varnish load balancing. And that works great because when varnish detects that it doesn't support whatever magic is going on in the HTTP transaction that is going on, for example, when you do a web circuit upgrade, varnish just say, OK, you guys talk to each other. I'll keep out of this. And it actually works as expected. But if you have some kind of old system or anything like that, well, it depends. But the thing is, when we are using for the chat side, we're actually using something called socket.io, which is the library you can use for Node.js that handles fallbacks for these things. Because not all browsers actually support web sockets yet. And if you're behind a proxy at home or whatever, if you're sitting at your school or anything, you might not be able to get web sockets going at all, actually. So this library actually helps us fall back on different stuff. It can use flash sockets, the flash with all the nasty graphics you see on the website that jumps around. It can actually be used for something useful. And that is for providing fallback support for web sockets because flash in the flash runtime is something similar to web sockets. And if you use a library like socket.io, it helps you fall back on that. And if all else fails, it'll use HX polling. So it'll just pull the server every few seconds. And then we're back to how it used to work with this site. But we are still not back to the awful performance of the old site because Node.js, when you use polling for that, it still has the state and memory when you pull. So it doesn't have to ask the database about everything. It can just look up into an array and say, no, there's nothing new for you. Sorry. Anyone else? You? Well, the Node module for Drupal. Right. Yeah, it's a bit confusing. Well, we've implemented some parts of the Drupal API, mainly to do with the DB, DB query, and user dot, whatever. This is kind of slow. But basically, we provide similar functions to user access in Drupal. So you can call if you have a user object loaded from the Drupal database in Node.js, you can actually call user access on it to find out, does this user have a specific Drupal permission? And similarly, you can call user load to load the user. And stuff like that, basically. If we use a Node library to connect with a Drupal database, yes, depending on the database, we use a Node library called MySQL for connecting to MySQL database, or a Node library called PG for connecting to Postgres SQL databases. It doesn't support all the new magic in Drupal 7 with query building and stuff like that. So it's a very simple curious syntax. Let's me see if I can actually find it here. Modules, Drupal. See, this is some of the code. This is user load. And it simply selects the role from the Drupal database. And adds the roles the specific user has and makes a callback. Yes? What are the differences between Bridge and Dnode? Well, I think the main difference is that they're just competing products. What are the differences between Type 3 and Drupal? They're more or less the same kind of things, but they have different design decisions. Bridge tries to do a bit more, but it's a little harder to understand what is going on, because it's more magic in a way. But you can do more or less the same thing with both. Yeah, the reason we're considering switching away from Bridge on Node.js, as it used to be called, is mainly that it's run by a startup, and there are no other developers on the code. So we are a bit careful about that, because you never know when they might actually go away. Done there? The question was, how do we keep our Node.js servers running, even if there is an error or it crashes or something? It depends a bit on what operating system you're using. But if you're using Ubuntu, you can use something called Obstart, that is a system for keeping track of what services your system is running, and restarting them if they fail. We use something called Supervisor, which is a Python program, which does the same thing. It monitors processes and restarts them if they're crashed. I think there are hundreds of small scripts like that. So you can use whatever you wish, more or less. There's also a Node.js powered one that is called Forever. So if you want to run your Node script with another Node script, you can actually do that. Yes? Well, the question was, is Node.js running multi-threaded, or does it handle a process, does it branch out processes like Apache? And multi-threaded, no. Well, yes, it's a bit complex, actually, because the Node.js program itself contains several threads, one which run JavaScript, and a few others who handle stuff like talking to the network and reading files from disks. So the Node.js program itself is multi-threaded, but you can't, or you really, rather you shouldn't use threads inside your Node.js JavaScript code because JavaScript is a dynamic language, so only one thread can actually run it, run the JavaScript environment at a time because otherwise your variables might change from one line to the next, and that leads to really unpredictable code. So what you do if you want your Node.js to take advantage of all the many CPUs on your servers, you can either spawn four copies of your Node.js program, and then they'll just share the resources available, or if you need shared state between them, you can actually, you can spawn processes in Node.js like you can in Apache, and then you are responsible for communicating between the processes yourself, of course. That's actually one of the main use cases for Dnode. If you have several instances of the same program that's running on the same server, and you need them to talk to each other, you can use Dnode for that. Yes, down there? Well, if I understand your question correctly, if you have like a single resources that is being requested by 10,000 users at one time, how is Node.js going to handle that? And no, it's not going to take the same, well, it has to respond to each of the 10,000 requests in turn, but depending on what code you're actually running to generate that response, it'll do one of several different things. As soon as you do a database call or anything asynchronous in Node.js, it'll use the opportunity while it's waiting for something else to happen. It'll take another incoming request and answer that if it can. So if you have like an example, like the whole hello world, we had, where was it? Like this? Well, this will take a picosecond or something like that for the Node.js server to actually process this part of the code. For this case, most of the time is spent actually passing the HTTP request and putting together the right packages on the network and stuff like that. And that actually handle is run on threads. So it's kind of hard to answer, give a short answer to this, but Node.js will handle a lot of concurring connections and it won't take 43 milliseconds to answer each of them. 43 milliseconds, the most of that time is actually spent on the network going back and forth and going back and forth with the database. So it might take one millisecond per request. So if you have 10,000 requests, it might take 10 seconds to respond to all of them. But it might easily be shorter than that. You'd have to run a benchmark to get a decent answer to that, I think. Anyone else down there? Well, there are a metric ton of Redis clients for Node.js. The Node.js community is really excited about Redis. So use, I don't really have a recommendation of which one is good, but use any of the Redis clients and you just give it the IP address and the number and then it has, in JavaScript, it provides the methods that you can use on your Redis server to run them there simply. They're telling me to shut up. Well, to simply answer how we're using that in our application, we can use it for storing storing a Drupal sessions and stuff like that. Any kind of data you need to keep in sync between multiple servers, Redis can be a really good solution for that. So yeah, aren't we supposed to finish that quarter past? So we have five more minutes, if anyone. We have our own web server. So we run it there. Currently we are renting it from Hetzner, which is actually a German company. But any VPS or almost any kind of server will run Node.js. We actually use NGINX for all our applications, but most of the time we try to either put Node.js on a different port number. So it doesn't have to be proxied via NGINX or run it on a different IP address. That's actually what we're doing with our application here. You can see the requests to Node.js goes to api.afd42.com, which is a different IP address. So in this case, we're not proxying anyone else. Well, thank you for coming. This one, that is from New Relic, actually. Yes, there's actually something pretty cool called Node Inspector that allows you to run the, basically this inspector, the same as runs in the Chrome browser. You can run that on your Node.js program and insert breakpoints and inspect variables and do all the stuff that this tool can do. That's pretty neat, actually. So I think you should probably look into that. It's called Node Inspector and there's pretty good instruction on how to get it working. If you hear from disconnects between server and client and that'd be something with Miscontract NGINX in between or where should I look for? Well, it depends, we've seen some really strange issues like people using mobile phones and switching cell towers and there can be all sorts of weird reasons why you're using disconnects. So it's hard to give a general answer for it, but a Miscontract proxy could do it easily, of course. Node.js or NGINX proxy will not work if you're trying to do stuff with web sockets, for example. It doesn't support that yet. Yeah, that's what we're doing with our app, too. Yeah, I don't think there's actually much to learn there. It's basically changing the URL of your AJAX request to point to the other server and demonstrates, yeah. Yeah, yeah, basically we're doing it in JavaScript. You can see on this, our application here. So kind of having that mix of...