 Serenity Scream, and with these tools, we will wrap it up. So thanks so much, Roy, and a card if whenever you are ready, Jack, you can just jump in and start. Yes, ScalaSkips, can you see my screen? Yeah, we can see it and we can hear you pretty clearly. Okay, great. So let me just get started. Okay, yep. Hello, everyone. A warm welcome for everyone who's joined this online meetup. And thank you to Carlos and Russell team for making this event happen. If you guys missed my introduction, I'm Karthik. I work as Delphalations Lead at DGRAPH Labs. And all throughout this talk, we're gonna learn more about what DGRAPH is all about. So this talk is about how to build GraphQL APA functions for TwitterClone just in 10 minutes. And we'll see how using DGRAPH just by composing a GraphQL schema file, we can automatically get all the GraphQL APA functions, GraphQL, the current GraphQL APA functions which are necessary are using which you could build a TwitterClone on your own. So let's just get started. Firstly, who's this talk for? If you are one among those who want to get started with GraphQL in minutes and don't want to worry much about server side, this talk is definitely for you. And having said that, it's not just important to get started fast or getting started in an easy way, but it's also, you might be concerned about the scalability and performance of your GraphQL API as your application grows and your application becomes more complex. We'll add a statu and we'll see how DGRAPH solves all of these challenges. So I guess like now, most of the viewers are familiar with GraphQL schema. So a GraphQL schema essentially represents a graph. So next time when you look at a GraphQL schema, do remember that what you are looking at is a graph. And a GraphQL schema represents your application data graph. Let's learn a bit more about how a GraphQL schema represents a graph and let's do a live exercise. So let's just compose a GraphQL schema for a read. And this is how in general, this is an approach which you could use in general to compose a GraphQL schema for your UIs. And this exercise kind of gives you a streamlined approach towards composing the GraphQL schema even for the most complex UIs. So let's look at this UI. We all are familiar with this. This is the UI for the treat. And this is a treat of which we just saw a while back when GraphQL Hong Kong made a course and announcement was made. And the first step is to identify all the entities of your UI. In this case, we have a Twitter user who's actually sending out the tweet. In this case, GraphQL Hong Kong is a Twitter user. And what other entities do we see here? We have the actual tweet, which is a second entity. And we also have Adlerate mentions. And Adlerate mentions are again Twitter users. So even the entity who's posting the tweet is also a Twitter user. And also the mentions are again Twitter users. So we now have two entities. One is a Twitter user and then the actual tweet. And the third entity could be the hashtags, right? In this tweet, we only see one hashtag. We have two, but in general, you can have any number of hashtags in a tweet. So now we have three entities, namely a GraphQL user of the tweet itself. I'm sorry, that Twitter user, the tweet itself. And then we have a hashtag. The next step is to represent all these entities as a node in a graph. So we had three entities and now we represent all of them as nodes. Namely, now we have user node, tweet node and a hashtag node. The next step is to see how these different nodes are related to each other. Do we have a relationship between a user node and a tweet node? If you look at the UI, yes, we definitely have a relationship, right? A Twitter user is a one who actually authors a tweet. So let's represent this relationship using an author's edge from a Twitter user node to a tweet. And next, let's see like from a UI, is a tweet in any way relates to a Twitter user? It does, right? A tweet can mention a Twitter user. So let's represent this relationship between a tweet and a user, a Twitter user, using a mentioned edge. So these edges essentially represents the relationships between these nodes. And again, the relationship between a tweet and a hashtag node is can be represented using a tag with edge. So again, quickly, so we started with our UI and then we represented, we have firstly identified all the entities in the UI. We identified three entities. We represented each of the entities as a node and then we represented the relationship between these entities as edges between these nodes. So the next step is to translate this graph diagram, what we call as an application data graph to a GraphQL schema. That's relatively easy to do because as I mentioned earlier, every GraphQL schema essentially represents a graph, the graph of your application data or the data requirements of your UI. So let's see how to now, how do we translate this into a GraphQL schema? The first step is to represent each of the nodes as types in your GraphQL schema. So we had three nodes and now we represent or we create GraphQL schema types for each of these nodes. And you could see that we now, we have three types that is like type user, type tweet and type hashtag. And the next step is that now we have the templates for all the types corresponding to each of the nodes from our graph. The next step is to represent the relationship or this edges between the nodes. So the way we represent this relationship is by creating a field for your types where the field would refer another type. In this case, you have type user which refers type tweet and author it. So similarly, if you see the type tweet, the type tweet refers back a type user while and mentioned it, right? And the next step, once we have the relationships of represented using the types referring to each other is to fill in what other fields each of these entities would have and what are its types? For instance, for type user, each user would have a unique ID which is represented by the GraphQL standard type, the ID type, and then a user would have a username. A Twitter user also would have a user handle which is a string and we again have the relationship of a user with a tweet by an author it. So after we represent the relationships, the next step is to fill in the fields for each of the types. And similarly, we now fill in the fields for the other types, right? We have that tweet has a unique ID of a tweet. Also has a tweet message, it's a string of, I think in the last slide, when we start on representative relationship between a tweet and a hashtag. So now we represent that using the tag with edge. Now we have the GraphQL schema, right? We started with your application UI and we added the data graph for your UI and then we represented the data graph as a GraphQL schema. And what you see now is essentially the representation of all the data requirements for your UI as a GraphQL schema. And the next step is just by using this GraphQL schema file, we're gonna auto generate all the credit GraphQL functions necessary to build a Twitter clone or to power all the data requirements of your UI. And let's see how to do that using DGraph. And before we do that, let's understand a bit more about what is DGraph in the first place. DGraph is the world's most advanced graph database and DGraph is open source, is a transactional and distributed native graph database. And here is what's exciting for the folks from the GraphQL community. DGraph is the only native GraphQL database which natively interprets and distributes, stores and executes GraphQL, which means that GraphQL is a first-class citizen for DGraph and GraphQL is not an additional layer on top of the database. You might have used other database alongside GraphQL by having an additional GraphQL layer on top of the database which translates the client GraphQL queries into the corresponding database query language. But in case of DGraph, GraphQL is just built in right within the database and GraphQL is a first-class citizen. So there's no layer being required and DGraph is also built from ground up to serve GraphQL workloads. So with DGraph, all you need to know to get started is just GraphQL. You're gonna just soon see it in action wherein we'll take the GraphQL schema file which we composed and just hand it over to DGraph and DGraph out of the box auto generates all the GraphQL crack functions you need. And then as your application evolves, where you need new product features, all you need to do is again, come back, edit your GraphQL schema file and iterate on your APIs. So not just you can get started with GraphQL, you also iterate only using GraphQL. And DGraph, the database admin endpoints are also GraphQL. So which means like all the database operations you can perform using the GraphQL endpoint with which DGraph provides. And DGraph is built, every database is built for a very specific kind of workloads. And in case of DGraph, it's built from ground up, it's built from scratch to be able to efficiently serve and scale for Graph like or GraphQL like or GraphTraverse like workloads. So if you are a GraphQL user and if you're building GraphQL applications, the kind of workloads your database would be operating in once you have a lot of client queries coming in because you're using GraphQL in the front end, DGraph efficiently resolves all the data requirements of your UI in one network call, in one shot because that's what it's been built from ground up to serve efficiently and scale for. And okay, let's just see it in action. Let's run DGraph. We are using DGraph standalone container. This is not a recommended way to run DGraph in production but this is great for quick start purposes. So let's start DGraph. So the database is up. And so this is a GraphQL schema which we just composed which represents the UI for a tweet. And the next step is to submit this GraphQL schema file using the curl request to DGraph. So let's do that. So this is successful. We just submitted this GraphQL schema file. And now you can use any of your favorite GraphQL editors field use GraphQL Playground. If you're just powering up your GraphQL tool or GraphQL Playground just point it to HTTP colon slash slash local host ADID slash GraphQL. So let's just look at the introspection and you could see that DGraph has auto-generated GraphQL credit functions. Now for each of the types which is submitted to DGraph auto-generates five GraphQL functions. For instance, corresponding to the type user we have get user, query user, update, delete and add user auto-generated. And similarly, you can see that corresponding to the type tweet which is submitted we have get tweet, we have query tweet, we have add tweet, update tweet and delete tweet. So for, as I mentioned for each of the GraphQL type which you submit DGraph auto-generates five GraphQL credit functions. So now let's just add some tweet using the mutation. Let me just quickly see, there seems to be an error. Okay, I just see that a value is missing. Let me just quickly grab the mutation from schema again. We have the mutation. Oops, there seems to be an error. We should be able to type tweet request of value for field author. I think we're just missing. Okay, let's just move forward. I think it's just a issue with the mutation format. And basically once you submit the schema DGraph auto-generates all the credit API functions for you. And then once you have the credit functions let's say you start to iterate on your application and then you have a new requirement for your app that is to be able to have a search feature for your user handle. So it's very simple now. All you need to do is just come back to your schema just edit the schema and add a simple directive to your schema. In this case, we add iterate search by hash and just adding this entry making this simple edit to a schema gives you ability to search for users based on the user handle. So just go back to the schema and just to make this simple entry. So let's just grab the schema change for user handle and go back to our schema. Let's add this, save the file and let's just resubmit the schema file to DGraph. Okay, so this is successful. So now just on adding a simple directive you would be able to query for the user, right? So you can filter, add a filter to say, hey, by the way, find the user by name Hackintosh Rao and give the user's information and you can then request for all the tweets the user has authored and then you can even probably request for the hashtags of those tweets. So have tagged with and then hashtag and the inspection makes it really easier to be able to get all the auto generation recommendations while you compose your schema or your queries. So let's say now we are able to search for user based on the user handles. How about we, that your product now needs a new feature to be able to search for user by user names too. Again, pretty simple. Come back to the schema and just add a new directive at the rate search search for user by hash, hash essentially sets and hash index in the database which allows you to search user by user's name. So let's just do that. So let's just make that simple addition into our schema and now let's just resubmit the schema to digraph and that's it. You should be able to run a query to now to search for user based on user's name. Similarly, let's say now you want to search for user just by using user's first name or last name instead of the full name. All you need to do is just again, come back and edit your GraphQL schema, right? To change the index for username from hash to term. So this essentially helps you to enable you to search for user based on user's first name or last name or any of the terms in user's name need not necessarily use the complete string of the user name. So very simple, just come back, edit the index, resubmit the schema and now you should be able to search just by using user's first or last name or any of the terms in user's name. And similarly, digraph offers a variety of indices and it's very simple. Every time you need to add a new product feature, come back, add a new database index to your GraphQL types and resubmit it and digraph rebuilds the index on the life. There's no need to even restart the server and you should be able to then use a new more powerful creating facilities. For instance, let's say to power your Twitter search you want to be able to search by such using a regular expression. For instance, I'm Kartik Raph, let's say if you want Kartik Raph to be in your user search, in your Twitter search, even if you use a substring of my name, let's say ART, in such a case you need a regular expression search capabilities, again, very simple, just come back, add the regular expression index, save, same process, resubmit, then just come back you should be able to run this query wherein now we are searching just based on a substring in the user's name and as soon as you type ART in the search box, then you should be able to get the recommendation of Kartik in the list of users you're searching for, right. So again, we digraph as I mentioned, it's not just you can get started over there using the database just using GraphQL, but also you can iterate as your product requirements evolves as your UI requirements evolves just by using GraphQL. Now, similarly, like we moved on from our last schema to extend the schema to offer new search capabilities. So if you look at type tweet, we've added a full text search for based on the content of the tweet that is the strings in the tweet itself. And similarly, if you look at hashtag, we added a regular expression based search for hashtags too. So we just looked at few of the database indices which digraph offers and every time you come back if you want to make use of this database index to power your application feature, you just edit the GraphQL schema file. We saw regular expression hash. Now we see full text search and also digraph offers other advanced indexes like geo search. If you're building a mobile application or a web application which uses location data, which where you want to build queries, like find me all the restaurants within one kilometer of this location or within a polygonal structure. It's super easy to do that. And we are adding more powerful capabilities, more powerful indices database and all you need to do is every time to make use of it is to come back and edit your GraphQL schema file. So let's just quickly extend our schema and update our schema with this full text schema. Okay, here we have the full text schema. And now again, just resubmit the schema and go back to the playground. So now we can do a full text search based on the content of the tweet itself, which was not possible before and all we had to do to enable this feature is to add a very simple directive to your GraphQL schema. So let's move on and let's just have a quick recap, right? Now with Dgraph, all we did to obtain the credit GraphQL functions is to compose your GraphQL schema. So if you're an app developer, if you're a GraphQL developer or building your mobile application or web application, start with a UI, identify the entities, get your application data graph and convert that into a GraphQL schema. And then that's all you need to get started with Dgraph and Dgraph gives you full-fledged credit GraphQL functions to build your applications and all of this from just your GraphQL types. Right, yep, that's all I have for this talk. I am pleased to check out Dgraph's website graphql.org or Dgraph.io and more specifically if you're interested about learning Dgraph's GraphQL capabilities, you can take a look at Dgraph.io slash GraphQL and Dgraph is open source. Please do feel free to go download and try Dgraph. And I think the easiest way for you to be up-to-date with all the updates from Dgraph Labs is to follow Dgraph Labs on Twitter. Please visit at the rate Dgraph Labs or you can follow me on Twitter at the rate hack into SH, RAV, that's hack into RAV, that's me and other two resources are to stay up-to-date would be to follow Dgraph's blog at blog.dgraph.io and also I think Dgraph would be a good place to follow up with all the products development and even the product roadmap. Thank you, thank you everyone for your time and thank you Carlos for having me here. Yes, it's a pleasure to get together. Thanks so much for joining us and introducing us a bit about Dgraph. I think it's such a promising technology. We do have a question for you. So Tobias, actually he's asking about what is the difference between the term and full text? Right, right. Yeah, so these are two different database indices and term index enables you to search only based on our terms in the string. For example, if this is your string, what I'm highlighting, is my screen on? Yes, sir. Okay, yep. Okay, so the term index enables you to search by any of the term in the string, but this term has to be exact. For example, we have, let's say Carlos Rufo. If you are searching for Carlos, you can search for Carlos either by searching for Carlos or for Rufo. So any of the terms in the string, but full text search gives you more advanced string search capabilities. This is more meant for paragraphs of texts. Like let's say if you have the information for your entire blog or it could be a tweet or it could be a bio, right? And this essentially contains a lot of strings, sometimes hundreds of strings and hundreds of characters. I think full text search is ideal for searching for such entities where you have a lot of words. And in case of full text search, you need not search for the exact string. Let's say your string says, I am talking at GraphQL of Hong Kong, meet up today in the evening. You can search for talk Hong Kong graph, that's it. So you need not use the exact strings. You still be able to get this particular string in your search results. So it's a more powerful string search facility or a feature which is typically used for entities where you have a lot of words. As I said, for instance, it could be a blog post or a bio or a tweet wherein it's difficult to have a lot of characters, a lot of words in it. Awesome. Yeah, I think like a, it was a really good answer. And a, basically I guess it's a different search for some ideas depending of whatever you need in that filter, let's say. And to wrap it up, probably the QA, I got a good question. So I would like to know the main advantages of the graph compared to other graph databases solutions. Right. Firstly, the graph is a native graph database. If you're talking about just graph databases or databases with support GraphQL, Okay. So in terms of scalability or like distribution, is there any advantages of the graph? Definitely yes. So firstly, the graph is a distributed database, and which means it's horizontally scalable. And you can start with one node where you're starting to build your application non-volume customers, but as your business grows, you can just keep adding the second node, the third node and fourth node and fifth node and so on. It just seamlessly scales. And it's specialized for high throughput, low latency use cases. It's built from ground up to be super-performance for graph-like or graphical-like workloads. I think that scalability, the graph offers and its performance, I think is something where the graph stands out from the rest of the graph databases in the ecosystem. Okay, that sounds awesome. So yeah, I think that we can a graph be that for today. Yeah, so if you want to just like stop starting your screen card deck and then we can just jump into just like for graph it up probably. So great. So yeah, like thanks so much to everybody. There are another question, what is the testing history for it? Can you have any memory version on it? Can you just put it into my test? So there are like a few questions, Karatee in the YouTube channel, but you can feel free to go there and just like sit with a Ta-Ma sermon in order to answer the question because we are running out of time. Basically to finish off, I really wanna thanks to everybody's for your time, for your knowledge. And probably like Tobias as a co-organizer, he can jump into closing the middle. Yeah, thank you Carlos. I think first of all, thank you everyone.