Good morning, everyone. Looks like the mic's working. All right, welcome. My name is Robert. I am a software engineer at the Facebook Boston office, where I work on GraphQL. And before that, I was a software engineer at Microsoft and a software architect for as software group. With the recent trends in microservice architectures, cloud native, and rich web apps, there's a lot more challenges when building APIs. In this talk, we're going to talk about how to overcome these challenges with GraphQL, an open source API query language that we created at Facebook. Let's go over the agenda. First, we're going to try to define GraphQL. What is it? What is it not? How do we use it at Facebook? And how does it compare to other technologies in this space? Next, we'll talk about some of those challenges that we face when building APIs. And we'll look at how GraphQL deals with them. Then we're going to transition from theory into practice. At this point, if you're convinced that GraphQL can help you solve your problems, then we'll talk about how you get started, how you get GraphQL into production, some of the advanced use cases and features you can rely on, and specifically how you can deal with authentication and authorization. And finally, we'll wrap it up by talking about what's in store for the future of GraphQL. What's on our roadmap? How can you contribute and participate? And finally, we'll have a resources slide followed by Q&A. So any hyperlinks you see on here, don't bother taking pictures of it or anything. There's going to be on the resources slide for you at the end. Let's start with a demo here. I have a GraphQL server running on my laptop. And I've just plugged in the URL into my browser. And what we see here is GraphQL. Now, GraphQL is the GraphQL IDE. This is just a tool. This is not GraphQL itself. But this tool lets us author GraphQL queries, send them the server for execution, and display the response. In addition, on the right-hand side, you see there's this documentation explorer pane. And using this, we can explore the GraphQL schema that this endpoint supports. So we know what queries to execute. In this case, I've built a very simple example schema to model an online library system. Let's take a look at what it contains. On the right here, we have this query root. And if I click through, it says it has two fields, authors and books. And for authors, it says it's going to return a collection of authors. So if I click through this author entity, it says, oh, it's got these fields, ID, name, image. And these are all primitive fields of type string. But then it has this edge pointing to books. And it returns a collection of books.  So knowing that, I can come in here and I can just start authoring a GraphQL query. So if I have a query, I can come in here and I remember that these are my fields that I can use to start accessing my graph of data. So I could say books, and I could see something like ID. So these are the IDs of all the books in my system. But IDs aren't that useful. They're great for programs, but they're not great for human beings. What are the titles of these books? So it looks like we have some Harry Potter books, the Lord of the Rings trilogy. Now, what if I wanted to fetch the author for each of these books? I've got this author ID, and if I execute this, that seems to be pretty consistent, but it's not giving me the data that I actually want. What if I wanted the author's name? Well, I could do something like this, and now I have the author's name populating my query. What if I wanted to get, for a given book, I wanted to get all the other books written by that author? Well, I can come in here and just say books. And now you can see we started with this Hobbit, it was written by Tolkien, and then here are all the other books in the system that Tolkien wrote. But also, I want to show that if I come in here and I type foo, it's telling me, what are you trying to do? Food doesn't appear to be a valid field.  You have, you know, we've declared the opening in the curly brace for the selection, but we've got this extra string outside of it. What does that mean? So let me switch back to slides. What did we just see? Well, we saw a GraphQL document on the left, and we packaged this up into a request, we sent it to the GraphQL server, and we got back JSON as a response. But we also saw that we can't just send arbitrary text. It has to follow some rules. And these rules come from two sources, the GraphQL language specification and the schema. Now, the GraphQL language specification describes the syntax. So it says, opening curly braces must match, or you must have an operation type before the first selection. The second thing, when we typed foo into the selection, and it says, hey, what are you trying to ask for? I don't understand the field foo. Well, that information comes from what we call the schema, and the schema is domain-specific, and it describes the types and fields on those types associated with a particular domain. In our example, this schema that we were looking at was describing an online library system. And you also saw a server that can take one of these requests, execute it, and return the response as JSON. So there's an implementation of the GraphQL specification running that helps you construct the schema, parse incoming requests, and fetch values for the requested fields. In the demo we just saw, we were using the reference implementation that was written in Node.js. It's also useful to describe what GraphQL is not. And anytime anybody sees QL, they probably think database, right? But GraphQL is not a database query language. Although the asterisk here is because there's this interesting new database called DGraph, which happens to use GraphQL as its query language. So I just wanted to point out that it's not the original design of GraphQL. And it's also not a client-side state management solution. So we might be tempted to think, oh, okay, cool, I've got this JSON graph of objects. I can just do it with client-side state management, right? Not quite. You still need some client-side state management for dealing with things like caching, cross-view consistency, and optimistic updates. And it's also not a good solution for binary streams. For example, file transfers, images, streaming video, where you're really streaming chunks of binary encoded data. That's not what GraphQL was built for. And it's also not to be confused with GraphAPI.  GraphQL is something different altogether, and it's currently only used for Facebook's first-party applications. It's not a limitation on the databases that you choose. It's actually just a very thin layer, as we'll see in the stack diagram later. And you can use GraphQL with all sorts of persistence backends, ranging from SQL to NoSQL to caches like Redis to flat files. And that's because the GraphQL fields that we saw in the schema are backed by arbitrary functions that you provide when you define the schema. Now, although the reference implementation is written in JavaScript on Node, that doesn't mean that GraphQL is a JavaScript-only thing either. There are implementations of GraphQL in just about every popular language. For example, Java, Python, Ruby, C sharp, Rust, Go, you name it. And these servers are used in production at a large number of companies. And you may have also heard of GraphQL through other successful open source projects, such as React and Relay. And while React and Relay are really good choices for building frontends that talk to GraphQL, there by no means exclusive. The declarative approach that GraphQL provides is equally useful for jQuery, Angular, View, as well as native UI technologies, such as Objective-C and Java. Lastly, it's not limited to HTTP. We happen to see GraphQL going over HTTP in our demo, but it's not limited to HTTP. It happens to use HTTP very frequently because of HTTP's ubiquity. GraphQL has three operation types. We saw the query where we were essentially performing a read against the system. But there are two other operation types. We have the mutation operation type, which supports writes. And then we have the subscription operation type, which allows the client to specify its interest in observing an event, a domain-specific event. Both queries and mutations take a request and then return a single response in the future. The subscription, by contrast, takes a subscription request and then returns zero or more future responses. And as a result, you can probably see that queries and mutations are stateless and they can operate over any transport that supports the request-response model. However, subscriptions are stateful and that means you need to be careful when trying to maintain durability, availability, and throughput at scale. Another thing is queries and mutations are only semantically representative of reads and writes, just like HTTP verbs. In other words, if you're implementing a GraphQL server or a schema, nothing stops you from having a query perform a server-side state mutation. And nothing stops you from creating mutation that has no side effect. These are just tools to make the operations and intent more clear. So if you had an HTTP get operation, that somehow deleted a record in a row in a database, nothing stops you from doing that. It's just not very communicative and intuitive for the user. And a GraphQL server doesn't even have to support all these operations. For example, if we don't want to find subscriptions, then we just simply leave them out of the schema. Let's talk about the origins of GraphQL and how it's used at Facebook today. The first version of GraphQL was built back in 2012 by three Facebook engineers, Lee Byron, Nick Schrock, and Dan Schaffer. And it was designed to support the growing needs of our mobile applications where the rest architectural style just wasn't cutting it. And in 2015, after years of building, extending, and operating GraphQL, the team decided to open source it. But this wasn't just a port of what we had built internally. This was an opportunity to examine the initial work, to take a look at what worked well and what didn't and make a bunch of tweaks. And as a result, GraphQL was open sourced in two parts, the specification and the reference implementation. Today, GraphQL powers many things, most notably all the Facebook web and mobile apps. Across these, we have over 1.3 billion daily active users. And these users send us over half a trillion GraphQL queries per day. GraphQL is also seeing rapid adoption on other companies. For example, GitHub, Pinterest, Intuit, Coursera, Yelp. And there are a lot of other companies using them for internal use cases that haven't gone public with their announcements. Now there are a lot of architectures, frameworks, and libraries, and patterns that facilitate client server communication. GraphQL is not the only one. But we could be here all day trying to compare GraphQL to everything else. So in the interest of time, I'm gonna focus on comparing it to REST because REST is the architectural style of the web. And hopefully by comparing it to REST, you'll transitively understand how GraphQL compares to any other API technology in this space. If not, come and talk to me afterward. Before we dive into the comparison, I wanna preface this by saying you'll find a lot of literature, a lot of articles online about how GraphQL is here to replace REST or how awful REST is. And I think that kind of narrative might be overreaching. So I wanna frame this comparison in terms of trade-offs. Try to avoid thinking about each row here as a checkbox where the column with the most checkboxes wins. But actually by show of hands, how many people here think they know what a REST API is? Okay, that's quite a few. Keep them up, keep them up, please, please, keep them up.  Where do they go? So that's great for the first point of comparison. It's likely that if you put 10 people into a room and ask them what is REST, you're gonna get 20 different answers. And I'm here to offer a 21st. So by REST, I mean representational state transfer as defined in Dr. Roy Fielding's dissertation in 2000. That is, a REST API is something that meets all six of the REST architectural constraints. Specifically, there's one that stands out. It's called the Uniform Interface Constraint. And the Uniform Interface Constraint is what contains the hypermedia constraint which states that hypermedia acts as this engine that transfers state between the client and the server. Now, the degree to which these architectural constraints are observed and enforced is highly variable. So that's why all of your hands went down. Because we have this landscape of HTTP JSON APIs that call themselves RESTful or REST-ish. And if we take two Paragon REST APIs, unless they were built with the same framework, it's extremely unlikely that they share critical features like linked resource annotations. So I think it's safe to say that REST has no shared definition, at least not in an concrete sense. GraphQL's not like that. GraphQL is not up for debate. Given a specification and a schema, you know exactly what is and is not a valid query. And you know the shape of the response that you're gonna get. And sometimes this specificity is good. Other times, the flexibility of REST is also good. Next, let's talk about the central organizing model behind REST and GraphQL. In REST, the central concept is the resource. And you can think of resources as virtual files living on a remote server somewhere. They all share common operations against them. In GraphQL, the central concept is a graph. That is nodes with fields and relationships to other nodes. And this has a profound impact on how you add features to each API. In REST, we're gonna end up adding more URIs for more resource types. Whereas in GraphQL, we stick with a single endpoint and we expand the possible variations of the queries against that endpoint. And REST's resource model is also a huge advantage when it comes to federation. By federation, I mean we can link resources between domains. I can make a Facebook post where I share a Wikipedia link. And then in that Wikipedia link, there's a citation of a New York Times article. In GraphQL, linking data across two different schemas is difficult and there's currently no good solution. REST has another constraint called manipulation through resource representation. And that means that a given resource includes hypermedia links that describe how to manipulate it. For example, how you modify, delete, or replace it. In GraphQL, when you're at a node in the graph, there's no standard or built-in way to access all the mutations that could affect that particular type or that particular instance. However, you might argue that GraphQL has something more general, introspection. Introspection is like reflection for your API. And it's the core feature that enables us to build tools like we just saw with GraphQL. It also allows us to generate type-safe client code and some other integrations that we'll see later. By contrast, it's difficult to imagine to introspect REST APIs in a standard way. Maybe something that resembles a sitemap. I don't see a lot of those around anymore. In any case, it's not mentioned in the REST constraints, so any implementations would immediately lack standardization. And as a result of introspection, GraphQL features strongly typed inputs and outputs. REST has a hard time pulling this off, partly again because of the decentralized approach to federation. And modern APIs commonly have to deal with clients that observe changing data. REST's stateless protocol constraint makes this difficult. It makes it difficult specifically to build efficient, push-based APIs that know the state of the history of what was already pushed to that particular client. GraphQL doesn't have this restriction. And via subscriptions, it actually makes real-time data a first-class use case. The trade-off here is that subscriptions are stateful and therefore it adds a great deal of complexity to the underlying infrastructure. That said, subscription support is optional. Building modern APIs is tough. There are a lot of challenges. So we're gonna dive into a few of them in more detail and see how GraphQL deals with them or doesn't deal with them. The first is efficiency. Within a single network request response between a client and server, two common problems occur. The first is over-fetching. And that's when the client made a request for some data, but the response contained additional data that the client didn't ask for. And the second is under-fetching. And that's when the client makes a request, but the response didn't contain enough data. And that forces the client to issue another network request. And under-fetching is especially common with the REST architectural style because the better you get at implementing the hypermedia constraint, the more common under-fetching becomes.  I mean seriously, here's some common latency numbers. So if we try to read one mag of sequential data from a modern SSD, it's gonna take about one millisecond. While if we send a packet from the US to Europe, the round-trip time takes about 150 milliseconds. So the network is exponentially slower than just about everything else that happens in a typical application stack. And that's assuming that we're on a really good network. With mobile devices, the networks are even more unreliable, subject to interference from solar flares or other devices or buildings, vehicles, terrain. In many parts of the world, wireless network quality caps out at sub-2G. And data usage is heavily metered. And to get a better sense of this problem, I have a demo that we can do together. So if anybody has their laptop here, wants to follow along, feel free to open these two URLs in your browser in two different tabs. I'll give you a moment if you wanna follow along. Just raise your hand if you're gonna try this. If nobody's interested, I'll just do the... Okay, cool. Yeah, take a second. Okay, we're all set. That first URL, Swapy.co, takes us to the Star Wars API. It says, all the Star Wars data you ever wanted, planets, spaceships, vehicles, people. And this is great. This is, I'm a huge Star Wars fan, by the way. But this is great. You can see, you know, you've got this URL and it seems like people slash one is the resource representing Luke Skywalker.  So I guess this means the films he appeared in, the species, the vehicles. Now, let me point out a couple of things. This films, this films one, this URL here. What is the shape of the data that this thing's supposed to return? It's probably JSON, right? But is it gonna contain something called title? Is that an immediate field in the root of the object or is it nested in there somewhere? What about the director? Does it have that information? I just don't know, just from looking at this, I kind of have to go through this hyperlink to follow through and take a look, right? So let's do that. Let's check out what films slash one is. Oh, so I guess, right. So I mean, there is something, there is a title field, it's called A New Hope. This is episode ID four. It's got opening crawl.  So imagine that we had a requirement that was for the film New Hope, display the names of all the characters that appear in A New Hope, right? I mean, just as humans, we can kind of do this. We can kind of take the role of the machine. What are we gonna have to do? We're gonna have to click every single one of these links and say, oh, okay, I guess people one is Luke and this one's C3PO and this one is R2D2. But every time we click one of these links, this is another network request. If we're in the US and this server's in Europe, well, that's like 150 milliseconds for each request and we're sending these off in parallel. They're gonna have to come back. Some of them are gonna fail. I'm gonna have to retry some of them and then I'm gonna have to join this logic back on the client. So I think that's kind of illustrating. Yeah, and also, look at this, this opening crawl thing. In our requirement, that wasn't even part of it, but this is a huge chunk of text and this isn't even the only piece of superfluous information. So in this Star Wars REST API, given that requirement, we've seen a real-world example of both over-fetching and under-fetching. It both gave us too little and too much data, which is not good if we're trying to build really efficient mobile apps that can operate over flaky networks. Luckily, that second link is that same API, that same data, but rebuilt with GraphQL. And just like the library demo we saw earlier, we have this root query and we can come in here and we can see immediately what is the shape of all the different nodes that we have in this Star Wars schema. So let's try to fulfill that requirement earlier, right? We wanted to get all of the character's names from Unyoo Hope. Well, I can come in here and I'm gonna use store hand notation. If you don't specify the query type and this is the only query in the document, then it automatically infers that it's a query type and you don't need to give it a name. So I can say all films and within all films, it says it's a typed film connection, so let's just get the films out of it. And let's try to guess, yeah, so it has something called ID. Great. So it looks like this is the one that we want. And there are actually a couple ways to slice at this where I only want Unyoo Hope. Probably the easiest one is I can just say first one. Right? Everyone with me? Next, in the film, hopefully there's something called characters, right? There's a character connection. And you know, we can just start typing and we get type hints from GraphQL because of the introspection query. Right? But just as easily we can come in here into this thing and search characters. What has characters? And you get a lot of this documentation for free. So the character connection, I can say, well, for each character, I could get their IDs. This looks pretty promising. And there you go. I have all of the character's names from the film, the first Star Wars film, Unyoo Hope, in a single network request response round trip with zero overfetch and zero underfetch. This is the exact data I asked for and nothing more, nothing less. Now I want to stop here because, you know, it seems like there's a lot of experience in the room dealing with REST APIs. And some of you are probably thinking, well, we can do this with REST APIs. Absolutely can. There are lots of ways to do this, right? We can create a custom endpoint. We can create an endpoint that's like starwars.co slash all character first names from movie with ID and then pass an ID as a query string. How many people have done something like that? Yeah, so you know what I'm talking about. We can do it another way. We could, in order to get this nesting field structure, we could pass it in with query and we can say fields equals whatever as a query parameter. But let's say our requirement changed ever so slightly. Let's say our requirement was that we want the character and we want the home world or something and we want the orbital period for whatever reason. I don't know. I'm a huge Star Wars fan. If I did this, what am I gonna do? Am I gonna go and create another swappy.co slash characters and their home world's orbital periods with ID? This is not a solution. It takes you a little ways forward but you can imagine for certain apps at certain scales this is not a tenable solution for very long. So that's a good opportunity to kind of mention that and a lot of people think about GraphQL as this client-oriented query language and it is but it also makes the server engineer's life a lot easier. You can think of it almost as this engine that can create on-demand rest endpoints where you don't need to go and have a new endpoint and that new endpoint has new authentication and authorization requirements and now you gotta monitor it and you gotta deploy it and you gotta version it. This is the headache, whereas expanding the query in GraphQL adding new capabilities to a GraphQL schema is simple. Okay, so hopefully you guys trying to follow along with the, on your laptops and you can keep exploring these two APIs and let me know if you have any questions afterward. So we saw how GraphQL can help us avoid under-fetching and over-fetching. It lets the client declaratively specify all the data that it needs in a single network round-trip and it reduces the need for complex client-side logic to deal with error handling and retries client-side joins. We also got type safety out of it. Through the schema, GraphQL provides type safety for these requests and that improves predictability because a client never has to send a request to an endpoint and then guess at what it's gonna get back. It has a high level of confidence about the shape of the response and this is really useful for native clients that are strongly typed or gradually typed because it enables compile and build time type checking to help detect mismatches early on in the development feedback loop. And at Facebook this allows us to generate type safe client models that correspond to the GraphQL queries in iOS and Android and that take advantage of full advantage of the type safe languages of Objective-C and Java. GraphQL also enables another very interesting non-technical capability for your APIs and that's fluency for modeling the business domain. How many people here are familiar with domain-driven design? Okay, a few of you. Domain-driven design is a book by Eric Evans in 2004 and it has this really neat set of ideas. The central idea is that people across the business, both technical and non-technical can build this shared vocabulary called the ubiquitous language. And the ubiquitous language is just natural language that describes the business domain in terms of entities, processes, and relationships. And this kind of natural language lends itself to being modeled as a graph. This means you don't have to talk about the business in terms of tables and rows and joins and stored procedures or you don't have to talk about them in terms of resources and URIs and HTTP operations. The entities and operations on those entities can just be spoken and reasoned about in natural language. And I think this is an incredibly subtle but incredibly powerful feature that GraphQL brings. Versioning, the web has spoiled us. If your app only has a web client, then you get to dictate the version that the client is running because the user is essentially redownloading that app every time they hit that URL. However, it's not the case with native apps as I'm sure many of you are very well aware. And if you use Facebook on iOS or Android, you'll probably notice frequent updates. But you have a choice to update that app or not. So you can imagine that we have a large number of different versions running at any given time. How does GraphQL handle this? Well, how would REST handle this? Would we version the API route? We have thousands of those. Would we pass in the version as a query parameter? Would pass it in the header and the MIME type or something? Or the content type? Would we bake it into the access token? None of these are scalable solutions. We've tried. So GraphQL deals with versioning by simply not doing it. And that means GraphQL servers must rely on backward compatibility and forward-only versioning strategies. And to do that, we can use the schema and deprecate certain fields. We can mark certain fields as saying, we wanna remove this as soon as possible. Please stop using it. And then one of the following scenarios occurs. In the ideal case, clients respect this message and they migrate away from using it. And we can detect when that field stops being requested and then we can remove it. If the clients don't migrate, then we have two choices. Well, we can either, if we value backward compatibility and that older version of the client to continue to work, then we can keep the field around and maintain it forever. Or we can just say, that version is too old. It's more than five years old. We're gonna stop supporting it. And we will just break that version. And that's in the, you know, but that's a business decision. We've already seen GraphQL in action and we've seen some pretty cool features like inline documentation, type hints, syntax highlighting, execution. But it's important to understand that all of these features are powered by GraphQL introspection. And introspection opens up this world of possibilities for tooling and integration. For example, my teammate, Hio, has been working on something called GraphQL language service. And this is a package that'll allow you to add some of GraphQL's capabilities to your favorite IDE. Check out this demo of it working inside VS Code. So we can write a query inside VS Code. We get type hints. We get inline documentation. We get type checking on input parameters. And we get click go to navigation, go to definition on fragments and related types. And of course we also get that same validation, the same validation capabilities we saw in GraphQL. It'll tell us when we've declared an invalid field. It'll tell us when we've violated the GraphQL language syntax itself. Authentication and authorization. I think this is such a common problem for APIs that it requires it's a dedicated, we should talk about it in more detail. These two concepts are often confused with one another, so let's quickly refresh. Authentication refers to identifying who the caller or user is. And this can be done, for example, by including an access token in the request header. And the first thing the server will do is check the signature and the validity window of this access token. And then the authentication requirements are usually domain agnostic. They don't vary with domain. And they'll go something like this. If the user can prove who they say they are, let them make the request. Otherwise, don't even bother cracking the request open or executing any more of it. Authorization, on the other hand, refers to whether the authenticated caller has permission to perform a given operation. For example, if we're building a blog, we might have an authorization rule that says only authors and admins can see posts in the draft state. Authorization rules are usually domain-specific, and therefore they belong in the business logic layer. I think a diagram will make it all a lot more clear. So you can see up at the very top, we have our transports, and imagine that the client is floating somewhere above this slide and sending requests to our server. And these requests come over some sort of transport, perhaps HTTP, perhaps some custom protocol. And at some point, the server providing those network transports has to authenticate the incoming request. And that's also a good place to reject in unauthenticated requests if authentication is required for that endpoint, for that API. And you can see that GraphQL, REST, RPC, these kinds of techniques kind of sit in the middle. They sit in the middle of the transport and in front of the business logic. And notice that I put authorization into the business logic layer. This is a little tricky. Why should authorization live in the business logic layer? A lot of newcomers, when they start with GraphQL, they get really excited because they see how easy it is to build the schema out and they start adding business logic into the field resolvers. And they'll add authorization logic there consequently. But if you do that, this is what it looks like, right? What's wrong with this? Well, there's no single source of truth across the different ways we can invoke the business logic anymore. We would need to duplicate the authorization logic across REST and RPC. Probably not a good idea. We might get inconsistent behavior depending on whether the user calls into us through REST or GraphQL. Another way to think about this is how we would test our business logic. If we had a requirement from earlier, like only admins and authors can view draft posts, how would we test that? Ideally, we should be able to write a unit test that isolates the business logic layer. But if we structured it this way, then at best, we have to write an integration test that involves GraphQL as a superfluous dependency just to exercise the authorization logic. Probably a sign that we made a misstep somewhere. So I think this is the diagram that we think makes the most sense for GraphQL and how to think about how GraphQL fits into the stack. Now that we understand some of the problems that GraphQL was designed to solve, but I wanna emphasize that GraphQL is a tool. It's not a silver bullet. It has certain problems that it's good at solving and other problems that it's not so good at solving. And part of our job as engineers is to understand the shape of the problem and finding a good problem solution fit. For example, I wouldn't want people to use GraphQL just because they think it's cool or because it's new. But aside from the specific problems that GraphQL helps you address, there's another dimension to consider, which is when. So you think you have a problem like this, but when should you deploy GraphQL? And this comes up frequently enough that I think it's worth addressing in a fairly general way. For example, if you're building something like a Hello World app on a white background and a web browser, it would be silly to reach for some heavyweight UI framework like React or Angular. And the same is true for APIs. There's no real payoff for trying to future proof everything. But then just how do we think about it? Here we can turn into something called the design stamina hypothesis. This is an idea proposed by Martin Fowler and he asks, what's the point of good design? Because if you start off with no design, nothing gets in the way, that you don't think about how to do some specific thing in some specific way. So you have this very fast initial velocity where you can get a lot of cumulative functionality in a short amount of time. But as you continue with no design, that curve tapers off and it becomes increasingly more and more difficult or takes longer and longer to add the same amount of cumulative functionality. Consequently, if you had started with good design, you are, there's an opportunity cost. Anytime you spend in getting better infrastructure, better documentation, training, whatever, that's time spent not coding or testing or understanding the customer. And if that happens, then initially, at least for a period of time, it will deliver less cumulative functionality in a given span of time compared to no design. Now notice that these two lines cross over and this is called the design payoff line. And what the design payoff line is saying that is that at a certain level of cumulative functionality or past a certain amount of time, good design wins. And this is, I found this to be a very generally useful way to think about when to do X. So GraphQL is no different. Try to think about GraphQL in this kind of framing. Great. So hopefully we have a fairly decent understanding of GraphQL now. We have a decent understanding of the problems and what GraphQL's good at solving, what it doesn't actually try to solve at all. Now some of you might be wondering how do we get it into production? You like these ideas, you wanna try it out. Well, every organization is different and your mileage may vary, but here are some general dos and don'ts when trying to get GraphQL added to your set of tools. In general, try to prefer small incremental changes over large overhauls. Deploy in a forward only way and leave V1 and V2 side by side for a while until all clients have had a chance to migrate. Specifically, don't try to build the entire schema. If your business is in building blog posts, for example, model only a small portion of the schema, it's okay. Model the minimum useful subset of it. Don't try to replace rest in one push or perhaps don't even try to replace rest at all. Don't place business logic in the GraphQL layer. You'll probably pay for it later. Do work with your team. People get really excited about GraphQL after they get it and they're like, oh yeah, this needs to go into production. Going rogue on this is not the best way, most of the stress strategy. Talk to the team, try to help everybody and understand where the wins are, why this is a good solution for the problems you're looking at. And then choose a solution that fits with your stack. So I mentioned that GraphQL servers are available in all sorts of different programming languages. There's no reason why anybody has to use the reference implementation that we've written in JavaScript in Node. Build a simple query first. Perhaps even something that requires no authentication, something like a message of the day that you can show to anybody. Build that first along with a minimum useful subset of the schema and then you can start figuring out how GraphQL queries work from the client, how they work on the server. And that means you can gradually expand out and add features like auth and mutations. And then I mentioned this before but it's worth repeating, but gradually expand the schema. So here's some advanced use cases. I think we're going over time a little bit so I'm gonna hurry this up. But GraphQL is clearly an edge API technology. That means people use it as an API gateway a lot. So if you have microservices, rather than having the client know about the URL of all those different microservices, you use GraphQL in front of those microservices to create a consistent and cohesive API endpoint for the client to interact with. GraphQL supports both third party and third party use cases. Facebook uses as a first party API solution, GitHub uses as a third party API solution. And we've also seen it used for service to service communication. It's really interesting that people are using it for that, but if it works, great. Skip over that. You might wonder, okay, well what prevents clients from sending malformed queries or queries not necessarily malformed, legal but are extremely inefficient or are infinitely nested. There's a technique we use at Facebook called the persisted query. And the persisted query basically hashes all queries ahead of time. And it rejects any queries that are not hashed. And that way we can control the maximum complexity of any given query. What's next? In about two weeks, there's an event called GraphQL Europe where we're gonna be making some important announcements about the progress we've made on subscriptions. Subscriptions is in an RFC state right now, but it's currently being reviewed to go into the reference implementation and the specification. We're also gonna see a rise in support for persisted queries from our partners. And we're also gonna see some really cool experiments like batch, defer, and live queries. So live queries are particularly interesting. Instead of using subscriptions to observe data, we can execute a standard query operation, but we can decorate it with a special directive called live. And that tells us that that query should be a living query. I don't want just one response. I want a new response, container to delta at any time that query would change. And of course we'd love if you were able to contribute back to GraphQL. There are many ways you can, of course, participate in the design discussion of the spec. You can PR features to existing GraphQL servers. You can build a new GraphQL server in your favorite language if one doesn't exist. And you can start working on tooling integrations. Join a local meetup and talk about GraphQL, talk about your journey, or just hang out in our Slack channel and be helpful. So that's it. Here's some resources as I promised. I hope I've equipped everybody here with a clear understanding of what GraphQL is, the problems it was designed to solve, and the associated trade-offs. So if it sounds useful to you and you have some ideas, if it sounds useful to you, hopefully you also have some ideas of how to get it into production. That's it. I'll leave this slide up and we'll do some Q and A. But thank you very much for your time. And I really appreciate you. It's a pleasure, I think.


Okay, everybody. Now I want you all to face the house. I've seen it before. So grab your photos.  I think you could probably show a picture of this to someone in any country and they could recognize it as George Washington's home. But actually, there's another story to be told here. The very first mention of slavery in Virginia is a letter written by John Wolf to the Virginia company in London. This is in the early 1600s. Now I asked the student once, what does that tell us? And they said, George Washington didn't invent slavery. Well, it wasn't exactly what I was going for, but I thought fabulous answer. He didn't invent slavery. In fact, Washington becomes a slave owner at the age of 11. His father dies. And part of his inheritance are ten slaves. He owns them. Just like you own your pair of shoes. You can do with them what you want. You can sell them. Give them away, gamble them away or rent them. Now it's interesting because of course people say one of the big questions here is, was Washington a good slave owner? Washington is actually a pretty typical Chesapeake slave owner. I can tell you how he differed. Washington recognized marriages. Don't forget chattel property, like your shoes, don't have rights. And of course one of those rights are marriage. It's a right. Washington recognized families and marriages. And very early on Washington decided not to separate families and to honor those marriages. That is a significant way in which he differed from other Chesapeake slave owners. Now we're going to head over and we're going to talk about daily lives of slaves here at Mount Vernon.


Hi everyone, I'm Kel Santiago Pilarski. Nearly a decade ago, I bought a one-way ticket to a country I'd never been to, and it changed my life. I used to be a nurse with specialization in urology and gynecology. I helped deliver babies, assisted in surgeries, and ran diagnostic tests. I'm currently a happiness engineer at wordpress.com automatic, and it has zero connection with my previous medical career. So, how did I get here? Normally, when someone's a graduate of nursing, they'll be a nurse. But I wanted to see how far I can go and which fields I can take on without relying on my medical degree. I don't want my life to be a one-career story, and I also wanted to get away from the medical scene. So if you watch medical series, you know what it's like. There's a lot of action, and when I was working in the hospital, everything was fast-paced. I felt like I was always on the go, and it's difficult to grow professionally when you're tired physically and emotionally. I also wanted to get away from the routine and repetitive tasks and want to add some variety in my day-to-day life and experience something new. I'd like to develop other skills and do something dynamic, be able to work anytime and anywhere, and wordpress gave me those possibilities. When I was working in the hospital, I was looking for other things I could do to switch into another field. Eventually, I got a side job that allowed me to work remotely by writing medical articles for an online magazine using wordpress, and that's when I first got to know it. For a couple of years that I was doing that, I was able to explore the flat platform, and I easily got other side jobs related to that, like working for an online store also using wordpress. Fast forward to 2014, I was recruited by a wordpress startup, and it allowed me to work abroad and finally got an opportunity to work abroad, which is exciting as it's totally new to me. I just needed it at that time. I remember when I was at the airport getting ready to board a plane, I had in my hand a one-way ticket and remaining savings in my pocket, and in my mind, I had a hundred questions and a thousand doubts. Not only that I was broke, but that job ticks all the boxes. Live in a new country, work in a new field, and get the chance to test my abilities, and guess what? I got to do it all in Japan, and I thought, this is it. I'll give it a shot. In my new wordpress role at first, I was resistant to change. Suddenly, everything was new, and I was, as I was going through this transition, I was questioning my decisions. I felt mainly intimidated and overwhelmed by the new environment. I am from a family of artists. My father is a comic illustrator and writer, and my mom and siblings are painters, chocolate sculptors. I was a tattoo artist. So how am I going to do this job? I didn't grow up with a computer. I realized that Wordpress wasn't as terrifying as I thought it would be, as it has a lot of well-documented open resources available to me and accessible to anyone from different tech and cultural backgrounds. And that helped me have a quick role transformation in Wordpress. As I get more involved in Wordpress, the farther I get from nursing, and that just gave me a clear picture of what I really want. It's not only because I'm one of the millions of nurses, but in Wordpress, I can stand out and create my own path here. But mainly, it's also because I'm from the Philippines, and there are not a lot of women in tech. By doing a career detour and switching it to a new field and ultimately ending up as happiness engineer, I could be a role model for other people who would like to have a new career path and especially be a role model for other girls. Adapting to this redirected career sounds scary at first, but it wasn't really, especially when I found my people and my place. I started contributing to Wordpress in 2014. I attended meetups, word camps, and that's when I first got to know the Wordpress community. It's very welcoming and that helped me adapt in my new role. I also got to meet folks from around the world who started out from different fields and are now into Wordpress. By going to events, meetups, connecting with others, I learned lots of new things and it even opened new opportunities for me. When I was in WordCampus Nashville, I met this lovely person, Naisha, who encouraged me to join automatic, and that was over five years ago. At automatic, the first line of our creed goes, I will never stop learning. It also means I will never stop teaching. As a happiness engineer, I always learn something new from my colleagues and continue to teach and help our customers. I found that it's important to continue learning, to not be stagnant and be left behind by the speed of development and product growth. Remember that you don't need to get the right career the first time. Seek opportunities and try things until you find your purpose. Embrace the journey, even if it's not a straight path. And when there's a roadblock preventing you from moving forward and upward, create a brand new course. Attend meetups, networking events, connect with others. Have a chat with someone whose work intrigues you. WordCampus is a great place for that. The person sitting next to you could be your new connection that can help you in your career change and never stop learning. Several years ago, when I decided to take a career detour and book a one-way ticket to start a new life in a new country, I didn't think of having a great career. I simply thought of wanting change and the thought of the impact of that change that can have towards myself and others. I didn't know that that small desire to want change can turn into something beautiful and something great. So tell me, if you had the opportunity to change your job for the better and be the person that you want to be, would you do it? Thank you very much.


Hello, my name is Darcy Devney, Chair, Arlington Commission on Disability, C-O-D. That's the first of many acronyms you'll be hearing tonight. Let's discuss Warrant Article 48, Zoning Bylaw Amendment, Americans with Disability Act, ADA, and Massachusetts Architectural Access Board, MAAB, Standards in Administration and Enforcement. First, please note that this bylaw change will not affect your ability to build or renovate your home because accessibility regulations do not apply to private homes. When a developer applies for a special permit, the Arlington Redevelopment Board, ARB, is responsible for the Environmental Design Review, EDR. There are many, many meetings lasting many hours for each project. During the EDR period, the Planning Department and the ARB use their collective experiences and knowledge to analyze the plans with the architects and developers and negotiate design changes. There are 12 separate standards of review used during the EDR. Did you notice what is conspicuously missing? Accessibility. Let me give you an example of why this is troubling. Last fall, we were concerned about serious access issues with a project in Arlington Heights. C-O-D volunteers listed pages of specific accessibility violations and made many detailed diagrams of the entire entrance, where you can see that the passenger drop-off zone was truly a drop-off. Yet, the architect and developer were not concerned. The developer's lawyer wrote, though my client will meet with the commission as a courtesy, he will do so after the architectural plans are more complete and the building inspector, who makes the ultimate determination as to whether the plans comply with the building code and AAB has completed his review. Oh yes, the building inspector is licensed to do exactly that, a thorough review of the applicable federal and state accessibility regulations. That entire process is after the EDR negotiations and changes, after the ARB or ZBA special permit has been issued. But of course, it's easier and less expensive to make changes on paper than in stone. We certainly don't expect the ARB to take responsibility for all compliance with MAAB and ADA regulations. During the ARB negotiation process is obviously a good time for accessibility issues to be highlighted and fixed. While we're not ADA professionals, we can help by sharing our lived experiences. Otherwise, it's not important enough to the developer until the building inspector's review finds and flags an issue. At that point, the developer can apply for a variance from the MAAB. Then and only then the COD must be notified, but we have only 14 days to look at the plans, research the applicable laws and advise the MAAB. Also, the MAAB is not required to agree with the commission's decision. It's easier to ask forgiveness instead of permission. Once that special permit has been granted, the commission asking for changes, even if required by ADA or MAAB, is an uphill battle. In these cases, there is a regrettable tendency for people to scapegoat people with disabilities as the frivolous reason for delay in permitting or occupancy and increased cost for changes and change order fees. Developers can ask for and be granted a variance or waiver on the basis of economic burden. Sadly, the ADA is mainly enforced by litigation after the building has somehow denied access to someone with disabilities. That is not particularly useful or timely. But aren't developers already legally required to follow the ADA laws? Sure, but as you can see from our example, that that could be problematic. One of the advantages of passing this bylaw is that it reminds developers right upfront that complying with accessibility regulations is part and parcel of the permit conditions. In conclusion, the commission on disabilities proposed this common sense, warrant article 48, because we want to be proactive during the development process. We hope to collaborate with the ARB and architects to ensure that projects achieve accessibility.


So this morning is probably the scariest morning of our trip so far. We don't have a lot of option B for this part, you know? What can we do, you know? How do anything? If we can't get the bike into the US, then I don't know. The trip just stops there. So this morning is probably the scariest morning of our trip so far because we just try to organize and see where we want to cross into the USA. So we actually looked up Itchy Boots channel where she crossed into the USA from Mexico and we were watching it and we were like, oh that looks easy. And then in the last second she was like, ah, I needed to apply four weeks in advance for my temporary import permit.  What was this info about now? And now we are resh-searching and apparently we have to apply in advance for our temporary import permit. Oh my god. And apparently it's like four weeks in advance and we are like a few days, maybe one week away from crossing the border. Yeah, I don't know what to do. We are both still sick, Olli is sick. Just sitting on the computer now, trying to figure out the way how we can accelerate this process or if we can even do it because apparently you have to send off a letter and you have to receive something and you have to involve like a lot of things in it. But Olli is trying to figure it out at the moment. One hour later. Goodbye, beautiful place. Good morning world, welcome back to the channel. Stay number 381 on our circumnavigation around the globe by motorcycle. We're here in the beach side area of San Miguel in Mexico and I feel terrible today for two reasons. Number one, I'm really sick, Lavi was sick over the last couple of days and now I'm sick and I feel just generally pretty terrible and had a pretty bad sleep last night. And the second reason is that some new information has emerged that we may or may not be able to actually get bumblebee across the border from Mexico to the USA. So I was trying to do some research today and it's really unclear as to what we need to do. So it's either that we just need to give some sort of declaration, some forms when we get to the border to declare that our vehicle complies with emission standards for the USA or, and this is the thing that we don't want, is that we need to get a pre-approval from the Environmental Protection Agency an exemption to say that, yes, we're all good to go in. I sent off an email to try and get this exemption but the turnaround time is apparently three to six weeks. We're supposed to go to the US next week. So we can only hope that the second option isn't the one that we need to get bumblebee into the US, hopefully they'll let us in. Yeah, because it's absolutely crazy. We never heard anything about it, first of all, and we didn't need anything like it for any other border and we've crossed already now like 18 borders. It would be so weird if we suddenly need to apply for something six weeks in advance. It can't be real, please be not real. It wasn't a pleasant morning for sure. Yeah, it was a pretty terrible start to the day. Yes, because if we can't take the motorbike to America, then the world record is finished. We don't have a lot of option B for this part, you know. What can we do, you know? Can't do anything. If we can't get the bike into the US, then I don't know, the trip just stops there. And the other issue is that we've only got allowance for the bike to stay in Mexico for another about two weeks. And if we overstay that, then we lose our $400 deposit and we have no idea what happens to the bike. So basically, something needs to happen to get this bike out of the country one way or another within the next two weeks. Yeah, it's not too much fun. But anyway, despite all the sickness and despite the uncertainty, we have to continue on as if everything is all right. And that means today, heading to the ferry to get the ferry over to Baja California. So let me show you guys the route for today. So we are here and today we're going to be following this green road up the coast to reach here to Polo Bambou next to Los Moshes. Ready for the ferry to Baja California. So basically, we're going to take the easy route today. We're just heading on the 15D, which basically going to take us all the way along the coast. We're aiming to get to a place called Topolo Bambou where Baja ferries run a ferry tonight. I think it's leaving at like 11 o'clock at night. 11 or 12 o'clock, yeah. Yeah, so we have plenty of time to get there. Google Maps says it will take us four hours and it's 12 o'clock, so we can relax and hit the road. Okay, so we're halfway through our journey to Los Moshes and we just checked our emails and we had an email from the Environmental Protection Agency in the US and basically what they said to us is you do need an Environmental Protection Agency exemption in order to get the bike into the US. We asked him, can we go in without this? And he said, no, you need this letter from us. So then we asked how long that would take to get the letter and he said it would be between 14 and 21 business days. We've actually booked in to get married in Las Vegas and that wedding is supposed to happen in just over two weeks and my brother's coming from Australia, my parents coming from the UK, my sister's coming and they've all booked their flights to come over and that's literally happening in 16 days. Yeah and the problem is 16 days means actually 10 business days. Yeah and they said 14 to 21 business days for them to give us this letter. So even at the minimum 14 it's basically the day of the wedding already and there's no chance of us being able to cross the border and ride all the way to Las Vegas before then. So we're definitely in a bit of a pickle at the moment. I have emailed them back and I've asked if there's any way that they could sort of expedite the process. I even sent, I emailed them back and said that we were getting married and we were doing the Guinness World Record. So yeah, I don't know, we have to see if they get back to us on that one. We are still going to go towards the border. The plan for this evening is that we won't take the ferry and we will book a room and just try to research it a little bit more and try to see if other people like cross the border without the letter. If there's any chance of us to get into the USA because after crossing so many borders we didn't really think about or maybe we should research something or like yeah, read something about it. So we were just like okay let's go and now we are in a really, really big, big kicker. I guess at this point we have to go towards the border. We have to hope that this letter comes sooner than expected or we just have to go to the border and try and cross it. I don't know, I don't know for now. It's really crazy because we spent so much time organizing this leg, this flight from North America to get over to Asia like this final shipping over to do the last leg of our journey that we missed like this little detail of what's right in front of us and that's the US border. It's crazy that we spent so much time and effort talking to agents and organizing what we thought would be the most difficult part when actually the most difficult part was just getting this letter from the Environmental Protection Agency. And it's not even that it's like crazy difficult, it just takes so much time. It's like 14 to 21 business days. There's like so much time. Yeah, I mean of all the borders that we've crossed so far like 20 borders we've had to do nothing in advance. We even managed to get the bike imported into Brazil in a container that everyone said that was impossible to do. They'll never get it in through customs and we actually managed to do that and then we fall at what is actually a very easy hurdle of just a few weeks in the past. Applying for this letter, get the letter, go through the border. That's crazy how we could miss that one detail. Yeah and I read like all the comments pretty much on my overlander now and I can't read anything about it. Like no one has mentioned anything about this letter.  I don't get it, I really don't get it. Let's just hope we have enough time that we are early enough that we can get this sorted. Yeah and normally even the Vegas thing wouldn't be like a crazy issue because we would just maybe like drop it or something. All this family is actually coming from like from England so we have to get married now like on this day. This one, the motos is doesn't have a light. Oh maybe it's for free. It might be for free. That would be good. After paying so much every time. Let's see. We'll see. Hola. Hola. Doce, oh 12. 12. That's one of the cheapest payages yet, hey? Yeah. That's because the road is so bad. Gracias. Gracias. Okay, yeah, let's go. All right. One hour to go, nearly there and my nose is still running and horrible.   Yeah, what a day. It's so nice that guy he invited us for dinner. Unfortunately I said that I'm a bit sick so I said we couldn't do that. But then he said oh, let me come to your hotel. I'm part of a biker club. I'll give you my patch from the club. He's going to come by the hotel later and give us a patch from his club. How nice is that? We just wanted to take a minute to tell you guys about our amazing sponsor On Vacation Doctor and their super handy app for people traveling the world like us. The On Vacation Doctor app connects you with top English speaking doctors in any country in the entire world. Just put in your location and this app will provide you with a name, the location and the phone number of the nearest English speaking doctor to you. It also provides local ambulance, fire and police numbers as well as the local embassy address and phone number. But the awesome thing about this app is that it's absolutely free to use for the first six months and then only $4.99 for the next six months. So super helpful and super affordable. Show your support for our very first sponsor by downloading the app for free today by clicking the link in the description below. Stay healthy, travel safe and now back to the video. What kind of bouncing road is that? What's bouncing? Geez. So finally we've made it. We're here in Los Moshes. We survived the day. I didn't know if I would to be honest in the morning but we're here. Yeah our hotel should just come up in two minutes. Yeah which is the name of the hotel? Lorena. Hotel Lorena. Is that me or him? I don't know. I think it's me. Okay. But it does kind of freak you out a little bit. Yeah totally. Yeah our hotel is pretty much in the downtown of Los Moshes to the whole day on one tank. It's not bad. 201 miles on 87 octane fuel as well. And we still got 45 in the tank so that's all right. I cannot be bothered to fill up today. We're going to stop. We're going to rest. We'll fill up tomorrow. Yeah let's hope that we can get all our energy back overnight. And this road's bouncy. Wow. I really would love to see us from the side. Like going along the bouncy. I mean our suspension so needs a fix. We so need to fix that. Oh my goodness. Okay it should be right about. Ah yeah Lorena. So we're just unpacking Bumblebee. And look who arrived on this on the shadow ride here. It's Axel Escalante. Hello. There you see your bike. Nice. 550. Yes he is. Very cool. And Axel has a present for us. Oh thank you so much. He's a friend, a boy, he's MC Los Moshes. Wow. It's amazing. And this is a motorcycle club? Yes. Yeah this is my young president. Your president? Yeah. And the motorcycle club is called Old Boys. Old Boys. Old Boys. Old Boys. That's awesome. Thank you. And good luck. Thank you, thank you. Happy the life. And very mentally and physically tired. But we have a really cool room here. Check that out. Look at this TV. It's like so old school. And then we have one big bed here. A little bed here. It's really nice and clean. And also we have a nice air condition here. The bathroom. The bathroom is really nice and the big shower. So the room is nice. But that's pretty much the only thing that has worked out well today. Because everything else is kind of a disaster. Because we haven't had any replies from the Environmental Protection Agency. The official turnaround time 14 to 21 working days is not good for us. Everything is so connected. The wedding from that wedding point we had planned the next bit. Which was going to take us up to Canada for our flight. For getting Bumblebee shipped over to Asia. And this pretty much is going to happen in four weeks. And if the turnaround time is like 21 business days. I mean then we have maybe like three days to ride up from Mexico to Canada. It's impossible. Yeah, yeah, no that is completely impossible. At the moment we really don't know what we can do.  Take advantage of this nice room with the air conditioning. And we're going to try and see if we can figure out some sort of solution tomorrow. So that's it from us today. We hope you enjoyed the episode. Sorry that it was really really depressing today. But it's just how we felt like since we woke up. It was just like. But anyway, share the video with your friends and family. Comment below and we will see you next time.


Good morning vlog. Welcome back to my channel. If you're new, subscribe, join the family. Today, I've got an appointment with a mental health support worker. It's the first appointment I've ever had with this team. So... Hopefully it'll go well. I thought I'd do a daily vlog because I don't know what to say in film. I don't feel comfortable with some ideas throughout the day so I can film videos for over the weekend because over the weekend it's my birthday and I don't want to be attached to a camera all the time. I'm just chilling, watching I'm just the new black. I'm running on no-wower sleep. Normally I have morning nap after my mediation. But I just couldn't fall asleep, so I ended up watching I'm just the new black. I've nearly finished and I don't know what I'm going to binge watch when I finished it. So any series of recommendations, leave them in the comments down below. Any Netflix recommendations. Waiting for a bus with me. I'm back from my appointment, which went well. The appointment went well, like I was saying. It was more just getting to know me with chat about my past. We talked about uni. We talked about horror films. She reviewed how I was doing gun and the lower doses of my medication. And yeah, that was just the appointment. It was just the get to know me sort of one. I got into the appointment with her on the 6th of January at 12. But yeah, that was what my appointment was. Thanks for coming with me on this journey and I will see you guys tomorrow with a new vlog.


and welcome to module 5 of chemical kinetics and transition state theory. Today we are going to use the dynamics in phase space that we learnt in the last module and calculate what is the equilibrium density matrix. This is a very famous relation which is attributed to Boltzmann. We will use this equilibrium density matrix to calculate average quantities and then we will calculate the Maxwell Boltzmann relation. So, just a quick recap in the last module we looked at the density in phase space rho of q, p. This density is the density of finding the system at the given point in space which is q, p and again q, p represents the phase space. We also derived, not derived really, but verified the Hamilton's equations of motion given by these equations del qi over del t is del h over del pi and del pi over del t is minus del h over del qi, very symmetrically looking equation. So, we will move forward with this and what we want to find now is how does density matrix changes with time? I have told you how q and p changes with time, good. But as I have mentioned in the last module, we are really not interested in dynamics of q and p completely because it is a very, very large space. I am more interested in finding the dynamics of rho. So, we are going to assume one statement or the derivation can be slightly mathematical and complex. So, we are not going to cover that in this course. It is called the very famous Lieuvel's theorem, another very famous mathematician and he was also exploring the dynamics of our nature, the differential equations that govern our nature and he figured out one very, very strange and powerful theorem which is called the Lieuvel's theorem, d rho over dt is 0. I must here emphasize this is a full differential, I have not made a mistake. This is a full differential with respect to time, not partial differential. So, this is not partial differential. For those interested students who want to read a proof of this, I have provided a link here. This is one of the rather concise proofs. The proof, there can be more complex proofs coming from divergence theorems that you can also look at. But this one will give a proof in a rather simple language. So, if you are interested, you can look at this proof, you do not have to. First, let me tell you what this Lieuvel's theorem mean, what am I talking about? What the implication of this Lieuvel's theorem is, let me draw a one-dimensional phase space. Well, there is no one dimension, it is always 2D, q and p. So, I have a one-dimensional system which is only q and the corresponding momentum p. What this is saying is, let us look at some point in this phase space. And essentially, let us look at a little box here of length delta x and length delta p. And I have some density of particles in this box. And we are going to look at delta x and delta p being very small. Lieuvel is asking the question, fine, I have this very small box. How does this box changes with time? How does this box evolves with time? So, each particle in this box is having some dynamics. And I end up getting a new box that perhaps looks like this with some new delta q prime and with some new delta p prime. Lieuvel says that delta q into delta p is equal to delta q prime into delta p prime. So, the volume of this little box does not change with time. It can get reconfigured, its shape may change, but the volume will not. And in retrospect, it is not a very strange thing really, is it? What we are saying is that the number of particles is effectively conserved. We are starting with some particles. Well, they may expand or contract a little bit, but the net volume does not change, its shape may change. So, that might be intuitive or non-intuitive depending on you, but we do have a rather mathematical proof of this. And in this course, we are not going to write the proof, we are not going to cover the proof, but we will assume this statement to be true. And we are going to look at the consequence of this theory. So, let us analyze this d rho over dt. d rho of q comma p comma t, we are being more formal, over dt is given by, you remember your chain rule, it is given by 3 partial differentials, del rho over del t plus sum over i del rho over del q i del q i over del t plus sum over i del rho over del p i del p i over del t. So, here and here I have dropped the brackets just for notation is, but at all points, the rho is the same as rho of q comma p comma p. So, this is corrected for all rho. We are interested in rho equilibrium, that is what we are trying to find in this module and play around with it. So, rho equilibrium, in the last module we specified an important property of this, which is that rho del rho equilibrium over del t is 0. That is rho equilibrium does not explicitly depends on time, it depends only on q and p, that is the very meaning of equilibrium. So, I can get rid of this term, this whole thing is 0, value this theorem. So, I end up with only this equation for equilibrium, if rho is non-equilibrium, then del rho over del t may not be 0. Well, what about it? We get an equation, let us massage this equation a little bit more and what we get is, so this differential equation will hold true only for equilibrium density matrix. So, now we will put in the Hamilton's equations of motion for d q i over d t and del p i over del t. So, I will get this is equal to sum over i del rho equilibrium over del q i and del q i over del t, look back into your notes, this is equal to del h over del p i over del p i and del p i over del t, you can again look back into your notes, this is equal to minus del h over del q i this is equal to 0. Let me just take this equation and write it slightly cleaner, I will take the summation together of these two terms, I will take the negative outside and I get this equation. So, I have this equation that I have just copied here in this slide, what do I do with this equation? As it turns out we can solve this equation and the solution is slightly hard. So, in this course, we are simply going to state you the solution. The solution is rho equilibrium is equal to sum n into e to the power of minus beta and h is a function of q comma. So, I will leave this as an assignment problem to you, this will be one of the assignment problems to verify equilibrium satisfies the above equation. So, you have to substitute rho equilibrium in this above equation, take its derivative with respect to q i and p i and show that this sum over i will come out to be 0. So far, what we have got is rho equilibrium is n into e to the power of minus beta h, where beta is a constant so far, I have not specified you what beta is. But this particular rho equilibrium might be reminding you of something very specific. In statistical mechanics, you must have seen the distribution from a different perspective for canonical ensemble, some constant into e to the power of minus beta e i at a particular e. In that statistical mechanics, beta was 1 over kT, where kB is the Boltzmann constant, you have to be as famous as Boltzmann to get a constant after you. Note that h is the equivalent of energy, it is a function, but that is what gives me the energy. So, we note these two equations and we will postulate that beta is 1 over kT for us, even in this equation. So, with this, I want to make a few comments on this distribution, this distribution is called the Boltzmann distribution. This distribution holds only at equilibrium, never ever make the mistake of assuming this distribution out of equilibrium, out of equilibrium I have no idea what this rho might be, that is for a totally different course. Another somewhat confusing point that might appear to you, this rho is a statistical answer, it is a highly averaged answer. What I mean by that? Suppose I take a small system, I take a box with a 1000 gas particles in it and I find the distribution of q and p at a given instant of time, that distribution might not follow this Boltzmann distribution. However, if you increase the size of this system, instead of using 1000, I use million, I use billion, I use 10 to the power of 23, I use 10 to the power of 100. So, as this number keeps on increasing, my distribution will tend to this Boltzmann distribution. Or if you do not want the large system, you may ask that is all good and fine, but my system is finite only. After all in this room that I am sitting in, I have a finitely many number of gas particles, will Boltzmann distribution not hold in it? It will if you average over time. So, for even a finite size of particles, if I take the distribution at different snapshots of time, I find it at some time t0, I find it again at time t1, I keep on doing it and I average them, I am going to get back this distribution. This is by the way called the ergodic hypothesis, just an extra bit of information. So, what we have got is this Boltzmann distribution in phase space. It is very famous, I have just written it out clearly here. Let us get into what is the normalization constant n now. So, one property that we had listed is integral over all phase space will always be 1. Well, this should also be true for equilibrium density matrix. If it is true for any rho, rho equilibrium is just a special case of a density matrix. So, this must also be true. So, I get integral dq integral dp n into e to the power of minus beta h, n is a number it is a constant. So, I take it out of the integral and I get n equal to 1 over integral dq integral dp e to the power of minus beta h of q, p. As it turns out this integral that you are looking at is a very important integral. This is called the partition function. Whole of statistical mechanics is dependent on this integral. Now, we can calculate any property we want in statistical mechanics using this partition function. So, at the end I get n equal to 1 over q or rho equilibrium is equal to e to the power of minus beta h q, p divided by q. So, now we will look at if we have this rho equilibrium. What do I do with it? Can I comment on something useful out of this rho equilibrium? And the answer is to calculate any useful property you always average over phase space. Again, I do not care about where each particle is. I also usually do not care about a property at a given point in space space. I want to calculate an average quantity with like temperature. So, once more a reminder of our 1D example have let us say q and p and I have some quantity some function defined over q and p. And I want to find the average of a. What am I going to do? Well, I will integrate over q. I will integrate over p over all possibilities. I will find the probability that I am at that q, p that is given by rho multiplied by a of q, p. So, that is our usual trick of finding averages. We find this property that I want to find average over at that given q, p. I find what is the probability that I am at that point. And then I just integrate over all phase space. So, in general for an n dimensions I will let me write 3 n dimensions. I get average of some quantity a where a is some function of q, p to be an integral over dq integral over dp rho of q, p a of q, p. So, I have calculated an average quantity now. And once more just to remind you integral over dq integral over dp is a shorthand for dq 1 minus infinity to plus infinity minus infinity to plus infinity of dq 2 till minus infinity to plus infinity of dq n minus infinity plus infinity of dp 1 minus infinity to plus infinity of dp n, it should be 3 n. So, I am integrating over every possible coordinate and momentum. And rather than writing this rather ugly and long many integrals, I denote it by integral over dq vector, integral over dp vector. So, let us take an example. Again let us revert back to one dimension and let us find what is average momentum. So, I have a property which is p. So, a is p now and I want to ask you the question what is average momentum at equilibrium. So, we will use the prescription that we had. So, in 1 b q, p at rho equilibrium of q, p is given by e to the power of minus beta h of q, p divided by partition function q. So, we will simplify this a little bit. My Hamiltonian is given by p square over 2 m which is the kinetic energy plus v of q. And q is integral over dq, integral over dp, this e to the power of minus beta h. So, the average over momentum as defined in the last slide is dq, dp, p the quantity I want into rho equilibrium. So, let us substitute these quantities that I have written. Rho equilibrium is e to the power of minus beta h divided by q. And I will substitute the q here in this equation. So, I get integral of dq, integral of dp e to the power of minus beta h divided by something that will look very similar. So, q is the number q I have taken out of these integrals and substitute q equal to integral dq, integral dp e to the power of minus beta h. In all of these places I have limits from minus infinity to plus infinity. Let me put all these integrals there minus infinity to plus infinity. So, how do we calculate this? How do we simplify this? So, let me just write down what I had got in the last slide dq minus infinity to plus infinity dp minus beta h into p. And now we are going to substitute our Hamiltonian here. Hamiltonian was p square over 2 m plus v of q into p by the same I am not going to I am going to stop writing integral limits. So, we will open this exponential and note that this is equal to. So, I have taken the part that is dependent only on q on the integral of q only and the part that is dependent on p only in the integral of p. And in the denominator I do the same this looks like a complex integral to solve. How do I do it? It is actually trivial to solve this is actually equal to 0. Why you ask? Well, you see this cancels with this. This is easy these look a bit nasty, but you note that the numerator this is this function that is there what you notice is that this is an odd function. So, f of minus p is equal to minus of f of p. And what do you know about integrating an odd function over all space? It is equal to 0. So, the numerator is 0 and so the whole thing becomes 0. But well this is perhaps you already something you expect do not you? The average momentum should be 0. It does it at thermal equilibrium all directions are equivalent to the particle has equal tendency of moving forward as going backward. It does not mean that every particle is at rest the average is 0. So, I have a question challenge for you can you estimate what the average kinetic energy is going to come out? So, let us assume I have two different chambers at same temperature T one filled with helium and other filled with argon. What do you think will be the average kinetic energy per atom for these two chambers? So, take a moment think about this answer very carefully go to the link that is provided here and provide your answer there for an immediate feedback. Do you think the helium is will be larger for helium it will be smaller or both will be equal and if you do not know be honest and you can write I do not know this is all anonymous. So, take a pause and answer this question. So, we will quickly look at how to solve this question. Well they have to be equal that is my claim we are going to prove it mathematically, but we already know they must come out equal. How? Because the average kinetic energy is essentially related to temperature and two boxes come connected to each other of whatever molecules are filled with in helium, neon, argon, nitrogen, hydrogen, atmosphere whatever at equilibrium the average kinetic energy must be equal. Because the temperatures are equal ok. So, we are going to prove this statement this intuition that I have. So, we are going to calculate the average kinetic energy p square over 2m now just like we had calculated the average p. So, now we will play the same tricks is well integral over dq integral over dp overall space that is your rho equilibrium into p square over 2m. So, just like we did in the for average momentum we will separate these and write the Hamiltonian and the denominator will be the partition function which looks very close to the numerator, but not exactly and we again do the separation of q and p.  So, the first thing that you notice at the potential term exactly cancels. So, it my gas might even be interacting it might be hydrogen it might be whatever gas you want even water vapor the potential term will exactly cancel. And so, we have to solve these nasty integrals that are here. So, to solve that I have provided you the integrals here. So, use those plug them in and calculate these. So, this is going to be another assignment to be able to solve these integrals using the provided integrals. And you have to show that this is equal to half kb so, 1 over 2 beta. So, this is another assignment problem. We will stop here what we have today looked at in this module is how equilibrium density matrix comes about from the fundamental equations of motion. We have skipped a few steps in the proof we do not derive the Louisville's theorem completely, but it is to motivate where does this partition where does this density matrix comes about. So, you do not need to know the details of the proof that we have not covered. But what you need to know is what is the origin of this equilibrium density matrix. We have used this equilibrium density matrix to calculate averaged quantities. We have looked at average momentum and average kinetic energy today. So, with that we will stop today. And in the next module we will look at one of the very famous distribution which is the distribution of speeds. Thank you very much.