GraphQL Galaxy

GraphQL Galaxy 2022

Schemas Everywhere: Understanding GraphQL, Databases & Prisma

Welcome, everybody. Thank you so much for joining me for this talk. I am very excited to be giving this in a lightning talk format. I've given the same talk before in a full length format and I've condensed it down into just the necessary pieces. So looking forward to see how this will go. If you have any questions about the talk after I've given it, feel free to shoot me a message on Twitter and I'll be happy to answer any questions you might have. But before we get into the meat and bones of this talk, let's talk about the bigger picture concept that the world itself runs on data. Whether it's your cell phone, whether you're using Facebook, or maybe your refrigerator, or whatever you have that's connected to the Internet, everything runs on data. And as developers, it's actually our job to manage this. So it's a heavy load to put on our shoulders, but that's what we signed up for when we became developers, is to actually take this data, do something with it, and spit it out in a format that other pieces of software can use. So the TLDR of all this is that in order to manage a set of data, you have to have some sort of knowledge about its structure and its purpose. You have to know why you're dealing with your data and why you're doing what you're doing in your application's code to your data. So to revise this original statement, not only is it our job to manage this data that the world runs on, but it's also our job to, at least to some degree, understand it. And this is hard because in general, data is hard to model. As technical people, we have a lot going on. We're doing a lot of technical things. We're developing applications. We have a lot of this knowledge to keep in our heads. There's not a whole lot of room to understand the whole data domain of whatever industry you're working in at the time. So a couple other reasons, though, why your data is hard to model. As your data flows through different areas of your application, you have to know how to interact with this data. So it needs to be modeled in a way that works with different pieces of your application. Your data model may change as your application evolves. So as new requirements come up in your industry, you may have to evolve your model a bit. And doing that in a way that's safe for your application can be difficult at times. Another one, and this is a big one, is that your data may not have been modeled by you. And I would also revise this to say your data probably wasn't modeled by you. You're probably consuming data from someone else and using it within your own application. So for all of these reasons, we as developers came up with this idea of schemas, which is a way to clearly and concisely represent your data model. But there's still a problem, even with schemas. Schemas are now everywhere. So we've solved this problem of being able to model out our data in a way that makes sense. But now that we found a good solution, we're using it everywhere. And the original intent for the schema is now lost. So what the schema is supposed to be is a source of truth for what your data looks like. But as you start adding different schemas everywhere, it begs the question, now what is the source of truth? So this causes the problem that you now have multiple perceived sources of truth. And each schema may describe your data a little bit differently, which is what probably causes the question, what is the source of truth? And also, each schema has a different role. And if the schemas look similar, it's kind of hard to determine what the role is of each individual schema. So to put this shortly, each individual schema in your infrastructure defines your data in the context of its own domain. So whether it's your database, your API, or something else, the schema is describing the data for that individual piece of your application. So we're going to look at a stack that has a database, a GraphQL API, and Prisma thrown in there as well, so that we can look at the individual schemas and how they relate. So to start off, we'll look at the database schema. What you see on the right is the code that you would need to write to create a basic database schema. This is written in DDL, or a data description language. And it's typically a database-specific language here. So this is a little bit complicated. These languages tend to be a little bit harder to learn than something like JavaScript or something a little bit easier to look at on the eyes. And for this reason, we at Prisma created our own language here called the Prisma Schema Language. And this allows you to model out your database schema within a Prisma schema file. The only difference is that it's written in this language that's a little bit more like GraphQL, that's a little bit easier to read. This is important here because now as new developers come into your application, or maybe someone who's non-technical will come in, they can actually look at this model and sort of see what's going on. This is also important because it's in a simple enough model that we can actually use this within Prisma to generate a type-safe Prisma client that interacts with your database in a way that's safe and ensures that the data you're accessing is actually available. And then finally, we have the GraphQL schema here. So this looks similar to the Prisma schema. However, there is a big difference. This is where a lot of people end up getting confused with schemas. The GraphQL schema tends to look very similar to your database schema because it's exposing data from your database. But the problem here is that it should probably not look exactly like your database schema. This isn't defining your data here. This is defining what your API exposes. So for example, to elaborate on this, you may be exposing data from your GraphQL API that's not even in your database, or you may be not exposing certain fields from your database for security reasons. And because of these things, your GraphQL schema is a completely separate thing from your database schema. It may feel a little bit like code duplication as you're actually writing them. But if you understand this difference between the two different schemas here, it starts to make a little bit more sense. So just to recap, we've got our database schema, which is the schema running on your database server that defines your data shape. You have the Prisma schema, which will live in your API and your API's code. And this is actually what is used to generate the migrations to update your database schema. And it's also what's used to sort of create that mapping and to fill in the gap between the database and the API so that you can have nice type safe interactions between the two. And then finally, you have the GraphQL schema, which is what the client uses to safely query your database via your API. But there is another gap there. So right here on this slide, I've got the gaps. And if we fill those in, what we get is we get Prisma in between the database and the API, as I mentioned. And you also get something like GraphQL code generator or maybe another tool that does something similar. And what this does is it generates types for your front end client based off of your GraphQL schema. So when you have all these pieces in place, all these schemas used properly with these nice tools in between them, you get a nice end to end type safe sort of situation and environment where your types, even from your client, are based off of your database types. So thank you so much for joining me today to talk about the differences between all of the different schemas that you might work with in your application. I hope it cleared some of those little things up about the different schemas that often confuse people. If you still have any questions, though, feel free to shoot me a message on Twitter about them. I'd be happy to answer. So thank you again, and I hope you have a good rest of your conference.


Sabin Adams

Real-Time Data Updates for Neo4j Using GraphQL Subscriptions

Hi all, I'm Thomas Wies, I'm a software engineer at Neo4j in the GraphQL team. And today I'll be talking about real-time data updates for Neo4j using GraphQL subscriptions. But first things first, right, we have to talk about the database that we use and it's Neo4j. And Neo4j is also a company, but mostly known for its database. And a database that can actually scale very heavily and it doesn't have any schema. All you need is nodes and relationships, which form a graph, as you can see one here, a movie graph with relationships and nodes. And the nodes are the bubbles and the relationships are the arrows. And the most important thing to note here is that both nodes and relationships can contain properties, so they're first-class citizens. Of course, if we have a database, we need a way to query that database or a query language. And that's what Neo4j built as well. It's called Cypher. And Cypher got a lot of inspiration actually from SQL or SQL, but it added some more things on top because you have to query graphs. So we have to do things like graph pattern matching. And one example, a simple example on top is here on the top row where you can see a match where we match a person who acted in a movie. And we have the arrows pointing or indicating a relationship. And this way we can actually read it quite intuitively. And believe it or not, it's actually very easy to learn. And it has a lot of the power that SQL already has built in here. So where clauses match, et cetera, et cetera. And we call this ASCII, or it's almost ASCII art, what we do here. So now we have a database, a really amazing database. And of course, the topic of this conference, GraphQL. And wouldn't it be great if we could just get those two together, right? Could we do something like this here? Yeah, of course. We can do that, actually. We already built it for you. And we started two years ago building an open source library written in TypeScript for your convenience. And all the library doors or the centerpiece of the library is, as you can see here in the image, it provides an API, or it's the base for an API for a GraphQL API, where the GraphQL clients can send their GraphQL queries to the API. And the library in the background translates on the fly this query to a Cypher query and sends that to the database and the response back to the API and then back to the client. And that's all handled for you automatically in the background. You don't have to do anything here. But we need an API, right? We have to define the API somehow. And usually you would go along with this or something like this, right? You create your types, your type movie here with a field title. And then you have to do this cumbersome stuff here. You have to write read queries. You have to write all these mutations, add, change, remove, et cetera, et cetera. You even have to write the resolvers for all of that. How painful is that? That's so, no way. I'm not going to do that. I want automatic schema generation, right? I mean, you do the boilerplate. I do automatic schema generation. And that's exactly what we did with the Neo4j GraphQL library. So the only thing you have to provide to make your GraphQL API ready to be used is to define your types or the type definitions. And we just take a very simple one here to get started. A movie with a title, all you need. And then the library in the background for you will create this here. You will get the read queries out of the box. We haven't done anything, but it's all available for you. So you can do read of movies with filtering, so where, for instance. We have aggregates already ready for you with, again, with filtering built in. We have connections, like the relay connections specification is implemented here. And where you can do cool things like cursor-based pagination, all of that out of the box. And you know what's the best part of it? The resolvers are already written. You don't even have to write that as well. When it gets better, wow, mutations, they're also included. You can create, delete, update movies, all these nice things. Again, filtering wherever you need it is already included. And again, the resolvers, they're actually already built in. You don't have to do anything. But that's kind of interesting. So let's have a look at how all of this works on that query level. So something you're familiar with to start with, right? We have a GraphQL query where we want to get all the movies which were released in 1999. We want to get the title and the name of all the actors that acted in it. So far, so good. The Neo4j library, GraphQL library, sorry, will then automatically translate this when it sees this or gets this GraphQL request to this Cypher query. And I'm going to walk you through it real quick. So on the top, we match all the movies, then we get or filter out only the movies with a certain release date, 1999 in this case. And then in this call subquery, the brackets, what we do is we do a relationship traversal from the actor or the movie to the actor, and we get all the names for it. And then we pack it all up, all the actor names and everything in a form that the GraphQL client can consume or that it actually expects. And do you know what's the best part about this? One GraphQL query matches one Cypher query. Do you see what's missing? The N plus one problem. It just doesn't exist. It took care of it. You don't have that problem. We need one query, resource it, one call to the database, and it's all done. Isn't that cool? Right? So now that you know all the basics there are to know, let's go on to the actual cool stuff, subscription, right? So just on the highest possible level, what are GraphQL subscriptions? Two entities are involved, the client and the server, where the client subscribes at the server for a particular event. And by doing that, they open up a permanent connection. In the GraphQL specification, actually there is no clear definition of what the protocol, like on the transport layer, what the protocol is supposed to be here. It's actually up to the server. So what we've seen is that most actually use WebSockets or the WebSocket protocol to do just that. And in the demo that I'm going to show in a while, we do exactly that. We use WebSockets. So once the connection is established, the server then has the possibility to send or push through events to the client without the client having to do anything, right? No busy pulling, no nothing like that. And we can send as many events as we want, which is pretty cool, right? So we have our real-time data updates, just what the title has promised. Let's go a level deeper and have a look at how it's implemented using the Neo4j GraphQL library, where the library is the instance in the center, and there will be a couple of more of those pictures. So it will always be the same, the instance in the center. So in this setup here, we have a client on the right-hand side who subscribed to an event. And then another client, the one on the left-hand side, sent a mutation. Think of creating a movie, right? Sent a mutation, it gets translated to a Zafiq query on the fly in the Neo4j GraphQL library, gets executed against the database, and then it comes back to the Neo4j GraphQL library, which then informs all the subscribed clients that this event happened, right? Pretty straightforward to this point. There's one thing that we have to keep in mind here is if someone were to make a change to the Neo4j database there at the bottom of the image from the outside, so not using the Neo4j GraphQL API, we wouldn't detect that. That's a limitation right now. We know of that, but we actually work on it. So stay tuned. It might actually be fixed going forward soon enough. The other thing is this is completely agnostic. There's absolutely nothing that prevents you from building on top of this. But I think now I gave you enough context to see all of this in action. And you can look at this demo or at the demo code later on from my colleague, Andres. He built these amazing demos, not just the one I show you now, but several of those. But we're going to have a look at it. So let's head over to the code and look at some code. So as you saw before, the first thing we have to do is to define the type definitions. And we're going to use a slightly bigger type definition this time than just the type movie. So the first thing we do is define two types, type movie and type person, and give them some fields as we specified here. And then you see a relationship or a directive that you haven't really seen before, which is called a relationship. And it does exactly that. It forms or specifies the relationship between the movie and the person. And in the directive, we can specify what type of relationship it is, acted in in this case, the direction, and the properties. Because remember, in Neo4j, the relationships, they're first class citizens. They can hold data. And that's how we specified in GraphQL. We specify an interface, and then we can add any data we want here. We're just providing some roles because you have to have a role in a movie, right, as a person. That forms our base. So let's briefly look at the server code because that can be quite interesting for a lot of people as well. The first thing to note here is subscription is a plugin, right? So we let people develop their own plugin. If the community, someone in the community, maybe you want to develop your own plugin, you're free to do that. We have provided a bunch of them for you already, but more on that later. For the demo, we use something very simple. We use event emitters from Node.js to get it done in a fast and quick manner for this demo. So you define a plugin. We have some for you, so no need to write them yourself. But here, this is a demo. I want to point out a couple of things. Then what you got to do is you have to get your type definitions, of course. You have to create a driver, a Neo4j driver to access your database. I started that in the background for the demo, so that's all running. No worries here. Then as a first important point is we have to pass those to the Neo4j GraphQL class, which we then instantiate later on, and also include the plugin to make sure to the GraphQL API or the Neo4j GraphQL instance that is running to show subscriptions are on. We're on here. And then we have to do the entire server setup. We have to get an express server, a WebSocket server on top of that. I'm just leaving out a bunch of details, which you can look at your own convenience. They're not really adding to the demo right now, but it's not really hard. Don't worry. Then we have to create the schema, including all the resolvers, right? And we just pass that schema to an Apollo server, because it's just a convenient way to do that, to use Apollo. Then we can start it. I did that already, so we're not really losing any valuable time. If we head over to the code, the first thing you're probably going to notice is over here, the root types. I mentioned those before. We have the query and mutation, where the auto-generated content is ready, create, update. But we're not interested in that right now. We want to have a look at subscriptions, right? Subscriptions comes with a lot of this automatically generated goodness out of the box for you. We have, for instance, movie created, deleted, and updated. Same for a person. And again, we have where clauses or filtering already built in for you. The same we also have for relationships, right? Because they're first class citizen. So if you create a movie and an actor connection, this is built in for you. You can just use it. And that's what we're going to do now. But I start with a simple case, so we all get our heads around it quite easily. So we can create a subscription, right? A movie created with an event and a timestamp. And then we want to know from that particular event that we get back from the movie, what exactly you want to return. So what has been, and this is just standard GraphQL, so I can add whatever I want here. And I know there's a tagline, so I'm going to add it. Then I hit subscribe, and I see it listening. What do we have to do now? Create a movie, right? Let's do that. So we create a movie. We have a mutation, create movie, story of toys. And if we execute that, we see we already have a subscription in, but we also have the regular response from the mutation that comes back. And we have subscription events here, like create. We saw the event that is create, the timestamp, and the movie in exactly the form that we requested. And this is subscription, right? We want to see multiple of those. Look at that, too. And of course, if I add another one, it will all come in a natural flow. And I didn't have to do anything, right, except listening to it. So let's stop this example and hop over to the relationship one. So if there's a movie relationship created event, we do the same again. We want to see which event it is, the field name of it, then which movie got created, which actor node got created, so which actor, and the roles that actor had. And again, here we can do whatever GraphQL offers us at this point. Let's hit subscribe. Again, it's listening. That's amazing. And now let's create a movie and an actor, right? So we create Gump Forest with an actor called Kevin Bacon, and he apparently was a runner in that movie. We have to see that, right? So let's store it. And again, it's here, right? We have connect as an event type, relationship field name, Gump Forest is here. And of course, if I just create another Kevin Bacon E, look at that. He's here as well. So that all works out of the box. And it's extremely fast. As you can see, it's already here. So that concludes our demo part, and I'm going to show you some more details in the background. So let's head back into the slides. And now they're loaded. So prior to, if you don't have subscription turned on, so just regular GraphQL quotes, if you create a movie on the left-hand side, a hot fuss with a GraphQL query, the Neo4j library will create this Cypher query for you. So a call subquery again in brackets, create the movie, add the title or set the title and return it in a fashion that a GraphQL client can understand. But then if, as before in the demo, if we turn on subscriptions, we have to add some extra data. The good thing is, and that's how it's supposed to be, the mutation on the left-hand side for GraphQL query didn't change at all. But we have to add some extra information to the Cypher query, which is this metadata here with an event create, as we've seen before, the type name, the timestamp, all the things you've seen in action before. We add that into the Cypher query because then at the bottom, you see there in the return statement, we return it back after it has hit the database. Why do we do that? This means we can keep consistency in the database without actually changing anything. We have one mutation that changes the database, but then we can have a multitude of subscribers on the other end that are consuming this event. So we have absolute data consistency in the database and we can subscribe or send the event to as many subscribers as possible or as they're subscribed without having an impact on the data or the database. But that's actually the point, Thomas. So many thousands of subscribers, is that going to work? Do we not need to horizontally scale all of that? In this case, the GraphQL library at some point, it cannot handle everything. So we have to horizontally scale it, which means we will end up with situations like this here where a client subscribes to an instance where the mutation on the left hand didn't even occur. Isn't there an amazing link here? I mean, how does this work? But obviously, rest assured, otherwise I wouldn't talk about it. This is fixed. We already built all of that for you. So this will work, which means your use case will scale. Both your Neo4j database and your Neo4j GraphQL API will scale with your use case. And we do that, as you can see here, by after we do the mutation, the Cypher query, and it's back in the GraphQL library, we will push an event there, number three, to a broker, which can be Kafka, which can be a Redis or a RabbitMQ. And that broker then in its turn will broadcast or fan out the event to all the running instances, and those will then send the event to their subscribers. So scaling solved, right? And now you may say, Thomas, cool, that's a nice promise, but this must be very hard to implement and set up and all of that. Actually not. It's super easy. Look at that. Remember the plugin system from before? Well, we already built a plugin for you that handles just that case. It's called subscriptions AMQP, and all you have to do is define the connection details and credentials to your AMQP broker. And yeah, sorry, you still have to set up that one, but there's many ways to do that. So you only have to provide us the credentials or the plugin of us, and you pass that plugin to the Neo4j GraphQL instance or class as you did before, and as you saw in the demo, and off you go. That's all you need to do. Currently subscriptions are still in beta, but they will very soon be generally available, and then you can get started with this. But to round things off, I want to talk about something really cool. So this you may have seen somewhere before. It's on Reddit, and it was in 2017 on April Fool's Day. It's rplace, rplace, and this allowed users to set one pixel or one color, then they have to wait for 15 minutes and set another pixel, and so on and so forth for a lot of users. We created this really, really amazing community art, and we thought this is the coolest thing to show or to showcase our GraphQL subscriptions, and we did just that. We created NeoPlace for you. You can actually access it right now under this link, under this bit.ly link or the QR code here that is visible. We took the same ideas but built it with the things that I just highlighted before with a Neo4j database in the cloud and Oracle database. We used a broker to make horizontal scaling and breeze. We of course used our Neo4j GraphQL library and the GraphQL API, and of course, I mean, GraphQL subscriptions for a real-time update of when people set the pixels or not. So go here, try it out, have fun, draw something amazing, and enjoy the power of GraphQL, GraphQL subscriptions, and Neo4j. And that's actually all I have for you today. You can head over to the open-source library. It's under GitHub. You can see here on the link where you can find us. We have all the plugins there, a lot of things to take in. Open-source for you available all the time. And this also is a great opportunity to say thank you to our community. You can always reach out to us on Discord under this link. We really had a lot of time and inspiration from our community, and they helped us build the product that is there now. And if we wouldn't have you as a community, we wouldn't be here right now presenting this wonderful product. So thank you very much, and see you next time. Bye-bye.


Thomas Wiss

React Summit

React Summit 2022

Content Modeling for React Developers

Hey everyone and thank you for joining in. In my lightning talk, my name is Harshal and I work at Contentful. Alright, so yeah, as I was saying, I am originally from India but I live in Berlin for 15 months. Still exploring Europe, still exploring, still trying to be a more Berliner. And I work as a developer advocate at Contentful. I recently joined Contentful and it has been an amazing experience because I get to experiment a lot with different technologies and framework and share it with the wider community. And I kind of love doing that and I build a lot of weird projects. You can check it out on my website or just hit me up on Twitter. Alright, so today I'm going to talk about content because in the past two years, the amount of content that we have generated is massive. I mean, everyone out there has created content in some form or another. In November last year, during the Black Friday sale, we saw a massive increase in the API request that we got at Contentful APIs. For example, the GraphQL API request was increased by 550% while the content delivery API or CDA was increased by 73%. And so, as a developer, I believe it is on us to make sure that we provide that amazing experience, not just to our users but to our team. But how do we do that and what is content modeling? So basically, a content model allows you to structure and organize your code. Now remember, you have the technical expertise but not all your content creators or your designers would have that technical expertise. So we need to make sure that we provide that value and we provide that easy workflow for them to create content. So that's quite enough of theory. Let's get into action and I want to talk today about Cookbook because I have taken cooking as a hobby recently and I'm trying to create a web app because I am a programmer and I believe I can do that. But anyways, so in the couple of next slides, I'm going to talk about my approach of how I am modeling my content for this particular application. So I've taken the top-down approach so that I can break down the elements into smaller pieces, into smaller chunks, which would basically help me to reiterate my content model over and over again. So I started out with wireframing and TeddyBullet design. Don't judge me on the design, but this is what I envision my web app to be. So a simple web app which shows a list of recipes and each of these cards basically have an image, a title, and a description. So this simple wireframework gave me an idea of what information I need in my content type. So in Contentful, this is what my content model looks like for the recipe content type. So now I have the title, I have the description, and I have images. But we are missing two important things. If I open each or any of those recipes, it has a title, it has the images, it has the description, but it needs to have those ingredients as well as the instructions on how to cook them. Otherwise, no one knows how to cook their particular recipe and it's going to be just a mess. So with this page, I kind of realized, okay, I have a few of this information, but I need the ingredients as well as instructions. And that's what I went ahead and added in Contentful. So I added two other fields. One is ingredients and the other one is instructions. Now in ingredients, if you see, it shares its reference because ingredients are going to be shared among other recipes as well. Hence, I created a separate content type for ingredients and I'm going to show you just that. So this is my ingredient content type and it has a name and a type. And there's too many types going on in this talk, so I'm just going to try to avoid using that word. But this is how my ingredient content type looks like. And this is the overall content model. So the recipe has a reference to ingredients, ingredients has a reference to type, and recipe also has an ingredient to the assets, which basically contains the images. Now, one of the other features that I kept in mind when I was building this content model was reusability because as React developers, we build on components and we want to make sure that we use those components again and again. And we don't like to, you know, code those lines of code again and again. And that's what I did over here. I knew I was going to have ingredients for a lot of recipes which are going to be common. And that's what, and that's how I selected ingredients to be a separate content type. The next is content governance. Now, this is mainly important when you are working with your team and your team is going to be the one who is going to create the content, publish the content, and review the content. This is where you have to decide on what kind of workflow, what kind of content governance do you want. Do you need to give access, do you need to give published access to everyone and only a limited amount of people need to have that access. And the next is, and the next very important thing is platform because you need to decide which platform this content is going to be used. Is it just going to be web? Is it just going to be mobile? Is it going to be both? Or is it also going to be a voice enabled application? So that is also one of the key factors that you need to keep in mind. And remember, nobody gets content model right in one pass. I showed you the SCP content type that I created. It only had three fields earlier, but as and when I was creating and designing my wireframe, I realized I need to put in more and more fields over there to make more sense. So it's fine to have an incomplete content type at first, but get the feedback from your team. Try to think more about it and then create your content type. A few resources that I would like to share with you all, we have a learning center where we have trainings where you can learn more about contentful and content modeling. And we have a developer portal where you can get all the developer resources. So if you just want to get started, developer portal is the best place to go. And thank you all for joining in. And sorry for keeping you waiting. I know it's a break and most of you would like to have a coffee. I surely want to, but thank you all for joining in. Have a nice one.


Harshil Agrawal

JS Nation

JSNation 2022

GPU Accelerating Node.js Web Services and Visualization with RAPIDS

Allan Enemark

Infiltrate Your Own React Native App

This is a headline you don't want to see. As a product owner or as a business, you don't want to. As a developer as well, you don't want to see this headline popping up at the New York Times. This one really did pop up in 2002, 2020, sorry, because Jeff Bezos' iPhone was hacked because there was a vulnerability in WhatsApp. So not on iOS, which you heard multiple times, of course, that are some exploits for iOS itself. But this was only because WhatsApp made an error somewhere. So they were, yeah, Jeff Bezos was infiltrated that way and escalated on iOS multiple times. So every time you make a feature or you create code, of course, there is a chance of a bug. And every bug and feature can also be a potential flaw or potential entry point for bad actors to use, so they can exploit your app, exploit your business. So in research, there was like 75% of apps have bugs in them or features that can be used to infiltrate your app or exploit your business. So for example, the 7-Eleven one was a nice feature what they used to reset your password, which is, of course, an obvious functionality. But they thought, what happens if you change your email? So if you change email all the time, maybe you could just enter another email and reset your password that way. Sounds great, but of course, if somebody new and multiple people new, they reset passwords of other user accounts and then just ordered everything what they could online. So that feature was misused multiple times and like it says here, it cost some money for them as well. Another thing you see online a lot is fake applications. So they use your brand or has your icon if it's really popular, of course, as well to make fake applications, put that in the App Store, for example, iOS or Android doesn't really matter, or Google Play doesn't really matter, and try to lure you in to download your downloading that app and try to escalate privileges. For example, you can ask for the contact permissions for the contact list, although your normal app doesn't do that, the fake app does, and just upload that contact list of yours to their own server and try to do it that way. Another trick is, of course, what they do is try to put advertisements in your application. So they make a copycat application, just one on one, and enter advertisement code in it. So if you open the app, there's advertisements, which you didn't add. So they are profiting off your application as well. You would think that Apple and Google would do a great job of protecting your app, of course, because they have this really neat review process, which everybody loves and hates. But still, there are thousands of fake applications in the App Store right now. Of course, some with great brands, although smaller, which do this all day long. And also there are some app stores, which are not really app stores, but they are fake app stores with correct applications, for example, because some applications are expensive and people try to use them in a free way. So they will go to an app store, which isn't, of course, the Google or the Apple one, and then download the application. And usually there is malicious code in there as well, because they also need to make a profit off you, of course. So in the Fortnite example, for example, Fortnite is, of course, still a popular game, but they made an announcement that they were making the mobile version of it. They made an Android application, which downloaded the real game, let's say, like that. So they made a launcher app. So everybody made a fake launcher app, which downloaded some other app, which, of course, needed the permissions and, of course, tried to inject everything in your mobile device. Another one is, it's not only, they are not only attacking your app, but also your tools you use every day. Of course, most notably, the fake Xcode, as we call it, is one of an example of that. And not only the tools, but also your dependencies. So all the dependencies you have in your application are targeted to get there into your device, so in your MacBook or laptop. And they try to search for, for example, access keys for AWS or some other credentials they want to need, they want you, they want to have, or they just put a crypto miner on your device without you knowing and they profit off you as well. Because these days, the software project has like 203 on average dependencies, I think React, of course, has some more, but that's the average at this time. There are a lot of ways for them, for bad actors to get into the dependencies as well, try to get into the app. Because most notably, of course, they try to do it on your machine as well to exploit that, but they want to exploit the application you are making as well. So again, they will eventually get into, get onto the device, buy your app, and then trying to get that data that they want. I think the British Airways one is one of the most notable here, is they use Modernizr, which is of course a web framework to attack, but they also use it on mobile as well. And what they did is every, they made a keylogger inside of Modernizr and then push that to BA and then every page on BA got that script. So every, also the checkout page, so everything you type in the checkout page was sent to them as well. So of course, all the credit cards, et cetera, details were sent to them and they use that of course to make all the purchases, et cetera. BA got fined for 20 million last year for this hack alone. So it is a really expensive trick that they did on them. So yeah. And of course the other one, also from last year, I guess, was the NPM one, the UiParser one, was that they added a crypto miner for your machine. So if you run that or you added the newest version of that dependency, then of course you got that crypto miner as well. So what can we do about this? First of all, and I think Katie did a great job of saying that as well, know your service loader, so also know the native code of your React Native code. Of course, most people will know the JS code or the TypeScript code as well, but try to understand the other parts for your React Native app is using as well. If you don't, yourself, try to hire someone or contract somebody to see what the code is doing and what it is not doing. So you can assess what attack factors there are in your code. Documentation of course. Again, thanking Katie for the React Native security documentation, which she made for the most of the bunch, which is great. So React Native itself on the website has some security guidelines, so please follow them as well. Google and Apple, for the native side, have great security guidelines as well, so to what to do and what not to do with your data and your security details, etc. Great shout out to Julia, because there should be a YouTube here, but I guess the Internet isn't working great at the moment. Julia is from Cossack Labs, which is a security company from Ukraine, she already has some talks about React Native and security for a few years now. Please watch them, because they are really good at knowing about how React Native works with the native side as well, for the bridge and all the things you need to account to. We have OWASP, which is an open source framework. We have that for web as well, we have the top 10 for OWASP for web. We also have that for mobile, which is shown in the infographic here as well. We have the 10 most used security vulnerabilities that are used in the wild, so they make a top 10 out of them. Take a look at them, see if your app is somewhere in that space and try to improve on that. They also have another project, which is the mobile requirement verification project, which is mainly, of course, there's a lot of documentation, but it also has an Excel sheet with all the things you can check to see if your application is safe. Not only code, but also in process, etc. So it's a very wide approach on how to make your application better. There's a lot of great stuff in there, so please take a look at it. Your dependencies, like I said, dependencies is one of the most used attack factors these days because it's really easy to get into most of the time, not all the time, but most of the time, like with NPM or with other dependencies we use. So know your dependencies. Of course, there's a lot of them, so one by one, it's maybe not undoable, but it takes a lot of time, but it should be the case that you know all of them. If there's an update, always check if it's correct, what the code changes are, etc. And use tooling as well. So there is a lot of tooling online for doing your own penetration test, for example, with the mobile security framework, which is an open source library, which you can run your app, your compiled app against, and it will say like, those are the security things we found in your application. And then you can, of course, improve on that. So you can put that in your CI, for example, as one of the stages. There are also some commercial ones as well. You can use SNIC, which is a sponsor, to use for your dependency checking. It will scan vulnerabilities as well, which is great. It could also be a step in your continuous integration part. And of course, use ESLint, for example, ESLint rules or something else for some other things that can happen in your app. Let's say logic, which can be exploited. So use that as well in your advantage. And of course, for the great part is how easy it is to do. So let's try a demo. I made a React Native application, just a React Native init, and that's it. That's what I did. So that's what you see here. I added JailMonkey, which is from Gantt from InfiniteRat, which is a great library to detect if your device is jailbroken or not, or rooted if you have an Android. And what I did is just make a comparison, like if it's rooted, then just show this text and this image, and if it's not, then the other one. And that's it. So it's a really simple application. I compiled that application for iOS and for Android. You can see that here. And yeah, let's see what we can do about it, with it. So first of all, the IP and the APK is just an archive. So you can just unzip it, and then it will make a nice folder. And then you can see there is a plist, for example, and you can see there are assets, and there's the application itself. That's the binary. And you see here is the code, which is the compiled one, which Metro does. It's just a lot of JavaScript code, which, of course, gets loaded on runtime, and then you have your application. So what does that application look like? Let's install it on my simulator. Yeah. So it says it's a jailed application, because, yeah, I don't think you can even root a simulator on that part. So it's just a jailbroken, or not jailbroken application, it says. So that's fine. Or a device, it says. So that's fine. But can we change that? So in the app, we see, let's see, we see there is a call is jailbroken. Let's see if we can find that in the bundle. Yeah, here it is. This is my piece of code. So this is the comparison which I'm making in the app, which is the compiled one. And then we have this one. This is the function in the library, in the dependency itself. So that's compiled as well in your bundle, of course. And this is just a comparison. So why don't we just make it true all the time? Save it and install it again. And voila, it says it's a jailbroken phone, which doesn't exist, because it's a simulator. So with just looking at the code and searching for it, I just altered your application. It's as simple as that. So of course, the hardest part is now repackaging, you would say, but that's also not that difficult, repackaging an application. And then of course, you can just certify it with your own profile and put it in the app store if you want to. Of course, it hopefully gets rejected by Apple because it's a duplicate, but you could still do it. Or you can put it on another app store and just put it in there. You would say that it is more difficult in native code, but it isn't really difficult. I have a demo version. So if I open the application itself, so the binary, we have the compiler, which is Hopper in this case. There are multiple variants of the same thing, of course, on the web. You must pay for them usually, but for demo purposes, this is great. So it will load the application. And again, I will search for the jailbreak one, which we were searching for. Now there it is. So let's see what it is. A little slow today. Come on. Yeah. So this is a reference, as they call it, to a function. So we're going to go to that reference. Not the structure, but the function itself. And then it says, ah, here's the function. So I can double click on it. And if I do the graph version, then you see that it's a comparison as well. So it will take two stacks. This also, if I go through it, I could go to the end, I guess, and say, like, okay, this is also true or false. So this is, of course, the compiled code. So you need to usually do hexadecimal things as well. But the boolean is really easy, because you can do true or false, of course. And then repackage it, which I cannot do now, because I have an evaluation version of this. So then you can repackage the binary, and you're done again. And it will show the same results as well. So in native code, it's not always that difficult to do as well. On Android, we have the same thing. We have tooling, of course, to open the APK or AAV, depending on what you have. And what you see is that it will show all the classes. If you're Java, you know what those are. All the classes are here. And of course, in the resources, we have the same bundle, which we already saw in the previous example for iOS. And just change it as well and recompile it. So of course, we have done that. It's the same thing. But if we use environment variables, for example, which is done a lot of times, and I look at the environment variables we have here in my app, which is a Google Maps key, well, let's see if we can take that one and search for it in my Android application. So if I search for it, you immediately see that it's there. So open to everyone to see. So of course, the case here is don't put any keys in your environment variables. Just get them from the web or something else. Because like I've shown you here, in a minute, most people can search for it. Of course, you can obfuscate the Android app, which is great with ProGuard. But still, if you know where to look, and also this one will not get re-obfuscated, you can search for the pattern and still find it. So for the last part, let's see if my internet is working. Do we have it? Nope. Well, that's nice. Did I take that into account? Let's see. Sorry for that. I don't have one. I just tried to use my phone. I checked it before. Sorry for that. Let's see if I can do that in a sec. Come on. Let's see if we have internet. Because I wanted to show if you use CodePush, for example, it gets the source from the internet. So also that can be a vulnerability as well. So if I click on this, hopefully, yeah, it says it has an update. Great. So if I look at what it sent over the internet, I'm seeing here that my app is searching for something. So searching for the update. And it says, yeah, I have an update with a download URL. That's nice. What is that download? So if I click on install, it will get that package from the internet and apply the configuration changes. So what if we could redirect that to something like with a middleman attack to something I own? So I'm going to let's see. No, no, that's not correct. No, this one. So I'm going to just say that this URL is going to go to my own device, then serve an HTTPS request, and I need to, because I already applied the update, I need to install the app again, because otherwise it thinks it already has the correct update. So I will install the application. That's the update, which is in here. So it's just a zip file from CodePush, which also has the main bundle and the assets. Let's see if it works. It says, OK, I'm going to install it. And voila, it's a different one, because I just overwrote those as well. So thank you so much. And be safe. Oh, thank you very much, Wouter. We have a few questions from the audience. Are you ready? Yes, I am. All right. Well, first thing, what's the best way for teams to keep each other accountable about security? Like, are there good tools for groups to manage this? Well, that's a good thing. Tools are not, I think, not the case, but more a process. Of course, PRs and code reviews are a thing. So if somebody bumps up, for example, a dependency, always the question should be, did you look at it? Or if somebody makes a change to a functionality, always say, OK, did you check with our checklist of security? That is fine. Tooling should be, of course, automated. So I don't think tooling is the correct word there. But I would definitely have a process in place. Yes, I think processes are tools. That's true as well. Where can we learn more about basic security precautions to take for React Native, for example? Well, I think, like I said, on the React Native website, there was a lot of documentation or Katie made some really great documentation about the few things I've just shown you about how to prevent that. So I would definitely take that into account. Yeah. Nice. And maybe my personal question. Why are you here on the good side helping us not hack apps? Why aren't you out there making money? Because I have a conscience, I guess. It's a really good question, because, of course, you can be a bad actor yourself and exploiting people. And of course, we don't want that. So I guess mainly because I have a conscience and I don't want to be on the bad side and always think about what I've done wrong in my life. So yeah, mainly. Thank you. Both a hero that we deserve and very much need. Thank you very much, Walter. Thank you.


#data