 Hi guys, how are you doing? Can you hear me in the back? Good to see some familiar faces here. And also good to be back in a Citrix office. I'm actually back in a Citrix office after a really long time. So the last time I was in a Citrix office was spring 1999. So I just finished grad school and I was looking at different start-ups. Interested in working for a start-up at that point, like still early boom days back the whole dot-com era, right? And so I interviewed companies in Boston and in Florida. And at this point, there was this tiny little start-up in Fort Lauderdale, famous for its beaches back then in Florida, Citrix, right? And so they flew me down during spring break to come interview with them. And they let me actually stay over the weekend during spring break and make a trip to Orlando and visit Daytona Beach and have a lot of fun. And they were being threatened. It looked like at that point, they were just going to get crushed by Microsoft. Now, in hindsight, it's amazing to see how far this company has grown that this office is bigger than the company that I visited back then in Fort Lauderdale, which is in a tiny little office about one-fifth of the size of this office space. So amazing how much can happen in a sort of a 10-year period. It reminds me of a court with someone once said where we often overestimate how much can happen in the next two years, but we underestimate how much can happen in the next 10 years. And with that context, I'll sort of jump in quickly into the discussion today about readers. As I understand it, many of you have some acquaintance, some level of exposure to readers so far. I've been working with readers for the last couple of years, building backends for a couple of very large-scale mobile apps that my company builds. And it's been a fantastic journey. I love readers. Some of you who might have attended my talk at PyCon last year might have heard me harp a little bit about how much I love it. Today's session is fairly basic. It's part of the progression that you guys will go through today where you already went through an initial beginner-level workshop. And what I'm going to do is I'm going to take a very simple use case and just show you in about an hour's time how a little side project fun little thing. I built a little API, you know, use Node.js to build a simple RESTful API that returns a quiz question and possible answers and what the correct answer is, sort of what you can see here. Actually, I think I've ended up cropping out column A. Column A was a question. A, B, C, D are the different possible options. And then this is the answer. And the API that is put together is just this. What happened here? Let's see. So it's almost slightly contrived, right? But it's a simple example of how readers can be used in conjunction with other technologies. Now, as you know, I think if you ask people around 50 to 60% of the people today still use readers mostly as a memcache replacement, which isn't really using a lot of the power that readers brings. So I'll introduce you to maybe just something a little beyond that, which is using it as a simple key value pair. But avoiding hitting the database, right? So let's talk a couple of use cases where something like this might be useful to you. Let's say you're building a game, right? You're Zynga. You're trying to build Farmville. Now, one of the important things for you is to not to have to hit your database all the time, right? Now, so when you have a game, a typical flow here will be someone signs in, you load up all his creds, you load up all the game scores, you load up all the details. You stuff them into readers. And then during the course of gameplay, everything is done in memory. And then at a later point in time, things get written over the disk, right? So this is a fairly common use case. You could apply it to a lot of situations where you could run portions of what you're trying to do real-time off of readers and then later write things to another separate store if that makes sense, right? So to sort of just dive into my slightly contrived case here, let's say you're sort of chartered a cradle of API that is going to be consumed by some other app. And maybe it's a little quiz app, and maybe some of you here are big fans of quiz app and some of the other addictive quiz apps that are popular today where you can challenge your friends and, you know, it poses a set of questions with different options. You need to answer, right? And one of the important things with some of these things is your API needs to be super snappy, right? So the performance is like super important. So this is running on Heroku servers in the U.S. It's a really lightweight node. It's just on a free dyno, but it's like super quick. And I'm going to dig into it and just show you where the data comes from. So the data for this comes from this Google spreadsheet. So I just quickly whipped it up and just asked one of the QA guys, a couple of guys in the team, and I just found this populated with like 20 different questions which they did. So it's got about 20, 30 different questions and answers. There's not a lot of data in there, but it's just a simple example. But what I'll walk you through quickly here, it's part rate is a little bit of node and how to extract some of the data, but it's a simple example of how with node you can just stuff a bunch of data on a Google spreadsheet and how you can retrieve it. This is the key that you need to use for extracting data from one of the Google spreadsheets using their API. And then once you have extracted the data, how you can dump it into Redis and then how your REST API can hit Redis to pull the latest item that you want and then to send it back. So for that let me this is readable. You guys can see it in the back? Let me know if you guys can see this. So okay, the back. So this is just a very simple contrived express app, right? It doesn't do a lot. It grabs the Heroku. Heroku works with Redis to go. They provide a free instance of Redis to go which works pretty great for a little side project, little things that you want to play around with. And I think the plan is great. We've used Redis to go for a while on some of the other instances that we have and I think overall they offer a great plan and great support. So in case you're considering them, I would highly recommend Redis to go. No JS app, it just comes in here. In case there is Redis to go configured in the process environment variables, it grabs it, splits it out to grab the URL, the host name and the port. If not, it just goes with the local host client that's running. Yeah, thanks. Next from there, other funny thing is this morning when I tried to run this from a demo, my code was about a year old and it was completely broken. It wasn't working. It turned out that Express has updated a bunch of things. I had Jason this morning to a fixed version so that it would work. So this code works only with Express Read Auto. A bunch of these have been changed in 4.0 onwards. But the bulk of the code in here which I think is sort of relevant is one, the code here where I'm fetching data from the Google spreadsheet and I'm pushing it into Redis. So like I mentioned here, this is the URL. For any Google spreadsheet that you're out there and some of you might be familiar with this. Some of you may not be. So for this Google spreadsheet, this is URL which gives me a Jason feed. So you can do this with any publicly available Google spreadsheet. Just take this URL and change this key up here to be the key that you see up here in the sheet. So you can do this with any spreadsheet. Just open up any Google spreadsheet that you have as long as it's publicly available. Exactly. So as long as it's publicly available. Yeah. Anyone who has URL also is okay. I think that's fine too. Yeah. Anyone with the link I think is okay too. So just grab this key. Stuff it in here and it gives you a complete Jason feed. Right? So now all I'm doing here is I'm grabbing the Jason feed passing through it. Again this simple coffee script. You can ignore most of the syntax. And then what I'm doing is this is the part where I get the response back. Once I get the response back I'm essentially passing through it creating a hash and then dumping this entire thing into readers in this sort of question and answer form. Right? So you can see from the feed I'm essentially taking out the question and the set of responses and I'm stuffing those into readers so that these can be looked up. Now the next piece of this is the lucky API. Right? So I'm doing this sort of split into two parts. Okay? So the first part is where I'm essentially hearing readers to fetch a random a random key from readers and the second part is where I'm actually returning what the current random value is. So initially let me just rephrase that to make it clearer. So whenever the lucky API is called I'm not actually trying to generate a random item each time. I'm actually pre-populating it on the previous call that has been made. So the first call actually won't return anything. First call will fail because there's nothing that's being stored under lucky. Right? So there's a lucky key which gets set. And this is set from a random pick from all the different questions that are in the database. Right? So again, how many of you here are familiar with Node? Okay, a few has. So part of this, not to make this too confusing, is there's a bit of async action happening here where this is happening asynchronously but this is what's actually returning data. So when this slash lucky URL gets hit the response actually comes only from these two lines of code. So this code executes immediately and returns the response from a lucky field which has been populated earlier. But while this is completed this code will continue to execute asynchronously in the background to fetch the next random value and to populate that. So that the next end is a lucky call that fetch happens asynchronously. Is that clear? No. Not necessarily. But for this use case it wasn't to the consistency of the result wasn't a factor as much here. There's more about getting a random question. It doesn't matter who gets what. So let's dive into it a little bit. So it is a little side project also play around with Node but I'm a lot more comfortable with Python. So you'll just see me dive into Python a little bit here. I'm just going to go in and clear my readers database just to show you from scratch on the shared lucky wallet. You'll notice. I think still I'm just going to connect to my local instance and you can see I've got all these keys in here. Cool. So I've cleared readers locally. And come in here and here's a quizlet folder. So to run this code I mean there's a proc file so when you push this up if you're using Heroku you just need to set the Heroku environment variable with the path which essentially sets a param. So in case you're setting this up on Heroku you need to set up this config value Google spreadsheet key and assign that to whatever your spreadsheet that you're trying to pull data from. If you're running from the command it's as simple as just So once this is running now as I just showed you guys we don't currently have anything in readers I'm just going to go ahead now and I forget about the default port so it's initiated the database updates from Google spreadsheet as you can see here as well there's a little bit of async action happening because this responds immediately saying that it's been initiated and then this processing happens meanwhile in the background and you can see it's finished updating so just come in here and got a bunch of keys in here now come back lucky so the first time like I mentioned earlier the first time it hits it's not found because there's nothing in there right but what's also happened is now the other async code is executed it's pulled a random thing and it's stuffed into the lucky key so is it clear why this is not found so next time I hit it so it's all just a local in-memory hit so the concept is fairly simple right if you've got a use case like this where maybe the app that you're building what are we building has a ton of data but there's a subset of data where it's useful to keep it in readers in memory and you'd have something very high performance with respect to the reads that you're getting out of a read and write obviously but I think it's a great simple way to apply or maybe you know you've got a little pet project like this and you know you're working with someone with easy enough to get them to use a Google spreadsheet instead of using a database easy enough for them to populate it in there and then you know work with it Google spreadsheet is a great simple API and the code to do all of this right is so simple right it's fairly straightforward to work with readers even without touching a lot of the other very powerful features so one of the things I like about it is you get started to get a lot of value out of it is so easy so we use readers internally for a number of things a lot of our queuing and delayed jobs run on readers a lot of our pub sub notification patterns run on readers are sort of instant search runs on readers because a lot of things where you can apply the data structures and problems to and some of it is just up to your creativity and imagination with respect to what you'd like to do so yeah not reliable is it I see how many yeah yeah yeah yeah no postgres plus readers so just to make sure nothing gets lost we definitely use postgres and then you know there's a job that hits postgres pull data for which jobs need to be run so it's not done independently for cases where we can't afford to lose data so one of the things that we're actually building out right now is it's a social media management platform and that actually helps people so if people who go out and schedule a bunch of posts which need to go out at various points in time and all the posts go into postgres but then we sort of have the crown job which goes and looks at all the posts that are scheduled for a certain time and then those get managed you know with readers plus RQ so but I agree it I mean you know there's see I mean readers can't persist data some people tell me that readers can't persist but that's not true obviously it has params through which you can persist information but it's likely not the option if you're looking at something that's mission critical I would still go with the traditional database coupled with it that's at least my take on it I don't know anyone else here who wants to chime in hmm yeah yeah I haven't taken a chance and anyone else here with experience around this any failures with readers that you want to talk about I'm sure there will be more through the days so how much was covered in the workshop so far okay so maybe I'll give you guys a little just a little how much more time do I have can 10 minutes cool so if it's fine I'd like you guys to just break out into small groups and just maybe you know it's also a nice way to get to know the people around here so just say hello to some of the people around you and just form small groups of four five and I'll come up with a few sort of again contrived but hypothetical problems extending this problem a little more okay so first just say hello and just get to know a couple of people around you who we don't know already this around you come on ha ha ha people you don't know okay ha ha ha ha okay now now's the time for a little confession how many of you are addicted to quiz up good I see some hands those guys are being honest so this is a pretty addictive trivia game that's there online and do you want to just tell people how quiz up works very addicted right yeah so let's sort of break that down on a couple of different pieces and maybe just guys around here can sort of talk about how you could apply readers just it's up with groups talk about how you would apply readers to some of these problems so one part of what he mentioned was a matchmaking part right so when I come in a quiz up I can choose any category and let's just say I pick Bollywood for example and it'll find other people around who are also interested in playing Bollywood at the same time and match make them together randomly so the first problem is this matchmaking problem okay matchmaking people so people pick the categories that are interested in and you match make them together that's problem one second once two people have been paired up right there's two ways the games happen one I'll take the first case first the games happen live right so both people have presented to the same question at the same time and as they respond you see the other guys getting scores or not so my actions are being seen with other person as well live okay so I am answering it Kiran is answering it right and if I choose the wrong answer Kiran immediately you know they already chosen the wrong answer and his timer is running it does it does after you have also answered it does so this is the second piece which is sort of two people concurrently playing and keeping both their actions visible to each other and in sync with each other same time the third part of what they do is at the end of end of the game you know let's just take these two alone for now these two problems the first one is matchmaking the second one is sort of the live game part and the interaction between the two players as a going question to question if you guys would like to I think is an interesting problem set to apply and how to look at using readers just in your little groups there take either the first one matchmaking or the live game part one of the two and just talk about how you would try to apply readers to solving some of these problems so guys just go ahead we've just got a few minutes left so I'll let you just spend some time talking about it and maybe later in the day we can regroup to discuss it if you'd like to check out the game check it out towards school the next speaker here Kiran Kiran speaker here you all set I'll just wrap up quickly hey guys we'll I think we're out of time so we'll sort of talk about this again a little more maybe later in the day to sort of talk about what your different solutions are I'll just wrap up the code for this in case you'd like to check it out it's up on github it's on argos quizlet in case you have any questions feel free to ping me I'm also on twitter my twitter id is twitter or tat twit or tat feel free to ping me if you have any questions and need any help and I'm also here through the day