authors at Alden, although I don't know if any of us are actually at Alden right now, but in spirit we are. So today it is my great honor to introduce our esteemed guests, Dr. Carolyn Bailey Lewis, who will be interviewing Dr. J. W. Smith about his 2019 book, From the Back of the Bus to the Front of the Classroom, My 30 Year Journey as a Black and Blind Professor. Dr. Smith earned a BA in History and Speech Communication from Indiana University in 1982 and an MA in Speech Communication from Purdue in 1985 and his PhD from Wayne State University in 1989. Dr. Smith has been teaching since 1983 and is a professor in the School of Communication Studies at Ohio University. He is a renowned researcher in the areas of communication and disability and African American rhetoric. In addition to the book that he's talking with us about today, he is also the author of the book Essays on Communication and the Blind and Visually Impaired, as well as numerous book chapters, conference papers and articles, including articles in the Braille Monitor, the flagship publication of the National Federation of the Blind. In 2004, Dr. Smith was awarded the National Federation of the Blind Educator of the Year Award and in 2007, the NAACP Image Award for Research and Teaching. He has served on the Ohio Governor's Council on People with Disabilities and as president of the National Federation of the Blind of Ohio. And in 2018, Dr. Smith was selected to serve on the State Rehabilitation Council for Opportunities for Ohioans with Disabilities. Interviewing Dr. Smith today is Dr. Carolyn Bailey Lewis and Ohio University Emerita in Communication Studies with over 38 years of experience as a public broadcasting and media professional. She earned a BS in 1971 and an MS in 1987, both from WVU and her PhD in communication in 2007 from Ohio University. Dr. Lewis has worked at West Virginia Public Broadcasting and at the WOUB Center for Public Media here at Ohio University. Dr. Lewis was the first African American in the United States to serve as a general manager in a public television station. In 1993, she was awarded the Neil S. Bucklew Social Justice Award from West Virginia University and in 2001, the Telly Award for her narration of Wandering Souls. In 2015, she was elected the hometown hero of Southeast Ohio by the American Red Cross. And in 2020, she earned the Medal of Merit for Professional Achievement from the Ohio University Alumni Association. So join me together in clapping with your mics on or off to welcome our very esteemed guests. We're so happy to have you here and very eager to hear everything you have to say. To the dean in his absence and thank you Dean Kelly and to Jen and the Aldrin Libraries. We appreciate this authors at Aldrin Opportunity and JW for asking me to be your interviewer. I appreciate that. My colleague, mentor, brother and friend, JW has spent more than 30 years inspiring, challenging and encouraging and shaping the lives of thousands of students. Along with effecting change for persons with disabilities in the university and Athens communities and beyond. Helen Keller said optimism is the faith that leads to achievement. Nothing can be done without hope and confidence. Like Keller, advocate, remarkable, extraordinary abilities, activist, living with no boundaries to courage and faith. Author, such is the exceptional life of JW Smith, his optimism, hope and confidence. Despite the disability, has that achievement beyond measure for this man of faith, humor and intellect. JW, good to see you again. It's always good to be with you, lady. When I teach classes at the beginning, sometimes I ask my students, who are you? Who do you want to be? And I'll say, well, I want to be a doctor, a lawyer, a teacher, a mechanic, nurse, whatever. I'll say, no, no, no, it's not the what, the who. So who is JW Smith? Who am I? I am a person who is inspired to inspire. I am a whistler and a hummer, which usually is a telltale sign of how I'm feeling, which is basically hopeful and optimistic most of the time. And I'm a person who likes to feel good and make others feel good. And who inspires you then, if you could name one or two people? There are so many. There was a drama teacher that I had in high school. Yes, I was in drama and I was in plays, one of them being Raising in the Sun. I was Walter Lee Younger, I'll never forget it. But a drama teacher named was Mrs. Hall. I don't talk enough about Mrs. Hall, but she taught me a valuable lesson one time. I was performing as a senior in high school at one of our rallies or assemblies, whatever it was. And I finished playing the piano and I had sung, I think it was God Bless America or something. And I went back to my seat and people were clapping and cheering. And I went back and relaxed and took it easy and was observing others. And about 20 minutes after that she came over and tapped me on the shoulder and she said, you know, it's okay if you clap for other people too.  So I never have forgotten that.  And she's just amazing. And then to meet my wife, Mary in 1986. And the fact that she's put it with me this long, I don't even know how that's possible. So I would say those are my inspirations. From the back of the bus to the front of the classroom, my 30-year journey as a black and blind professor published in 2019 by Monday Creek Publishing. It chronicles your 30 years as a black and blind professor in the field of communication studies and also looks at the experiences and how race and differently able to intersectionally have influenced documented encounters. So why write this book now? Well, I was thinking I'm getting old there. And I want to put some of these stories down before I forget them. And another reason to, you know, I don't know of any other black and blind professor in our field of communication. There may be someone else, but I don't know them. And in some ways that's awesome responsibility. So I wanted to leave like a trail for the next person that comes along in the field of communication studies. You know, that might learn something from my story. And then one day I was just sitting and I was thinking I was coming up on 2018-2019. I wanted to do a sabbatical and I was like, what do I want to do? And my mind went back to the first time I walked in the classroom with my PhD in 1989 at Indiana University, South Bend. And I was like, wow, that's been 30 years. Why not, why not, why not put down some of those stories, some of those memories? And the book was born. You're right, of course, as a blind person. So how did you do it? What were your processes and who helped you? Yeah, I mean, so many. You know, I mean, one thing being blind since birth, so it's the only life I've known. So I learned all the coping skills at a very young age. Now, you know, but this is before, you know, cell phones and internet and all these great gadgets now that would have made my life so much easier in many ways. But I learned Braille at a young age. I learned how to use readers at a young age as well. There's a skill to that. And so I don't even know where to start with the help. Just meeting people along the way. I think there's a chapter when I talk about my graduate days, when my wife literally typed my entire dissertation by me dictating it to her.  You can't even, you can't even replace that kind of, that kind of wonderfulness. That's not a word, but it works for me. I've had great professors along the way. You know, I tell people, I had three types of professors when I was coming up this before ADA. The largest group where the people tried to help me and said to me, look, you're the first blinds you've ever had. I don't know what to do. You tell me how to help you and we'll make it work. The second group, thankfully, was much smaller, but still there basically said, look, you sit over there in the corner. Don't bother me. I won't bother you. I'll give you a B or C and let's get this done. It was not said that way, but it was understood. And then there were two or three that basically said to me, yes, this is 1970s, early 80s. I don't want you in my class. You don't want to be in my class. Let's not even go there. Thankfully, that large group was a group that worked with me. So I did everything from taking exams by tape recorder. Most of them I took by going to the professor's office and he would, he or she would read me the exam and say, hey, what's your answer?  You better know it. And I always could type. So I typed some, I did everything possible to get through whatever class I had to do. And traveling, I've never been afraid of traveling, you know, so I grabbed my cane and go and walking. So I, you know, growing up in Chicago and then Gary, Indiana, then Detroit. So I grew up in the big city. So I was never afraid of traveling as a blind person. It's all about confidence. So I, I was never afraid of that. So all I had to do is learn some of the basic skills. I had the right attitude for it. And then the final thing I'd say is I grew up with sighted people. I know that sounds weird, but a lot of blind people don't. And so they're not comfortable in the sighted world. I've always been comfortable with sighted people. So I've known how to communicate with sighted people. I've known how to make them feel at ease or, or lessen the stress when they come in contact with me. And that's been helpful too. I'm glad you mentioned traveling, because you know my story. Yes, I do. Well, you ought to tell it again, though. I think we'll go back a long way from the early days when I got here, or I'll say early days. In 1997 I got here and the Presidential Advisory Council on Disability and Accessibility Planning was in progress. And he had been a one person advocate on this campus trying to get things changed.  And so I got to know Dr. Smith a bit. And then one day I was wanting to go somewhere and I had to go by myself on an airplane because my husband passed. And I saw him going up and down the street just whistling. I said, where you going? He said, Detroit. I said, with who? I didn't see anybody with him. And he said, I'm going by myself. How you going to get there? Going to Columbus and get on the bus? Get on the plane. Okay, so he inspired me and so many others. Like this quote says, you can do things you think you cannot do. So I'm thankful for you for that and for so many other things you've done. But you said you would like to pick two of these stories, favorite stories and anecdotes and tell them as exemplars of your academic journey. What's one of two of those stories that you want to tell? There's a nice segue. Let me tell the one about, I know you read the book, you know, you know this story, but it's one in grad school when I was at Wayne State University, which by the way is a third largest school in Michigan. People forget about that place. Like 30, almost 40,000 students there. Although most of them are, I don't know. There are people out there, who are just on the streets, but you know this story. But it's one in grad school when I was at Wayne State University, which by the way is a third largest school in Michigan.  But there's a lot of dorms, too. But so what I got there. I had to learn my way around campus, you know what I mean? and got some professional cane traveler to teach me, but I didn't have the time for that, you know. And I mean, I didn't want to waste their time because I didn't need that. So I said, what is the best way for a blind guy to learn his way around this town and this university? And somebody hit me and said, find another blind person. I'm like, okay, that's easier said than done. And went over to the disability office one day and I was a blind guy working there. And I said, hey, let me talk to you. We struck up a great friendship and he taught me all the tricks of the trades and there are tricks, you know, but that totally blind. Now he had not lost his sight until he was in his 20s. So he was not new, you know, he was newly blinded, but he had learned a lot of those tricks of the trade and he taught me around that campus. And one of those tricks was one day we were walking, it was a nice sunshine day, you know, and we were walking to go get some lunch at this restaurant called Johnny's. I'll never forget a Greek restaurant called Johnny's. He had their best bread. I had about two blocks from my office. So he would meet me at my office and we'd walk over because it was near his office. So when he'd walk over for lunch and then we'd walk to his office or I'd let him go and I'd walk back. So we were walking one day and we're talking in nice sunshiney bay and he said, stop. And I was like, okay. And he's like, listen. And I stood there and he's like, I was like, what, I mean, what are we listening to her? And all of a sudden on my left, these loud high heel shoes came flying by, zoom. They were, I mean, they were moving. And he was like, okay. He said, lock on to those high heel shoes and let's follow her. And we assumed it was her. She's going our way and let's see how far she takes us. We followed that, those high heel shoes all the way to that restaurant. And I hope she never knew we were following her like that. He's like, that's just one of the tricks. And I was like, oh my goodness, only another blind guy could teach another blind person something like that. So I had to include that. And he ultimately ended up coming to my wedding. I ended up coming singing at his wedding. It was an amazing relationship. Can you talk about the snake? Oh gosh. My public speaking teaching days. Which people always talk about, you know, how does a blind guy teach public speaking? I mean, that's in the book. You got to get the book to know how I had my little tricks. But I was teaching public speaking at University of Detroit. I never shall forget it. I don't think they call themselves that now. I think they're like Mercy College or something. And that was a cool winter morning. We used to hear like seven speakers. So I think it was a fourth speaker that day. At that time, we used to have a lot of demonstration speeches. You know, people would come in and teach us how to make a cake or pizza or some other crazy thing. But another thing they would do is sometimes bring in like their pets, you know?  So this girl, she came up to me before classes. She said, do you mind if I, my boyfriend and I bring our, my cage, I'm speaking on Wednesday or Thursday. I said, no, I've got, I've had pets all the time. So I don't care. So when they came in that morning, I was a little concerned when they slid the cage beside me because it was like really quiet. I'm like, whatever, you know, maybe, I don't know. She got to speak and one of my tricks was to stand right near the podium so I can hear everything I could catch in terms of nonverbals and stuff like that.  And I knew I was in trouble when she got to the end of her introduction line and she said, now I want you to meet my friend and pet, Sam the snake. And she reached over my back and pulled this ball constrictor out of her, out of the cage and let it wrap itself around her like a few feet from my head. And I'm like, oh my goodness, here we go. And she said, it's good, it's a little cool in here cause he's a little lethargic. And I'm like, yes, it is good. It's cool. She did her speech, put the snake back in the cage. Her and her boyfriend took it out and they never came back to class again. So I don't know if my face reveals that the kids seem to love it. I don't know why she never came back to class. After that, I said, you know what? No more live pets in this class, bring a picture, bring a stuffed animal, no more birds. Cause I had birds flying around, rabbits, no more live pets. I never shall forget that. And talking about issues of race, you discussed how some of your stories have been impacted by your race and your ethnicity. Yeah, you know, thankfully, you know, the one conclusion of this book is that thankfully I've been a blessed, I haven't had to deal with too much blatant racism, at least not confrontational. But you know, there's a one story from my graduate days when one of our more famous faculty, he was a big hockey fan, he loved hockey. And he was a big sports fan. So we talk about sports and one day he was joking, we were talking and we were talking about athletes interviewing after games, you know how they butcher the language sometime and they can't get a word out and you know, and this was like 1987 or something. And he said, now, again, I must admit, I don't know whether he was joking or like he had a look on his face, but I think he was serious.  And I sort of chuckled and he walked off. And afterwards I thought, okay, now this may be just me, but in 1987, I don't think there was not one non Caucasian hockey player. And I thought to myself, I'd like to have that encounter back and not let that be the last statement. So that was an issue. And then, you know, here we, in our department, we had a black female apply for one of our jobs and they came here and they didn't get the job for a lot of reasons and probably should not have. But what her visit showed me when she left and she didn't get an offer, it showed me how lonely I was. Having her here for a couple of days, just being able to talk to her as a black female, it really crystallized to me how lonely I was. I mean, it took me a couple of months. I couldn't go to a faculty meeting for a couple of months because I didn't know how lonely I was. I didn't know how starved I was for cultural interaction and exchange. And that really, that actually kind of shook me up because I didn't see that coming. So that's at least two experiences where I'm pretty sure that it really turned the spotlight on the issue of race for me. What did you learn writing this book about yourself, your experiences, experiences rather than an academic book or an article that you didn't know before about writing this and publishing that you didn't know? What did you learn? That's a very good question. I learned that you know, age and time really does give you perspective that nothing else really can. As I was going down those memory lanes and thinking about some of those past experiences, I used to go to weddings and events and I hear when I was younger, I hear these older people say, yeah, 25 years ago I did this and I'm like, oh my God, how old are they? 25? And then I started doing the same thing. And I'm like, okay. So that was a crystal clear lesson for me. This process also taught me to really appreciate where I'm at. When I wrote the chapter about how I got to Ohio and why I'm still here and I got to relive why I stayed here. I mean, you have to read that chapter because it's a long story. I had no intention of coming to Ohio University. I'd never heard of it, never heard of Athens. And when I discovered that school at that time, writing this book just made me think about what it was like to come here and how fortunate I've been to be treated as a professor who just happens to be blind. Now that might sound like a fairly innocuous statement but this book taught me just how blessed I am. I have never heard like tokenized or trivialized or I've never felt like I was treated any different in any other faculty member here. That is an amazing, amazing concordance. When I finished the book, I sat there and I was like, I came here in 1993 and 20 some years later, yes, things have changed, people have changed, the department is different. But the humane, the humane, the humane, the humane, the humane, the humane, the humane, the humane, the humane, but the humanity is still here. I still feel respected and invited and I felt so good that I never wanted to take that for granted that I could put that down and I have wanted for years to put down that chapter, that story about how I came out. I've told the story in a variety of settings but to actually put down that chapter, I think it's chapter three, to actually put it down when I finished reading, I said to myself, now that's what I wanted to do for years to tell that story of how I got here and why I'm still here. That was almost cathartic for me. Your book is on Amazon and a couple of quotes that people gave in their reviews. As a black and totally blind individual, he muses about how this distinction has both colored and shed light or what might have been an innocuous or unremarkable encounter. This memoir is riveting because of its vulnerability, candid honesty and fresh transparency as well as the conversational tone and quality. It's an easy read but one that can also cause reflection and soul searching without much warning. So things just sort of sneak up on us. I know as you read them. So you dealt with Amazon and other booksellers. That experience was probably not new but what advice would you give to others who are thinking about writing but just don't know or publishing and don't know the process? First I'd say if you get a good idea, you know start putting it down. And it helped me to have written the manuscript. My goal was to write it while looking for a publisher and I did that and I got a couple rejections and that gets discouraging. It's like, I wrote one place that was ideal for this book and they wrote back and told me, we only published two books a year and we'd have like 200, I'm like, well, okay. So I finished the book, didn't have a publisher and I was like, okay, but at least I got the manuscript. So cause they always want to see a chapter or a part of it. So I could show them the whole book and I was talking to a friend and he said, have you heard of so-and-so locally? I'd never heard of Monday Creek and I sent them the book and they talked it over with their people and sent me back the contract and we started at Prost. It's been a wonderful experience. Not only are they local, but Jean is such a wonderful person, easy to get a hold of, easy to get the copies of books I need. I can get 10 copies or 200 copies, you know, she can have it done and just so supportive and it just made me feel good to be able to work with somebody locally like that. So I'm sure that not everybody's publishing experience is as awesome as mine has been because you got to find that right publisher. She makes suggestions, she helps where she can in terms of publicity and setting up marketing opportunities but the other part of it is just the invitational atmosphere of the company, you know, and she publishes everything from memoirs to children's books. I recommended her to another colleague of mine and now his book's coming out. It's going to be amazing and he did the same thing. He was looking for publishers and kept getting rejected and then getting contracts that didn't suit his and I said talk to her and he came here and went out to her to her place and the rest is history. I don't want to give his book away but it's going to be amazing. So that is how the process worked for me. She will support me and send me emails about book contests or ways to publish my, market my book.  She's all about promoting Southeast Ohio. That, she is like a quiet gym around here that more and more people need to know about. Absolutely more and more need to know about. Dean Kelly and Jen, I know you want to leave time for questions. I just have a couple of more questions from those who are viewing. How much more time do we have? I'd say maybe another 10 minutes, Dr. Lewis. For interview. Yes. Okay, great. J.W., will there be a sequel? Will there be a sequel? Not like this. This is the last, so yes, I am revealing something today. So this is the last I'm going to write about me. I feel like I've gotten the story out. But don't tell anybody this. Starting next year, I'm going to write a novel, a mystery novel. I love adventure, mystery. I love books about assassins. I know, don't, don't. And so I'm going to write a book like that. I have this concept and I almost, I don't want to give it away because somebody might steal my idea and I will not be happy. But that's going to be my next thing. I'm going to spend next year writing this book. I've always wanted to try my hand at, you know, speeding traffic and mystery and so that will be my sequel. You've been teaching for more than 30 years and lots of experiences, lots of places you've gone, people you've met. How are you able to condense? I think the problem a lot of people have is it got so much. So how do you condense that? How did you do it into that book and determine which stories you were going to tell? Yeah, I, when I got the concept, I just took notes. I, I, I, it's chapter said, okay, what can I remember from my graduate days that will fit this experience? Like when I walked out of my advisor's office one day, we had met about the dissertation.  I have these limits. I didn't even own a computer at the time. I, I was like, and how am I going to do this research? I walked out of that office and went around the corner and I had about 10 minutes of pity and there's no, I don't, I don't even know how I'm going to do this. So those kinds of stories would come up with each chapter. And then my first job, I'm like, what happened there? The only thing I regret is not telling more about the, the national blind educator award. I, I should have included more about that process when I look, when it hit me after the book was done. And I was like, man, I should have expanded that because it was a great process. It was a national award. There was a great story done on it in the, in the Braille Monitor. I should have included it. So that's the one thing that I regret that I, that I wish I had put in. But the other condensing was, you know, was all a part of what, what, what fit the profile. And I've gone back over now that I've done and I've said, was there any story I missed? That other than the national, the blind educators, anything I've missed that I wish I could put in? And I'm pretty, I'm pretty, I'm pretty confident that I got the ones in that I wanted to get in, starting in 1985. Yes, especially the one too about my friend, the same guy that taught me the high heel approach to traveling. He and I decided to take a cross, a cross country trip on the bus from Detroit to Wichita, Kansas to attend this conference, which took four buses.  Well, I'm blind, my friend's blind, and we're cheat, we're grad students.  So we decided to cook up this scheme where he would pretend to be my sighted guide. So we would have to pay. So we were taking these buses and I'm pretty sure these drivers figured it out when he ran into a few doors, tried to sit us down and see what people were. I'm sure they were like, okay, but that was just stuff you did. That's another fun time we had. I went to a conference with you. If you've never gone to a conference with Dr. Smith, you must, one of the most fun times and interesting times you've ever had. He's one of the most humorous people that I know, intellectual, great sense of humor.  You gotta, you know, life is too short and good God, we know that now. It's too short to, I mean, look, I don't want to minimize people. Oh, I'm going to say something else. People are struggling in lottery and so that's real. Now, I'm not advocating Pollyannishness, but I'm saying you got to do whatever it takes to get as much out of life as you can.  You know, what do you do with that? You just, you just, you just thank God for the opportunity. You umbly thank them because no one has to share that kind of thing. And that's, that's the power of communication. When I, when I perform, when I do music and sing, I'm always saying to myself, I have sung this song 20 times, but it might be the first time somebody's hearing this today and they may really need to hear it.  Yeah, it's been a long day. It may be the third night of a three one night stand thing. Somebody needs to hear this song and I'm going to push myself to do it, even though I just did it last night. I've done it for 20 years. I'm tired of it, but if it's going to help them get through something, I'm going to give it all I got. As I close my portion and turn it over to Jen, I just want to say that you said in an interview that your big takeaway is that you're no different than anybody else, no more special and you're just blessed to be in this country and have this opportunity and the love and support you've had through the years, which made all of this possible. And I just want to add that you are a living testimony of a quote by Pablo Picasso. He said, I'm always doing that, which I cannot do. That's you in order that I may learn how to do it. So JW lives out his own feed that our differences can be strengths and that many people live more for affirmation than bread, and that we are responsible to all for all. He's aware about him that is gentle yet strong and a style of engaging both young and old alike. JW who sings and whistles along the way, as always, has been a pleasure. So Jen will now take questions from those of you who are viewing. And let me just say this. This is my, I mean, we are, you talk about one, two punch of OU.  And she said this to me, so I'm going to say it to her publicly. You know, in many ways, she is the sister I never had and wanted to have. I have two sisters, one passed away last year, and her birth deal will be next week, and that's, that'll be tough. And then I have another sister, but we were, we were never really close. And so in many ways, Dr. Lewis is that sister that I wish, wish that I had had and I'm glad to have. Thank you so much for doing this. You're amazing. You're welcome. You've got me now. Can't get rid of me. Jen. Thank you so much, Dr. Lewis and Dr. Smith. Okay, we're going to open it up to audience questions now for either of our, our speakers today. You can either type your question into the chat and I will moderate, or you can raise your hand and then, you know, you can unmute and ask the question yourself. However, you feel more comfortable. Ask first. Dr. Smith, could you compare the process and the intellectual process and the differences between writing your dissertation and any of your books? That's a great question. Um, for me, so I sort of approached a dissertation, you know, it's more of a sort of scholarly thing. I was, as you might expect, I, I had to keep in mind the audience. And also the process of checking and rechecking the facts and the supporting documentation, you know, that was important. So that was very similar in the books that I've written as well. But the difference for me was to get comfortable with the personal side of the books that I've done. Not all of them. Like the campaign book, that was, you know, that was for a specific class and campaign communication. So that was driven by that. The essays on the blind and visually impaired. That was a compilation process in talking about a aspect of our area of the field that was very barren. So when I write, when I wrote this memoir, it was all about how much to disclose, how to tell a story that would be as important and informative to me that it might be for someone else. You know, I'm always so, so the, the, the deciding factor for me in either the dissertation or books is, can I answer the so what question? Why should anybody care? And I'm always asking that.  I can get something from that. And I'm always asking that question. And I answer that better times than sometimes on others. But thank you for that question. It's a very good question. Thank you. All right, Dr. Smith, we've got a question and chat from Judy Kerry Nevin. She would like to know if you were ever thinking of pursuing singing before you decided to go for your advanced degrees. And, and what made you follow the path that you chose? Well, you guys are good. I started singing like 10, 11 years old.    We started singing at those, at those times. And I started professionally singing as a teenager, gospel for the most part. The blind boys of Alabama have tried to sign me several times. I, they almost got me in 1982. They had to contract. I went to one of their shows. They had to contract or like, we'll give you a couple of hours to go pack and go with us. I mean, I almost did it. I wonder what my life would have been like if I joined up with them back then. But I always knew, see, I was a music therapist for a while. So I, I enjoyed the music, but I, eventually the therapist just wore, the therapy just wore me down. So I always knew that music would be a part of my life. But I, but once I made up my mind to get, get the PhD, I decided that I want to be a person that would teach by day and sing by night. So I didn't want to try to earn a living as a musician. I wanted to pick the spots when I wanted to. But another great question. All right. We have a couple of comments in the chat also thanking both of you. So Tasha, out of, out of way, excuse me. She says, I would like to thank this dynamic duo for your advocacy and willingness to share your experiences. So transparently, it is absolutely wonderful to see and hear both of you. And Beatrice, and I apologize, Beatrice. I cannot pronounce your last name. It says, this has been wonderful educational empowering. One is the presence of, is in the presence of greatness whilst listening to my friend, Mr. Feelgood. Thank you to my, to see both of my incredible friends. That's my buddy. Yeah. That's awesome. Yes. I actually have a question for you, Dr. Smith. You talked a little bit about the different processes for writing this memoir and your thesis. And I'm wondering, what are you looking forward to most in your next novel, your mystery novel in that process? Getting away from both approaches. I want to just let my imagination run wild. So that's what I'm looking forward to. Like really upping my creativity. And it'll probably be a real mess when I get done, but I'm looking forward to trying it. Okay.  Would you like to ask your question? I would. Thanks very much. Really enjoyed this. I went to Amazon, since you brought that up before. And I was reading a comment by Dr. Lewis. And you, in your comment, you talked about disability coming before race. And I was just wondering if you both could just talk about that, maybe a little bit more. For me, it's why. Why is that so salient? And just, I was hoping to hear about that from both of you. Dr. Lewis, why don't you start that one? That's an interesting question. Thank you, John. If I decide to go somewhere, I don't think about what color I am, but can I get through the door? If I go to a lodging facility or hotel, can I get in the bed? Can I get through the bathroom? Can I get to the restaurant? I'm going on a bus. I mean, things are much better now, especially since the ADA. But those are things that you still are concerned about. Sometimes I would have a scout to say, go in there. If we stop somewhere at a restaurant, to the restroom and to the seats are not too close together. So I'm not worried about, no, I can get in a place. That's not the issue. I know I can get to campus and get to school, but can I get up the hill? Can I get on the elevator? There are some elevators on campus, believe it or not, that you can get in them, but you can't close the door. So you learn where these spaces are, where ramps are good to use, things have changed. And what just the climate, the environment, will be like the structures. And so that's the first thing you think about. If there's an automatic door opener, is it going to come back and hit me in the face? Or is it going to be okay that I can get through the door? So John, that's the reason that you think about disability first. And then you think about race second. John, I think I mentioned in the book, in the first part, I say, I do a little thing. I may have done it when I've spoken over in your place, but I tell people, close your eyes.  And invariably the blindness wins. And I think that is still true. Now, what's so ironic about that is probably John, 50 years ago, the reverse might have been true, right? In so many ways. So I think, Dr. Lewis, you can agree or disagree. I think in some ways it's gotten better in that we both sort of feel that in most cases, the differently abled sort of supersedes the race issue, except in certain really specific context. That's a great question. I agree. I went to a conference one time in Norfolk. My room was on the 16th floor. So I'm always trying to get a lower floor. At least I can just scoot down the steps if there's a fire or anything. And I said, do you have a lower room? What would I do if there was a fire? All they told me is we know where you are. So I'm not concerned about what color I am in those rooms. So that's the bottom line. Thank you. Thank you. Yeah, these hierarchies that are around there when you start looking at those. Yeah, very interesting. So thanks for that comment. And I was going to say, in addition to your example there, Dr. Smith, with what do you see first, that, and temporarily able-bodied people, I think are the two things that I will always use with my students. So you've left me with both of those and I appreciate it. You're so welcome. All right. I think we have time for one last question. And it's in our chats. And Judy, Kerry, Nevin is wondering, Dr. Smith, what your editing process is like. Could you describe that for us? Oh, great, great, yeah. For me, first, I write the book in my head. I have to get the outline and the concepts in my head. So I take down notes. I can't just write the manuscript straight. I take notes. And then what has worked best for me, I pray about Lord finding me a good typist, someone that can type fast, but also I give them a certain amount of editorial license. And you know the best way I write? I walk and I talk. So I walk around the office and I talk and it's up to them to get it down for me.  But the old preacher in me, I need to stand up and walk around and talk and not have to worry about somebody can't spell or can't get it or can't keep up. I got to find the right person to do that. And I was so blessed to find a grad student here. I was talking to her one day and it's like something said to me, ask her, oh, was she great. She could just sit here and then she would say, what about this word and drop it in so casually? And I had the opportunity either approve it or disapprove it, but she could do it in a way that wouldn't break up my flow. But you know it's constantly editing. And then for this book though, I had another person that I really respected and I would send them each chapter. Please tear it apart. Tell me, are you getting it? Tell me what you would recommend. What changes you'd make. And sometimes it's in back changes. I would accept them. Sometimes I'd say, no, I like it this way. That worked well for me. And I like that process for me. And you had a wonderful book signing too. Oh man, yeah, that was great. I mean, a little professor book center here. So go help my friends out. And every dime that book sales down there, it's all for him, that store. I want that store to still. So I get no cost of that. Go support them. But it was a wonderful book signing. It had 30, 40, 50 people come through there in that two-hour span. It was wonderful on October 4th, 2019. Yeah, it was just a wonderful time. I had never had one, so I didn't know what to expect. It was awesome. And this has been awesome too. I mean, good God, the time's gone and I love it. Thank you both so much for the fabulous stories, for sharing your time. It has been wonderful. And I can't believe the time is over already. Yeah, so I think Jen's gonna pop a link into the chat. That little avow form. And we would like all of you to please give us feedback about how we can continue to provide programming that you're interested in attending and as fabulous as this. And I would like to thank Jen for all of her hard work as she did all of the hard work to get these two people here with us today. It has been great. And finally, we are very happy that you might consider joining us on November 16 at 2.30 for our next event, where Dr. Jenny Klein, Ohio Professor of Art History, will be interviewing Carol Genshaft and Deidre Hamler, who are co-curating a exhibit at the Columbus Library called Ragging on Art, the Art of Amina Brenda Lynn Robertson's House and Journal. It will be very exciting. Maybe as exciting as this. Thank you both so, so much. And have a wonderful day. Thanks everyone for joining us.


Hi everyone. Today we will talk about chasing on page table in this session. I'm in Yixiang Town, a Linux daily user.  So in this session, we will first introduce what the page table is and how it works. And then talk about current chasing tools and the framework in Linux kernel like K-POP, TracePoint, F-Trace, and so on. Next, introduce our tracing implementation, the virtual memory profiling. And finally, we will look on a recent patch on page table. So each process has its virtual memory area in Linux kernel. The process control block is represented as test-starts. And its memory layout is shown as the image below. The mm-starts pointer in test-starts indicated the virtual memory area of process. And there is a vm-area-starts pointer in mm-starts. Describe the memory mapping information. Look the right match. As we can see, there are pgd and mmap in mm-starts. The pgd is the top-level page table. And the mmap pointer referred to is its virtual memory area, which can be any session like stack, heap, bsx, or data in the image as the button. First, let's look at the image and website. We can see that each process has its virtual memory area. And the memory management unit, MMU, helps to transfer the memory from virtual edges to physical edges. We can regard physical memory as a set of many pages. A single page is co-framed, and each of them has the same size. And the page table is used for managing these pages, such as pgd, the top-level page table we have mentioned in the previous page. So each page table level contains the beginning of next-level page table, just like this image. Since the fast green memory size and the emergence of 64-base CPU architecture, page table needs more level to assess more edge space. The full-level page table first appears in Linux kernel 2.6.11, and kernel version 4.11 Rc2 merge the five-level page table, and both of them are indicative of where the computer industry is going. So how the physical page is found by virtual edges in Linux kernel? First, it will call pgd offset function to gather pgd entry, and calculate pgd entry by list, pgd offset function, and so on. Finally, it arrives pt entry, and do the same thing to get a physical page. It's a structural page by taking a little offset. It is not worthy that for a page with bigger size is called huge page. It can be found in PND or PUD. When a page table entry in aspect says Linux kernel can be represented as below, even though it is often just unscientific. It defines a task for two reasons. The first is for type protection so that they will not be used inappropriately, and the second is for features like PAE on the SAT6. An additional for base is used for addressing more than 4 gigabits of memory. The base shown on the left side are SAT6 Linux kernel defined page table entry protection base, which describes the properties of current page table entry. For example, if a page table entry with page base RW, and it says on zero, but we try to write on this entry. It will cause a patch fault. When the patch fault happens, the function called trace is below. Continuously sample at the previous page. If we try to write a page which is not writable in SAT6 architecture, it first called sqlpageFault function, and so on. The findVNA function will find out the memory address where the patch fault codes, and call doWPage function to handle the patch fault error. After talking about page table concepts, it's time to talk about tracing tools. The image below shows the mainstream Linux trace tools. The most common tracing tools are k-pop and tracePoint, which is for tracing Linux kernel dynamically and statically respectively. And both have traced an ABB are based on this. In kernel, there is already, it says a dump page table file under architecture s86-mm, like a right side. And this file, if you turn on the corresponding config, you will see this file in, you will see this file in the f side, like current kernel, current user, if I in kernel under the sys kernel debug page table directory. And we can get some page table informations through this way, like cat, current, kernel. And there is, there is some page table information. This after all is, this after all is one way of doing it. The function tracer ftrace can be used to find out why it's going on inside the kernel. It can be used for debugging or analyzing latencies and performance issues that take place outside of user space. The ftrace framework read the control informations from the trace file system, and modify the kernel dynamically to enable or disable a specific trace event. All the trace information will be print, will be print in the kernel room buffer and can be read from trace file system in user space. It is easy to use because it only needs some simple command line tools like cat and echo to communicate, to communicate with debug file system. So you can use it in some everyday system, even if it only has a busy bus. And for convenience usage, it has a command line front-end tools, and trace command. Mac use, which man use ftrace easily and more user friendly. The ebpf is an internal virtual machine, which can be used for tracing kernel event pools. There are multiple different front-ends for ebpf to generate a ebpf by call, such as C and Perf, BCC, ebpf trace, or PLY. After the front-end generate a ebpf by call, the ebpf file file will check safety of the call and then pass to the ebpf virtual machine and load it into kernel. The user space can use ebpf map or Perf event to get a real-time tracing information from the ebpf. Hi, my name is Chen Lin. I'm going to talk about the trace tool that we propose, the virtual memory profiling. A difference between the previous trace tool is that the virtual memory profiling can customize the data you want to store and the prop points you want to insert. It's just like the trace point is when you are using it. And the major feature we add is that the trace can store the sequential event and immediately interact with the data we record. So we can deal with the information and make a compare to each other to decide what's next target we are interested at. The virtual memory profiling will combine the event with the process by making a pair of the test charger which is at the point of virtual memory events group to the test charger and we use the filter of the event trace to get the process that we want to test on. To add the event in our trace tool, you need to first, to add the event we need to add the event in our trace tool. We need to define our own data structure with the structure VMP event and with the VMP prefix of the illuminance. Afterward, it needs to also define our own record function and the trace points to report the information to the user space. Each sequential event will store at one of the index of the sequential event. The array of the VMP event which is the member of the VMP events group and the index specific is using the ticket which is the atomic type. So we can promise that there's no other event will store in the same index of the sequential event. And there still have the generic event we can use for store the global data and we want to save. Here is a sample. First we define our own illuminance the VMP type patch table. Then we declare the event which the name is the pg table and the sequential event size. Moreover, we define the prototype of the record function and the argument name of the record function. Then we need to define our own data structure with the VMP prefix. So we define the two data structures. The first is to store the generic data. Like we are interested in how many pte locked and the PMD and the MMP variable locked. None of this we also interested in some function like the pte gets many which is the function that we will discuss later. And the pte puts many functions or the gets unless zero functions or either the free user pte table functions. And for the sequential event we define the VMP pg table structure which will store the information for each we call the record function like the pg table bytes the paint VM or the swap or either the copyrights page. And since we can customize our record function so we can define our patch table worker to work through all the patch tables and collect all the data we need. We want to record. So here we have defined all the information that we are interested in like the PMD or PUD or P4D information. And when we are using the virtual memory profiling we need to set the inter and record and it and it exists function to the corresponds place. So here we use the debug address to control the internet and it exists to and since the record function to the function that we are interested like for example with this we mentioned earlier that here is a function that we can record the number of we call to that. So the function we defined will be like this. The inter function we will first initialize the data and the event we will store it. And as here we've just first records the information we want as the initialize. And as the exists function we will record the last event then we will report to the user space by the print information the printkid or the transport interface. And we also provide the macro for each VMP event to travel through this or the sequential events. And since the record function will be recursive report by the itself. So we use the static variable to prevent the multiple time record the recursive code so that we can just only record once at a time. And here is the information we can get it. And here is we record the normal kernel the default kernel that the page table statements will be like. As you can see as you can see we insert our trace tool successfully to the PID 777 PID. And the last task name is the test the sequential events we the sequential event size we defined is 496. So and for here we can see it's that when we do the exists we can see that the PT log called a lot and the PMD MAP and the page table log also called a lot of time. And here is the trespass here is the event trespass we can see. And here is the information that the event trespass we can see. So we just simplify here is that we just record two events in our virtual memory profile the entry and the exist. You can see that the page table bytes is smaller than the X when the test tool exists. Here is another case study that is from other developers page. This page is from they discover that the some malloc library will usually allocates them on of the virtual memory. And that does not do the MAP to loss we virtual memory. They will use the M advice to free the physical memory but that function will not free the page table memories when they use it. So in that page series they add the PT reference count to the structure of the page table to test how many user of the PT page table. So and when the reference count is equal to zero the PT table will free it will be free. And here is the information that we trespass the patch. As you can see the events the last events the patch table bytes is less than the privacy we trespass on the normal kernels the default kernels. It have the benefits that it will free the patch table bytes but as you can see the reference the attach of the reference counts of the PT tables is a lot and it will have some overhead to the auto operation which is the type of reference counts. So it have some trade-off when you are using this patch series as free the unused patch table. So it's my beam. So here is our how and here is how we use our trust tools. Thanks.


All right, cool. So we'll get started in just a sec. Glad to be here, glad to be in person, attending one of the first few conferences of the year in person.  I was here last week for the OpenJS con for the same venue. We were doing the first GraphQL conference, which is vendor neutral conference organized by the GraphQL Foundation, so I'm happy to kind of be here again. It's barely been like two weeks. Thank you so much for making it here. Hello to folks on the live stream as well. I'm going to be talking a little bit about GraphQL APIs in the context of data and over a few data mesh type architectures as well. As a quick ground of introductions, I am Tanmay, I'm the CEO co-founder at Hasura. So I'll talk a little bit about Hasura and GraphQL and then dive into the agenda of the talk. Hasura is an open source project that we created in 2018 and the idea is to provide an instant real-time GraphQL API on the data that you have in your organization, connect to various services, various data sources, get a unified GraphQL API that solves for things that you would want to solve for the API layer, which typically end up being three main problems. The first is you want a semantic JSON kind of model at the API that you want exposed to API clients. The second is a performance, speed of light, caching, caching complex queries kind of problems. And the third is security and authorization problems, which is the reason why you have an API layer in the middle in the first place and things are not accessing data systems directly. Hasura is an open source project, Apache license. Since we launched it, it's been one of the fastest growing GraphQL, open source projects in the GraphQL ecosystem. You can check it out on GitHub. GraphQL itself is a specification that came out of Facebook that was open sourced a few years ago. It was open sourced a few years ago and then donated to the GraphQL foundation that was then started a few years ago as well. So 2016 I think is when the spec was open sourced by Facebook and a few years later the GraphQL foundation was formed. So the GraphQL foundation is a vendor neutral body. It's a part of the Linux foundation, sister rock to the CNCF for example, we're one of the founding members of the GraphQL foundation as well. And that foundation body governs the GraphQL specification and I'll get into GraphQL in a bit. But the important thing to remember is that unlike say for example, Kubernetes, GraphQL, the GraphQL open source project is more of a specification and not really a runtime. So you'll have various different vendor products or open source projects or your own implementations that would implement the GraphQL spec very similar to the way you would have a REST specification. And then that's how you'd implement a GraphQL spec in a GraphQL server for example. So Hasura is a GraphQL server in that context. Cool. So before I get started, just a few quick questions for you folks. So how many of you have heard of GraphQL before this talk? Okay, cool. How many of you have used GraphQL? All right, that's awesome. And how many of you have encountered data API projects or data as a service initiatives inside your organization as well? Okay, cool. A handful. That's awesome. So the context for today's talk is I'm going to talk a little bit about the need for a data API. And then just given the audience here, depending on kind of what my polling resulted in, I would have zoomed in a little more onto the GraphQL side or a little more into GraphQL for data side. So I think given this, I'm going to zoom in a little more into the GraphQL side of things to give you folks an introduction to more of a deep dive introduction to GraphQL. So what I'd like at the end of the next kind of 25, 30 minutes is that you folks walk away with the idea of there's a seed in your mind of like, hmm, GraphQL is an interesting thing that I want to try out, especially in the context of a data API. So that's kind of my goal to kind of show you how GraphQL can be useful for especially data API kind of workloads, right? And then, of course, convince you to try GraphQL with your data and then talk about it. So just as a GraphQL evangelist. And then I'm also going to go over a few data mesh type architectures or data API type architectures that we've been seeing over the last few years with various users, various customers, both as a part of Hasura and then also broadly in the ecosystem as well. So that's kind of roughly my agenda for the next bit. Cool, so why do we need a data API? Data is everywhere. It's just exploding. It's insane, right? Like it just keeps increasing. It doesn't stop. It increases in volume. It's increasing in the types of data that we have, whether it's relational or transactional or graph or exposed by a SaaS service, search or time series. And it's also increasing in the workloads and the use cases that we have is also blowing up. So across all of these three dimensions, like volume type and use case, right? We're doing more with data as well. And as we start to do a lot more with data, it's great that we can kind of operate data, but unless somebody can use that data for doing something with it, you can take it to your users, you can give it to a different developer, you can take it, you can ship that data outside the organization to a different team, it's not useful. It's great that you've gotten the data and you've done stuff with it. But now you need to ship it somewhere, right? Or deliver it somewhere. And that's kind of where the need of an API comes in. That's going to be kind of where I'm going to be zooming in on, right? I'm not going to be zooming in on kind of these data systems that you have, the ones that you've had for the last 30 years, and the ones that you will increasingly have over the coming decade, right? It's just exploding, every month there's a new database as a service, right? Which is cool. And so I'm going to be talking a little bit about kind of that data API piece. And what we need from the data API and positioning GraphQL in the context of that data API, right? And what that really means. So, and again, the reason why a data API is useful is because it becomes, it's the kind of bottleneck or the gatekeeper to being able to use that data in contexts that are not just inside the data domain, but outside the data domain as well, right? So when we kind of think about, and I talked about kind of what we want from an API, right? When we think about an API that's specifically for data, right? A data API. Apart from kind of performance and security kind of concerns, you want to make sure that you're going to be able to continually evolve your API as well with the way your data is evolving, right? And that becomes a bottleneck, especially if you have a lot of data. Because you have hundreds of models, you have thousands of models. You're given a database or two databases or ten databases and each of them have hundreds of thousands of models. You don't feel like building APIs for each of them and for each permutation and combination of what shape people would want that data in, right? It just feels like work that we should not be doing. And that kind of is the context of introducing a data API and specifically with GraphQL. So, fairly obvious stuff when you think about what you want from an API. And one of the lenses that I'd like you to kind of keep in mind as you think about this is, just flip between two hats, right? The first hat is the hat of somebody who has to build this data API, right? You have lots of data, you're going to have to build a data API, Node.js, Spring Boot, Golang, whatever you're using. You're building an API that's connecting to these various systems and delivering that API. So you're wearing that hat of an API builder and you're thinking about your life and your day to day as you're building those many APIs. And then you're also wearing the hat of the API client when you're thinking about what is a nice experience and what is a good way to consume these data APIs and what kinds of challenges you'll run into as you think about consuming that API, right? So, flip between those two hats, that's kind of where we'll be looking at things from. So, the first, I'll dive into GraphQL. And I'm going to talk about GraphQL mostly through like a live demo so that you can see the API, that's the easiest way to understand it as opposed to going over kind of like a spec. So, we'll do that. But I wanted to highlight a few features and then we'll go into a demo and then we kind of anchor those specific features in the context of that API builder hat and the API user hat, right? So, one of the first features of GraphQL that makes it very useful for a data API, right? Is that it kind of better reflects the reality of the fact that your data and the models that you have in your data, they're kind of a semantic graph, right? That's just the reality of the way our data is. Data is related, that's why it's useful. And often when we are building these APIs, we don't very accurately capture the fact that data is related and it has in different sources, maybe even within the same source, but data is related, right? We end up building APIs that are kind of like points, right? We try to force fit the way that we think about data into specific resource endpoints that we can operate on. But the reality is that it might not, it's hard to think of things as independent resources, right? They're all kind of dependent resources. And so that results in two types of challenges, right? The first is when you think about API discovery, right? From the point of view of a user, looking at one particular resource is not interesting. I'd rather kind of look at things as they're connected to each other, right? That helps me discover what the overall API system is much. It's much easier to kind of consume that, right? But second also, practically from using that API, because everything is connected, you're often not requesting for a single resource.  The number of times you query only a user is vanishingly small, because everything is interconnected, right? And so practically what this means for an API user is that they're making multiple API calls to do anything. And that is the reality of systems much more than the reality of a single resource that you're fetching, right? So that's kind of one important capability of GraphQL that makes it useful, which it shortens that discovery loop and it condenses the multiple API calls problem into a single API call. And we'll take a look at what that is. The second thing that makes GraphQL nice is that its GraphQL specification can run on anything, but the de facto kind of standard is over HTTP. And it's very native to JSON. So it's very shamelessly JSON-first, you'll see that it's not as powerful, as say a SQL, for example, as something like Cypher, which is like a query language optimized for graph databases, right? But it's very shamelessly all about the JSON, right? And that's nice because most of the API clients want to consume stuff in JSON, right, more often than not. And of course, you end up spending a lot of time as an API builder, essentially converting things from where they are into JSON. That's a bulk of your precious life hours are wasted in doing serialization and deserialization, right? The third thing that makes GraphQL nice, which we'll also take a look at, is that it's a query language for APIs more than a set of endpoints. So it's closer to a SQL for your APIs rather than a collection of endpoints, right? And that makes it very nice because you can create your own conventions and you can create a flexible API that does things like paginations and aggregations and joins and cursor-based sorting and all kinds of interesting shenanigans that you want to do with your API and provide that capability. But in a more coherent query language type structure, rather than creating a new query param with the name that you felt like that particular morning, right? You're like, this should be called limit or this should be called first or whatever, right? So instead of kind of getting into that mess of what query parameters I should use and how I should name things, you can approach that entire problem of creating a flexible API a little more coherently, right? That's kind of what the specification allows for. The other nice thing about GraphQL is that it has modern primitives, like subscriptions which allow for consuming real-time data, consuming events and for consuming streams of data, which is also really nice because increasingly a lot of our data, well, it's not like 90% of our data is streaming data, but it used to be maybe a percent, now it's a 5%, right? These are random numbers, don't quote me on this. But the amount of data in flight and just the amount of data that we have that we want to send over an API, those volumes are going up and the data in flight, the amount of data in flight is also higher. Which now means that you'd rather have an API specification protocol that can handle those kinds of workloads as well as and when they come up, right? Cool. The last piece, which is one of the most important things that makes a lot of what I talked about possible is that the specification of a GraphQL API, the GraphQL schema, is a built-in artifact. For those of you familiar from the database world, when you think about creating a table inside a relational database, right? The database is introspectable and there's a catalog as an act of using the database. So in a way, your data models and the description of what your data is, is built into the process of using that database and creating models in the database. GraphQL is very similar in that when you create the GraphQL API, when you create a GraphQL server as a byproduct of that creation, you are fundamentally creating and putting out a GraphQL schema. The GraphQL schema describes the graph of all of your models, what operations are possible, how things are related to each other, what the types are. This has a massive impact on API documentation and on onboarding tooling, right? Just to go over all of this with examples where we can see this slide. Wearing the hat of both the API builder and the API consumer, think about API documentation or the lack of API documentation, right? The only thing more painful than building 100 APIs is documenting those 100 APIs and then continuously keeping up with that documentation. Somebody expected JSON true, but they got a capital TRUE because you were using a weird Python serialization library that just output a string instead of JSON because somebody screwed up, right? And maybe this change happened and then broke a bunch of applications and now you're sharing Excel sheets that have documentation in it because who wants to set up an open API spec, right? So it's not fun. This is not useful work when it comes to that API documentation. But when you think about API onboarding as well, when I'm using the API, the fact that when I'm using a GraphQL API, there is a schema there makes it very easy for people, for example, when they're building mobile applications, to have a typed SDK, right? So any GraphQL service, you can generate an SDK. You can get autocomplete on your APIs because the entire API schema is documented automatically. So it just opens up and the community goes crazy in building all kinds of tools that makes it easier for API clients, which is why when you hear about GraphQL, you'll often hear of it from the API consumers point of view because API clients really like the experience of consuming GraphQL. We'll take a look at that and it makes it really easy. The people who are building APIs, they don't like GraphQL as much because it's a fair amount of effort to build a GraphQL server, just like it is to build any other server that has a new protocol, right? So most of the love that you see for GraphQL comes from the API consumers because their experience is just absolutely amazing. All right, so with that, let's take a look at what a GraphQL API looks like over the next, say, five to 10 minutes. I'll take you over just a little bit of comparison of versus a rest-age API, like just putting them side by side and seeing what that looks like. Take a look at models and relationships. We'll take a look at querying. We'll take a look at a particular way to approach authorization, which is unique to Hasura, but it applies no matter what you do. We'll take a look at aggregations and how you can bake in more composition and how you can approach creating your own kind of composition semantics when you're building with a GraphQL API. We'll take a look at a few real-time examples and we'll see the benefits of schemas and types throughout these various examples. So with that, let me dive in straight into a demo set up that I have here. All right, so, cool. All right, so I have a GraphQL server that's running here.  At the end of it, what you'll have is a GraphQL endpoint. So what you see here is a GraphQL endpoint. Oh, sorry, do you want me to zoom that up? One more, okay, cool. All right, hopefully the UI won't break terribly. All right, so that is the GraphQL endpoint, right? That is similar to a REST endpoint that you would have had. It's just HTTP. When we send API calls to this endpoint, we'll be sending API calls over post, only post. And that's the nature of GraphQL. And you'll see that there's only one endpoint which is slash GraphQL. So there's only the slash GraphQL endpoint. Let's take a quick look at what the API experience looks like. So I'm gonna type in query. I have a model called artist. You'll notice this autocomplete kind of situation happening here. And then I want to see what attributes an artist has. So I'm just gonna control space and see what fields I have available here. So I have ID and name, and then let's run this. All right, so what you're seeing here is this is the API call that I made. And that is the response that I'm getting here, right? Let me scroll down a bit, all right. So that's the ID and name that I'm getting here, right? This is equivalent to something like REST API endpoint that would have done a get of slash artists. Right, that's what it's equivalent to. Instead of making a get request to a slash artist endpoint and getting a bunch of artists, I have a music artist API. Instead of doing that, what I'm doing is I am sending this query that text here to that post endpoint. And that's giving me the result which is in JSON, right? So the output is exactly what you would expect from a REST API as well. The, this language that you see here, the syntax that you see here, this is GraphQL, right? And if you look at it, it's pretty straightforward, which is why people like it, right?  That's why people like GraphQL, because it's like, ah, that's what I want.  And just get the data that I want. So that's what a GraphQL query looks like. That syntax is GraphQL. Let's take a quick look at what this API looks like. So if I want just ID and I run this query, I get just ID, right? If I add in the field name, I get it with ID and name, right? If depending on other fields that I have, so for example, I have albums and then I can traverse albums inside that and we'll take a look at album has title and the album has music tracks and stuff like that. We'll take a look at that in a second. But I can choose what fields I want, right? Now this is very useful from an API customers, from an API client's point of view and from the API builder's point of view, because if you have a model that has 100 attributes, you don't want to create unique endpoints for each particular shape of data. That is not useful work, right? Like just because the mobile client wants 10 attributes and the desktop clients wants 100 attributes, but there's a microservice client that wants like the 100 attributes and related data, you don't want to create unique API endpoints to service each kind of workload, right? This is now a built-in property of a GraphQL API that I can choose what attributes I want to get in the data that I'm in the response that I'm receiving. Let's take another look at kind of how parameters work. So I can now say limit that to just 10. So now instead of getting 300 or so, I'm getting just the 10, let's limit that to five and I'm getting just five here. This is kind of equivalent to a get endpoint that had something like a limit, right? Like a query parameter. That's, you're seeing that the parameterization kind of stuff is coming in here. That's where this goes in, right? And again, just to get a sense for what's happening underneath it, it's really straightforward. This is being sent as a post payload to this post endpoint. So it's literally a JSON object that is being sent that contains this query, the GraphQL server processes this query and then returns the right response. The GraphQL server figures out how to extract, there's a limit thing here, five, return only five responses. Exactly what a server would have done when it would have parsed an HTTP URL with query parameters. Same kind of parsing logic, but it's parsing on GraphQL instead of parsing a URL string with query patterns, et cetera, right? So just a different kind of specification there. Let's take a look at kind of what other operations we can do here and what this looks like. So there's this tool that I'm using, by the way, this tool called Graphical. This was also a tool that was open sourced by Facebook at the same time that the GraphQL specification was open sourced. This, the graphical tool, the reason why this autocomplete works, let's say for example I do NMAE and I try to run this API call, I get a error saying that the field NMA is not found in this type, right? So there's kind of this validation happening of what attributes I have available. I in fact see this nice little red underline that tells me you don't have NMAE, do you mean NAME? Is it like the AI in your API essentially?  And this is IDNName, this is pretty straightforward. I'm sure all of you have seen various combinations of names that look very similar, that have a double T or a double L or a single L or all of those attributes that are Java like names, right, where you can have a lot of errors, right? So that experience is easy. Now the reason why this works is because what is actually happening underneath it is graphical, this UI tool, right? And you'll see this in Postman, you'll see this in any kind of API client that you're using that supports GraphQL. What these tools are doing is they're hitting this GraphQL endpoint and saying, tell me the schema that you have, like show us the GraphQL schema that you have. Just go opening up a visualization of this GraphQL schema, right? This is the entire API, right? And you can kind of visualize it. You would probably not end up doing this in practice too much, right? And this is like for like 10 models, right? For all of the permutations and combinations that you can have there, imagine if you had thousands, right? But here you can kind of see what your different fields are, what you can query for, what is related to what, right? But this experience is kind of automated when it comes to this graphical portion, right? So for example, when I look at my API, I'm like, hmm, what fields do I have? Oh, I have artists, that's cool. What can I parametrize on? There's a limit thing that I can parametrize on, that's nice. And let's see what I want to fetch, ID and name, that's cool, let's fetch ID and name. And then I want to filter. So let's say where name starts with A, right? And so now I'm only going to get the is, let's make it a little more interesting and get the j's. And so you see name starting with j, right? So you're kind of browsing this API and getting a feel for what the API is as through this kind of explorer experience, because it's zoomed in, it's cutting out and stuff like that, but once it's not, it'll be a slightly better experience as well. So you can see the different operators that you have, right? So because you see also, notice that everything is typed, right? So because it's a name, I get to do these kind of like regex type operations, right? But if it was an ID, because it's a numeric type, I'm only going to see operators that help me filter based on number kind of operations, right? Now, so for example, I can say where ID is greater than 67, right? And so I'm kind of browsing this API and learning about the API as a part of like using this API itself, which is a fairly convenient experience, right? All right, now just one important thing to point out here is the syntax that you see there of limiting and where and offset and whatnot, that is entirely in the control of whatever GraphQL service you're building. So if you're building a GraphQL service where you want to provide advanced filtering, go for it. If you don't, don't. In Hasura's case, our aim is to provide that kind of flexible filtering thing so you see lots of filtering options. All right, cool. Let's take a look at the graph in GraphQL. So this setup that I have here is an interesting setup where I've taken three different data sources. I have a BigQuery data source, a Postgres data source, and a SQL server data source. And what I've done is that in my Postgres data source, I have artists and these are the artists that we've been looking at. And what I've done is I've taken the albums, like each artist has a bunch of albums and I've put that in SQL server, right? Just because. And so the albums are kind of here, right? What I've done is I've created a relationship between these two models. The artist model has a relationship to the album model through an artist ID, right? And because I've created that relationship, we can kind of see that in the GraphQL API, right? So let's see, let's limit that. Let's remove the where clause and let's fetch albums that have a title, right? So now what you're seeing here is the artist, right? And their albums, right? And you're seeing that in kind of the, again, you're seeing that in the format that you'd expect to see it in, in the shape of the JSON that you want to see it in, right? So as you kind of start connecting this kind of semantic graph of the various models that you have, your API customers can start querying that for the right shape that they want, right? For all of the attributes for join things and whatnot. And then again, just to make this interesting, I put all of the music tracks in a different system. So the music track has name and maybe like the amount of time it takes the tracks to run. So each album now is fetching multiple tracks and you're getting multiple tracks from wherever it is, right? So this kind of makes that experience of consuming the data API, of discovering what I have in the API fairly easy. At any point of time, I can go in and kind of look at the documentation for what the pipes are. So for example, and I'm gonna zoom this up again in a second. If I look at album, and I just zoom this up here, you'll see that the album has a title, which is a string. It has an array of track objects, right? And the track has bytes and milliseconds and media type and whatnot, right? So this property of the documentation, this property of what is browsable is all kind of available inside the, as a part as a free artifact of using GraphQL itself. So that's a quick look at what the GraphQL API looks like and kind of why the experience of consuming GraphQL, especially for a data API, is far richer and far more convenient, both for the builder and both for the user. Well, when I say builder, be careful because somebody has to build the GraphQL server.  So that's a quick look at GraphQL before I kind of zoom into some ways of composing permissions and aggregations, which are interesting, which is just to show an example of how you can compose stuff together. I was going to say before I move on to that, if folks had any quick questions on the kind of GraphQL things that they wanna see, but we're running a little bit out of time, so we'll save that for the end. All right, let's take a quick look at what aggregations could look like, right? So aggregations are cumbersome to put into a data API. It's not very natural, especially in a JSON style API, right? And so I'm gonna describe one approach to thinking about aggregations when it comes to from a GraphQL API point of view, right? So if the kind of convention that we've started following, right, is that every time there is a list of resources that we're returning, we'll also provide an aggregate for a list. So any list gets an aggregate. So like for example, we had artists, right? And you look at these artists and I have like whatever a few hundred of them. This is a list. So any list gets an aggregate. So if you think about that, what you'll also notice in your API is the ability to run, is to convert that into an aggregate and then you can do a thing like count for example, right, and then you'll get a count. But the nice thing is that these can compose across relationships in your graph, right? In your API. So for example, you can do query artists. Just to make this a little more sane, let's limit that to 10. And if you look at artists having albums, right? Each artist has a list of albums, right? So for example, ACDC has like two, except has two and Aerosmith has one or whatever, right? Because there's a list that's a nested object, I can also convert this to an aggregate, right? Now this is a particular convention that we follow as when we generate a GraphQL API. But the idea here is that you can create kind of a convention or semantics for your data API that compose well together, right? And so here for example, I can now say artists with an album's aggregate and that aggregate is a count of two. So this kind of fits in a little bit naturally into a JSON API graph kind of structure. And at the same time allows you to think about how you wanna introduce aggregations in your API. If I were to kind of abstract this up one level and think about what the overall concept is, the concept is that a group by, right, is the top of the graph. So the group by key comes on the top. So the group by key here is an artist. So group by key comes on the top and then the aggregation operations for the list is nested inside that GraphQL structure. So this is one way that you can start composing aggregations into your GraphQL API as well and offer a fair amount of flexibility to the API customer as well to say, oh, cool, I wanna do aggregations on a list, a sensible thing to attempt to do. And now I can run those aggregations and they'll compose across relationships as well, right? And this is interesting. And there's an interesting amount of work that we've done here at Hasura to make sure that this is actually composing across two data sources. So you're seeing that this aggregation is running across Postgres, data source and one and SQL Server on two, right? And you can imagine the kind of database in Anagans this takes to get it to work, but that aside, what is interesting here is that you can kind of get this composition and a neat API that makes sense and that is extensible kind of working for you. We'll take a quick look at what real-time APIs look like before we switch into what different data API architectures look like. So, all right, let's take a look at subscriptions which is always a fun thing to look at. So I've set up another toy kind of application here where I'm gonna sub query color info, right? So I'm running this query and I get a description saying green, plants reflect only green light, red has the longest wavelength, plants reflecting only green light was a bit of a mind-blowing thing as a child to learn. But, right, that's why they're green. So anyway, that's, so I'm just running a simple straightforward query, right? What I can do is I can convert this to a subscription and now I'm getting this data but now this is real-time. So if I go and imagine that the underlying data source, let me just split these into two tabs here, right? Okay, so you're seeing that this is a response here, right? If something now happens to the underlying data source and says plants reflect only green light and occasionally purple, right? As soon as I make that shift here, you'll see that this kind of gets updated as well, right? And this is just a very neat and obvious abstraction for an API customer because they're like, yeah, this is the model that I'm interested in and now just subscribe to it. So whenever it changes, you get changes, right? So from an experience point of view and from an API point of view, as you start kind of subscribing to entities in your upstream data sources that are changing, you now have a way to think about how you want to expose that to your customers and again with the same benefits of GraphQL, right? You're getting to parametrize, you're getting to authorize, you're getting to choose what attributes you want to send over but it's quote-unquote real-time. You can extend this idea to streams as well. So let's take a look at, I have a stream of colors and let's see how many fields I actually have. Let's look at subscription, color stream. Let's stream in batches of 10. What is our initial value here? Okay, let's start off with an initial value of 5,000. And so I have like a, I think 100 million elements or records in this color's model, right? And let's fetch ID and color, right? All right, so what you're seeing here is that this has now become a stream where I'm kind of doing almost like a bulk data extract operation over as many records as this is with this idea of an offset or a cursor, right? The client in this case now says that I'm not interested in a value of a single element that's changing but because you have this massive list of elements help me stream through that list, right? And give me access to what you want. And so this is another kind of convention that you can add on to a graphical subscription to expose kind of the semantics that you want for your API, right? And this again is nice because increasingly you're gonna have data workloads where people want to ship like massive chunks of data.  I wanna stream not the 100 attributes but just five. All of those things and you want to send that across to people without like emailing them or FTPing them like a file or whatever it is, right? That I've never done thankfully. But that some people have done. So that's kind of what a subscription, a stream might look like when you think about a streaming API. So, okay, that's a quick look at what the GraphQL API looks like.  I'm gonna quickly zoom into a few different data API architectures before we pause for questions. So I think examples of three types of architectures that we've seen with users in the way people think about a data API, right? So the first is kind of like a operational data layer or hot data layer kind of system where what folks do is they think of, they have data in various sources. They EPL that to a central store, kind of like a data warehouse. Depending on the nature of your data, it might be a data warehouse or it's more operational.  For example, you build your own data API and then that becomes the API that you're giving off to your clients. Here, when I think about these architectures, for me, it's always interesting to think about like ownership and agency, right? So here, the persistence layer is owned by the team that also owns this data API. This is interesting because you get more control of things like performance. It sucks because somebody has to build all of the ETL stuff to come into this ODL layer, which is depending on how much of a budget you have and who's keen on doing what, that may or may not be an excessive one undertake. But that API team still controls the API experience, right? So that's kind of what this looks like. The dotted box that you see here is the ownership box. Another example that we've seen is where you just have the centralized data API layer, but you have various different data sources. I've called them databases, but those could be databases, those could be REST APIs, those could be GraphQL APIs, could be GRPC, could be whatever. But you're creating the same semantic model across these data sources. And the team that owns the data API only owns the data API layer, which is stateless, has maybe a caching layer with it.  Right. The third, which is kind of a variation, is the more federated setup. And this kind of starts resembling more of the data mesh type things that people are gradually moving towards. The idea here is that you have various data products. So DB1, for example, is owned by a different team, DB2 is owned by a different team, DB3 is owned by a different team, and DB again is a data source here. And the consumer owns the data API experience that is then connected to these sources. So it's kind of the authorization is split, that the authorization governance is split or federated or split and federated across these two, right? So the data product owners control kind of slightly less granular governance for their data product. But the specific API consumers, they own the API experience and the finer grained kind of authorization entitlements that decide who gets to extract what data or use what data in the data API. The compute infrastructure is also split because you're running some queries against the data products itself, but you're also running some of that compute as a consumer, you're owning that kind of yourself, right? So this is also kind of a more federated architecture that we're starting to see, especially in conjunction with things like a data lake kind of idea, right? Where you chop things into object storage, you have like an Athena-like layer on top of that, and then you start building your data APIs in front of it, right? So that different consumers own. So those are kind of three variations that we've seen that have different kind of pros and cons. Bram, wanna call it time. We'll share the link to the slides as well, so all of these are links, but there's a few interesting things here to look at. One of them is kind of the underlying architecture or approaching building a GraphQL server as a compiler or a transpiler, as opposed to building it as a traditional API server. The second is an architectural deep dive and discussions on various approaches to build real-time subscriptions and to build streaming, what the different pros and cons are and how you think about building and scaling out such systems. What I would love to hear from you is, try GraphQL, try it out with your data. There's a link here that in this particular case for the demo that I use, that uses Hasura needs a doc container as well, but if you get to try it out yourself, would love to hear what your experiences are like. Feel free to reach out to me at Tanagon Twitter or on LinkedIn for any questions or discussions about GraphQL or data and stuff like that. Also as a plug, would love to announce our annual user conference, a free and open user conference with contributors and people collaborating on the Hasura GraphQL engine, different announcements and things that we're doing, that that's happening next week, where we'll be talking about this is live stream, right? Okay, I can't let the cat out of the bag. But interesting things for people to build support for as many data sources as they have, everything from DB2 to Airtable, and then kind of get that same GraphQL experience. So we'll be talking about a whole bunch of things next week as well, so do join us for that, again, free and open conference. But that is my time, and if you folks have any questions, I can take questions. So I think we have a little bit of time if you want any live demo type questions as well. Yes, go ahead. Yep. No, you have to, no, it isn't. The kind of streaming that I demoed, nobody's, like, that's not an out-of-the-box thing anywhere else, I think we're the first people of kind of approach to this way. The reason why it's hard slash interesting is because it needs a fair amount of integration with the type of data source that you have, right? Because you wanna, when you're doing us, when you're providing streaming on top of Postgres or on top of Kafka, on top of Cassandra, on top of different types of data sources, the ways that you'd want to optimize that is a little bit different. So we do that through a deeper integration. That's what it takes. Which we did, can you do right? Yes, they're called mutations. So the GraphQL keyword for that is mutation. And just to show you what that looks like. Just like we have a keyword called query and subscriptions, we have a keyword called mutation. And for example, with Hasura, we generate a bunch of mutations for correct actions like insert, update, delete. So you'll see a whole bunch of different mutations that you can run. You can also map, like another way to do it is to think of, from a CQRS point of view, you'd think of a mutation as executing a command, right? So the mutation essentially fires a command. The command goes and does a bunch of stuff and updates the read models. And then the response of the mutation returns the read model. So just to show you what that looks like, if I do create artist, I pass in the payload. And then when I return that response, right? I can traverse the entire ID, like the artist model. So this is the read model that you're seeing here, right? This is like the GraphQL system is hitting, like assume there's a read after write kind of situation that happens, right? So the create artist that sends in like, I think it'll take an email and a name or whatever, right? So this is like a custom command. There's a piece of business logic that'll go and run, that'll take name and email and do something. And once it does a thing, it returns an ID. The GraphQL system enriches it and returns and understands this ID is actually a reference to the artist model and then provides this ability to traverse the entire artist model. So that becomes another way of approaching mutations. So, but at a GraphQL specification level, it's called a mutation. The GraphQL spec wisely does not bother too much with verbs like post, put, patch, delete because they're like, man, it's so weird. You'll do whatever you do with the right operation anyway. Just call it a mutation and go. That's the idea. And then what, it's your convention on how you wanna create mutations, right? You had a question? Yes. Yeah, yeah, yeah. It's not a part of the GraphQL specification by default, but you can layer that in as kind of a convention when if you're building out a GraphQL service. What we do, for example, is we associate a execution cost with every GraphQL query. And that execution cost maps to essentially the time that it takes to execute a query. And then different API clients can get like a cost quota. So you can create roles or sessions and say that this person has a cost quota of like 500 milliseconds to the minute, right? So you get to execute your API calls for a 500 millisecond window net in the span of a minute. So you can run one API call that's 500 milliseconds long. You can run 10 or 50 milliseconds long within the span of a minute and then you get rate limited. So that ends up being a nice data API experience. There are lots of other kind of ways that you can denote cost, but I think from our experience it's not as practical. Like you can have cost based on like how many joins are you doing, right? Like how many attributes are you fetching? Or what is the query complexity? But those are so vague because sometimes you might have a really simple query, but the data volume is so large that analysis of the query complexity doesn't help because when you juxtapose it with a real world like amount of data you have, the cost is out of the window, right? So it becomes more sensible to just think of it as a quota. That's one way of doing it. So everything I talked about is open source here both in the project that we've made plus the GraphQL specification itself. The GraphQL specification is pretty light. It has queries, mutations, and subscriptions, right? And then it says that inside the query, inside the mutation and inside the subscription, what you want to do is up to you, right? So for example, the conventions that I showed around limit offset where, right? That's a convention that is unique to Hasura, right? If you were building your own GraphQL service, you would have had a very similar looking GraphQL query that queries users, but maybe you don't like using the word limit offset. Maybe you would have used the word first last. You would have used the word page instead of offset. So that convention of the particular words that you use, the nouns and the verbs that you're using to describe operations on your API, that's unique to you. The overall structure of having queries and mutations and subscriptions and that format that you saw of like the JSON style format and the parenthesis, that is a part of the GraphQL specification, right? And then there's a bunch of other stuff also around fragments and whatnot, you don't have to get into that, but that's the GraphQL spec and then whoever is implementing the GraphQL spec might have their own conventions in how they think about the GraphQL API. But everything I talked about is open source, by the way. Proprietary in the sense that it's unique to this product, but yeah, yeah, yeah, yeah. So as from a Hasura point of view, the way that we approach it is, so we have a UI like a, that helps you kind of create models, set up relationships across models and stuff like that. So you're kind of creating these relationships and you're creating authorization rules and whatnot. The way Hasura works is, it's not GraphQL schema first, it's metadata first.  So you say that I have an album model, an artist model and they're related, right? And then Hasura uses that metadata to create the GraphQL schema. So you don't create the GraphQL schema, you describe the metadata, Hasura creates the GraphQL schema. But there are many different approaches in the way that you could create a GraphQL API. You could go schema first, where you first describe the entire GraphQL schema and then you start backing that up with specific operations, right? That's schema first. You could go, what we're doing is like metadata first or model first. You could even go code first, which is kind of this, you imagine that you're writing these Java controllers and as you write these Java controllers, the schema is spit out automatically, right? So there's many different approaches that you can take. The approach that we take is metadata first. All right folks. Oh, sorry, any questions from the stream? That's a good question. Can this be used in embedded environments for distributed databases? I'm not sure what the question means. I'm gonna unpack that in two levels. Can you use this in embedded environments, like an IoT environment? Yes, you can. It's as long as you can run a Docker container. So you can run a Docker container there. That becomes your GraphQL server. You can run that there. You can run Hasura next to a distributed database as well. And as a part of the Hasura metadata, you'll add annotations to describe what your chart, like what your topologies, and then Hasura will do the query routing appropriately, for example. So we support distributed databases as well. We do Yugabyte, Citus, Cockroaches in like early preview.  So yes, I guess is the answer to that. All right, thank you so much folks for the questions and for spending time here. And I'll be around.