 So, that's me. I'm at song.io. So, I'm actually visiting from Sydney this week. I work for a startup called D-Graph and we are building a very scalable distributed graph database. But in my day job, I find myself writing a lot of JavaScript and Golang. But my first job out of college was Ruby on Rails. I wrote a lot of Ruby and I left my heart in Ruby community. So, I find myself again in the Singapore Ruby community. So, I'm here to tell you that using SQL in your Ruby apps might be slowing you down. So, how many people use graph database in production environment? So, there are many applications and many problems that are better solved with graph databases than SQL databases. And I'm here to show you a demo. So, to make my point, this is my plan. First, I'm going to showcase what graph database really is, what graph databases are good for. And I'll jump into the demo straight away. So, graph database stores your data in nodes and edges. So, something like this. So, these circles are nodes, represents an entity. And edges are lines connecting between the nodes. So, graph database is really good for edge traversals. Like traversing the edge between two different nodes because it's almost free in terms of complexity. Also, it's optimized for key value lookups because traversing edge is really cheap. So, this is Facebook open graph. So, you can represent people as nodes and you can represent the relationship between the nodes using the edges. This is Google knowledge graph which powers Google search. So, why do we want to use graph database? Because we can retrieve complex data really fast. And also, you can store data in a more natural way. No one really thinks about your data, their data in rows and columns. That's something we are taught in a college or coding bootcamps. When we think about data, we visualize them in nodes and edges. So, in this demo, I'm going to use D graph. It's fully open source graph database. It's the fastest graph database in the market. I'm going to share this slide. There's a benchmark. It's the only scalable database in the market. So, let's try to use it in Rails and let's try to see how we can solve a particular problem. So, everybody knows stack overflow. So, graph overflow is something I created as a demo. So, it's loaded with 10,000 users, 20,000 questions, 30,000 answers, and around 550K edges that are connecting these nodes. So, I'm going to jump into the demo and the source code for the demo will be available on Mirup.com. So, this is the main page of graph overflow. So, here on the left-hand side, we see the hot questions. And these questions are ordered in some sort of an algorithm that makes the most sense to get all the hot questions. On the right-hand side, we have a list of interactive questions, meaning these are the questions that users have, this logged-in user has ever interacted. Either he might have viewed a question or commented on the question or uploaded one of the answers. So, to create something like this, if you're using active record or something like that, it will require a lot of preloading and lots of joins. And those operations are really expensive to generate this single page. So, let's see how this page is actually generated using graph database. So, just to make sure, anybody here use Rails? Show fans? Okay, good. So, this code makes sense to everyone, almost. Okay, so, we have three different resources here. Question, Outboots, and Answers. So, this is a question controller. So, this index action is what's responsible for generating this whole entire page. So, if you have a look at this, there's a multi-line string called Query. And it makes an HTTP code to the DGraph instance, gets the JSON back, and store the payload as an instance variable to pass to the view. People at the back, can you see the... Okay, good. So, it's really simple. It's really simple apart from these long lines of query. So, what's interesting is that we don't have to do any active record preloading or joins. We can just retrieve the whole data with a single query. And this query language is based on GraphQL, so it's really intuitive for anyone. So, I don't think we don't need to understand the whole thing, but let me just quickly go through what's going on. So, this first block gets the question to show in the home page. So, these hot questions are retrieved by this particular query. So, let's see what's going on here. So, we are fetching all the questions. Question that body is a predicate that are connecting the nodes together. So, if there are more than zero question that body, it's a question. We get the answer and store the answer upwards count as this variable. And we store the count of the answer. So, a number of answers that this question has. And we sum over all the upwards count of all the answers. And we also store the timestamp created it. And here, we are calculating the score. And we are many graph databases support, as well as SQL databases, method operations. So, we are doing some sort of a time decay function so that we show latest question on the top. And here, we are doing some, we're giving each factor of weight so that we can calculate the score. And here's where we're actually fetching the questions. Does anybody here use GraphQL or have ever seen a GraphQL? Okay, one person. So, I'll quickly explain. So, GraphQL is a query language developed by Facebook. It's loosely based on JSON and you can fetch stuff like this. So, you name your entity questions and you can pass bunch of information. You're getting first 20 questions ordered by descending order of score. And what do we want to fetch? We want to fetch the UID for the route. And we want the question title by the timestamp. And we want to fetch the web node responsible for writing this question. For that, we want to fetch the username. So, as you can see, there's no over-fetching or under-fetching. So, if you're using active record, you end up getting the, mostly you end up getting the whole attributes of the model. But here, you only fetch what you want. Also, I can quickly go over the interactive question. So, here, we do the same thing. We store as variables whatever questions that user has viewed, whatever questions that user uploaded or answered. And we do the same thing. So, we fetch all the interactive question with those IDs and fetch the actual content. So, with this single query, you can generate this whole page. It means less network calls first. And it also means because you're relying on graph database, relying on a scalable database to do the work for you, it means that your organizations can save money literally because now your graph database is doing the heavy lifting. Also, it means that your users will experience less latency. It'll come out as a better user experience. And when we navigate into a question, we see the question, I mean, title, body and all the answers and upwards. And if the user uploaded the answer or not. So, all this information can be retrieved by this single query. There is no join or prefetching. So, you get all the question-related attributes. And for this question, you can get the first 10 answers without even thinking about joining between two tables. And for those answers, you can get all these fields related to that answer. And without even joining, again, you can get all the users that ever uploaded this answer. So, as I said, EdgeTravelSale in graph database is free almost. So, this takes almost no time. Okay, so there was a quick demo of how we can use graph database in Ruby application, particularly in Rails. So, if we think outside of the box and maybe stop relying on active record for a while, it might be a better way to solve your problem in your organization. So, what are the benefits? So, again, we let the database to the heavy lifting. It means you can invest less in your infrastructure. Because database with Ruby is very expressive and enjoyable to use. But it's not the fastest language in the world. So, by delegating all these works to a scalable native database, you can still keep the expressiveness of Ruby and also get the performance that you need in your organization. Also, as we saw, we can retrieve very complex data with a single query without even thinking about join or paying costs related to the join. It's highly scalable and not proprietary. It's completely open source. A lot of companies doing anything smart are using graph databases. Facebook, Google, LinkedIn, Quora, everyone. But here's a problem. They're all building their own proprietary solutions because there's no open source standard, open source solution that's scalable for everyone. So, by using DGRAP, we can give the power back to those guys in the garage to compete with the likes of Facebook. So, that was how to use graph database in Rails. So, as I showcased, it's super easy to use any kind of graph database in your Ruby apps. So, if you're solving a very complex problem with lots of joins, it might be a good chance to give graph database a try in your Ruby applications. It's super easy. It's simpler because you can retrieve very complex data with single query and it's faster because you don't pay the cost of joining two tables or multiple tables. Thank you very much. Any questions? So, what is it not good for? So, graph database is not good for databases that applications that require asset transaction. So, for example, if you're building a financial application like bank, I wouldn't use graph database to store my financial information because many graph, not all graph databases support transaction. So, it is true that graph databases are really fast to write and read information from. But, it is at the cost of asset transaction of the database. So, it's insured. Graph database is not good for any applications that require any transactions. So, I'm just trying to understand why you get out of using joins. It's not just like pushed into the database and the database handles it. So, you're wondering how the join is done under the hood. Yeah. So, there is no join actually because the way your information, your data is stored internally is they're stored in a way that to find the information everything is a single lookup away. It's a point. So, we store a pointer to another node. So, that's all the edge really is internally. So, it's a store lookup. I mean, it's a pointer. So, to traverse a single pointer is almost nothing. So, it's in a way when you store the data initially there's an extra cost but you reap that back when you because you have to instantiate the pointer when you put it in the database but then when you pull it out you can do it faster. That's the way the trade off here. Yes, but I wouldn't call it a trade off because even if you insert something in a SQL database you also pay a certain cost. And to store a pointer I wouldn't exactly call that a cost but it's I would say that it's a different way of storing the data so that you can retrieve the relationship a lot faster in the future. Any more questions? I have a question. How do you handle migrations especially if your model changes? Yes. So, DGRAP, well I can't I can't really say for other databases but for DGRAP we support schema and it's implicit or you can make it explicit and if you change the schema later all the all the data will be auto-migrated. Thank you so that was the first talk.