React Summit

React Summit 2023

Speaker's Room: Kadi Kraman

Kadi Kraman

Career Advancement

Rita Castro

Slobodan Stojanović

Giorgio Boa

Christoph Nakazawa

<p>It's safe to say that a lot of websites and apps these days are heavily reliant on images: product images, avatars, social sharing. With continued technological advances, the variety of device sizes you need to support keeps growing. How exactly are we to make the same page look great and feel performant on both a 16'' MacBook Pro with a retina display as well as a small 5 year old Android phone? We will look at some of the modern approaches to tackle just this problem on web and native - as well as what happens if you don't.</p>

Optimising Images in Web and Native

GraphQL Galaxy

GraphQL Galaxy 2022

<p><span>Requirements change, but API contracts are forever - I wish! A breaking change is something that is not backwards compatible. This means that a consumer of your API would not be able to use the new version without making a code change themselves. We avoid breaking changes if possible, but there are cases when they are inevitable. It could be something small: like making a mandatory field optional. Or it could be something big: like removing a query or a mutation. In this talk we'll review the types of breaking changes you may encounter and how to deal with them gracefully.</span></p>

Handling Breaking Changes in GraphQL

Hello everyone, it is a pleasure to be here and it is a pleasure to talk about something that is very relevant to my work, which is handling breaking changes in a GraphQL schema. So just a quick intro about me. My name is Kadi Kraman. I'm currently the director of mobile development at Formidable. If you've not heard of us, Formidable is a consultancy. We build websites, mobile apps, and of course, GraphQL APIs. In my five years in this company, I think almost every single project had a GraphQL API in it. So we've been doing this quite a bit. As for me, my first GraphQL API I built was around 2017. And since then, I worked with both small and large applications and mostly as an API consumer. So because I build a lot of mobile applications, usually I've been the client of a GraphQL API. I would spend maybe 20% of my time writing GraphQL and 80% of my time using GraphQL APIs. So breaking changes is something that's very relevant to me because I'm the client that gets affected if breaking changes happen. So what is a breaking change? A breaking change in a GraphQL schema is basically an update that causes the API contract to change in a way that is not backwards compatible. Now, what does this actually mean? I'm going to show you using a code example. So here we have a little schema. We have a query where you can query a user by an ID. It will return you a user type. And the user type has just the ID and the name in it. Both of them are mandatory fields. And if we look at what a query would look like, so here on the right, we're going to query the user by ID. We query the ID and the name, and we get exactly that data back. So say that you had this user type in your current project, and the client comes back to you and says, hey, we don't want to have our name as a single string. We want to have the first name and the last name separately. So as a new requirement, you need to separate the name field into first name and last name. So how would you go about it? You would be tempted to do something like this. So here we've added the first name and last name, which are both mandatory strings. But then, because we really don't use the name anymore, we can remove the name field. Now, this seems all well and good from the schema side, from the API side. But when we look at the client side and query the same query that we did before, we are actually met with an error. And the error says, cannot query field name on type user. And indeed, the name field no longer exists. Now, this is an example of a breaking change, a change that is not backwards compatible because a query that worked on the previous version of this API no longer works because of this change. Look at how we would make this change backwards compatible. It's actually surprisingly simple. Instead of deleting the field, we can add a deprecation notice using the deprecated directive. So you've seen next to the name field, I've added deprecated and also provided a reason. So in this case, it's deprecated in favor of first name and last name. And here we can see that the previous query that queried just the ID and name still works. And the new query that queries the first name and last name still works. Therefore, because both the previous and new queries work, this is a change that is backwards compatible. The deprecated directive is really handy. It's basically, it allows you to tag a field in a schema as a deprecated field to communicate to your consumers that this field should no longer be used. It is part of the GraphQL spec, which means that most GraphQL servers should be implementing it. And the most important part, most IDEs, GraphQL tools and clients that you might be using will pick up this notification and warn you if you're using a deprecated field. Here I've added an example. So this is from Insomnia, which is a GraphQL client that I use for querying. And when I look at the schema and the user type in particular, we can see that the name now has an exclamation mark next to it. And if I hover over it, it's telling me that the field name is now deprecated. And it's also giving me the deprecation message that I wrote. So it's deprecated in favor of first name and last name. Now there might be a reason, however rarely, that you'd simply have to introduce a breaking API change. So I'm going to show you a way that you could introduce a breaking API change in a GraphQL API relatively safely. The key words you need to remember are add, deprecate, migrate, remove. Unfortunately, not a very good acronym. Let's go through these one by one to show you what each step means. So this is our starting state. We're going to start with this user type that we used before, just with the ID and a name. And this is our application stack. So we're going to have a website. Let's say that's an XJS app. We're going to have an API. It's of course a GraphQL API. And because I build mobile apps, we're going to have a React Native app for iOS and Android in a third repository. So all three of these are in separate repositories, and they are deployed separately. And the first version of these, web1, API1, and app1, all implement the user type as seen here. Now, the first stage, add, is pretty straightforward. We're going to add the schema fields that need to be added. In this case, we're going to add the first name and last name to the user type. The next stage, deprecate, you would usually do it together with add. But in this one, we're going to deprecate any fields we might want to remove in the future. After we've added the deprecated directive, we'll use the deprecated directive to add a deprecation notice to the name field in the user type. Now, when we're finished with all of our changes, we will release a new version of the GraphQL API to API2. Now, API2 is still compatible with app1 and web1, which means this is a backwards compatible change. The next step is the migration step. Now, in this step, you have to go through all of the clients, everything that's using your GraphQL API, and update them to use the new API. Then we'll go to the website and the app. We'll do the change, and we'll publish the new versions and ensure all of our users are using them. Now, when you're confident that no one is using web1 and app1 anymore, you've published web2 and app2, then it might be safe to remove the field. So here, we can remove the name field that was deprecated from the user type, and when we're finished, we will deploy the new version of the API to API3. Now, API3 is not compatible with web1 and app1. They will still get an error, but if no one is using them, you already published the change, they'll be using web2 and app2, then that is a fine deletion to make. Now, because I build mobile apps, I wouldn't be a mobile app developer if at this point I didn't go on a tangent on why this is so much harder on mobile applications. On a high level, this is what deploying websites and APIs looks like. You've finished your version 1, you're going to upload it to wherever you release it, say AWS, it will become available to users, and 100% of your users are going to use it. Now, when it comes to releasing v2, when you finish coding it, you're going to upload it to AWS, you're going to make it available, and instantly, all of your users are going to switch over, and 100% of your users will be using v2, and no one will be using v1, and such. When you finish with v3, you will release it, 100% of your users will immediately be switching over. Now, this seems pretty obvious, but the fact is, this isn't at all how it works for mobile applications. This is what deploying a mobile app looks like. When we finish our v1, we're going to upload it to the stores, we're going to get an approval, and when we've got the approval, we can publish it to the App and Play Store. Because it's the first ever version of our app, 100% of the users are going to be using it. Next, when we're ready for v2, we're going to release it to our stores, we're going to get it approved, we're going to release it to our stores. It actually takes time, so we're going to go away for two weeks, we're going to look at the stats after two weeks, and we'll see that maybe 60% of the users will be using it, and 40% of the users are still using v1. And when we do another version, v3, we get it approved, we release it to the stores, we go away and come back after two weeks, we'll find that maybe 65% of the users are using it, 30% of the users are still on v2, and 5% of the users are still on v1. Now, the sad truth is that mobile app releases never get 100% adoption, like websites do. And the reason for that is apps only get updated if the user either has automatic updates turned on, or if they go to the store listing page and update manually. Even if the user has automatic updates turned on, the update wouldn't be instant, as soon as the app is available, it will get updated. Instead, usually it will get updated once you plug in your phone and you're connected to the Wi-Fi. So there might be a huge delay between when you publish the app and the users, even those who are first in line, actually get it. Knowing that, you might be asking, when is it safe to make a breaking API change if it's used by a mobile application? Well, the truth that you don't want to hear is that it's actually never safe to make such a breaking change, because you will always affect someone. It is impossible to get 100% of your users onto your latest version. But what if I really, really, really have to? Well, there are ways to make this upgrade as safe as possible. Usually in mobile apps, we build in, so this is something that you would have to build in as a developer, we would build in a failsafe, which basically is a prompt that would prompt users to upgrade if they want to continue using the app. Generally, most apps have it built in, but it is a last resort. We don't want to use it. It should never be part of your normal development flow, because it's terrible UX and users hate it. And to be honest, Apple also hates it. And we don't want to piss off Apple. As I was actually working on this talk, one of the apps that I use regularly had this app upgrade prompt. So I've added it here as an example. Basically, when I update the app, so when I open the app, I will immediately get a native alert that says, this version is deprecated, please go to the store to upgrade it. So if I press on learn more, it will take me to the app store, where it will prompt me to upgrade. I've actually seen they did a complete revamp of the whole application. I think they rewrote it. So presumably the previous version is no longer compatible. Now even when you get to this point, and you've prevented users from using the old version of the app, you technically can't even then be sure that they're going to upgrade. Because at this point, I can choose to not press the update button on the app store, because maybe I'm not on Wi-Fi, I don't want to use my mobile data. And also I can just decide that this annoys me, and I'm going to use this app on the website instead, or not use it at all. And once you've done everything you can to make sure that users will update, then you just need to monitor that they are doing so. You'll do this in two levels. One is on the API side, and one is on the app side. So on the API side, this will be maybe in AWS or in CoreLogix, you can generate metrics to monitor query usage. So you would generate a metric to monitor the usage of deprecated fields, and you'll see whether or not they get called or not. And then on the other side, you can also monitor your app's active users for each app version to kind of get an idea of the number of users still using app versions that are deprecated, and that have this breaking change, and how many users this breaking change could affect. And one thing to note is that having breaking API changes generally is much more significant for mobile app users and developers than it is for web users and developers. Because on the website, if your website goes down or it doesn't work, then usually your users could tweet at you, they could maybe email your customer service angrily. Whereas if an app is broken, if the API doesn't work, then users have a very nice and convenient way to complain about it, and they will do it in a store listing page and give you a one-star rating because of a single line change where your API didn't work. Getting away from that dreary topic, let's play a little game. Which one of these is a breaking change? So we've got the user type with the ID and a name, and on one side, I've made the name from mandatory to optional, and on the other side, I've made it from optional to mandatory. Did you say the first one? Indeed, in a GraphQL schema, if you have a field that is mandatory, and then you change it to be optional, that is a breaking change. And why is that? Well, it might not be very easy to see it from the schema, but it will be a little bit simpler to see as a code example. So here is, I've used TypeScript just to make it a little bit more obvious, and on the left, we have some code that you might have on the front end that uses this API. So because our user only has an ID and a name, I might have a utility function that uses the name and takes the first part of it as the first name. Now after I've done the change, so I've made the name from mandatory to optional, so it might return null. Actually, TypeScript is helping me out and telling me that I can't split on the user's name because it might be null. And indeed, if at any point the user name returns null, I would get the JavaScript error calling this function. Let's do one more. In this case, I've got the user query, and I'm changing the user ID that I'm querying it by from mandatory to optional or optional to mandatory. Did you say the second one? Yes, the second change is breaking, and it can be confusing because it's the opposite for query inputs because here, changing the user ID from optional to mandatory is breaking, not the other way around. I've used the diffs here on purpose so you can see that as a reviewer, it is actually really easy to miss these kinds of changes. Thankfully, there is a tool to help you. If you haven't checked it out yet, I would definitely recommend looking at GraphQL Inspector. We're currently using it on my project, and it's made a huge difference. It does a bunch of things, but the most important thing for us is that it allows us to have a check on pull requests, which will tell us if a breaking API change will be introduced. You can use this on any kind of CI. We use GitHub Actions, so I'm going to show that as an example. Here, what we're configuring is that it's going to compare the GraphQL schema in the current pull request to the GraphQL schema in your current working branch. This is what it looks like on the actual pull request. On the left, we're going to see an example of a breaking change. We have it set to fail CI if there's a breaking change, and you can see the two types are being removed. Removing types is always breaking change, and therefore, this gets highlighted. The other cool thing is actually on the right, we can see some examples of just information notices. These are not errors or warnings, just for information. What the GraphQL Inspector does is that it highlights any changes. This will draw the attention of the reviewer to what's actually changed. This is really important because you have to be quite aware of what you're actually adding to your GraphQL API, because as you can see on the other side, removing anything is always a breaking change. Once you add it, removing it could be a FAF. Because we've enabled fail on breaking, there's another thing that we've added, which is to have an approved label. You can set your own label for an approved breaking change. You can call us whatever we want, but this is us. Basically, if you add this label to a pull request, then even if it had a breaking change, it will allow the CI to pass. This is really useful because basically, as a pull request gets introduced, a reviewer will go through it, and they will have to... They get highlighted that there is a breaking change, and a conversation needs to happen whether this is a change that we're happy to have in, is there another way to do it, and should we avoid it altogether. In summary, we looked at what is a breaking schema change. This is renaming a field, deleting a field, changing the data type, making a required field optional, or making an optional input required. In general, you should avoid making breaking changes as much as possible, especially if your API is being used by a mobile application or any kind of desktop application that doesn't have the same kind of published workflow as websites and APIs. But if you do need to introduce a breaking change, you can use the add, deprecate, migrate, remove step to minimize the amount of users you're going to affect. Finally, if you haven't yet, I would very much recommend you check out GraphQL Inspector to improve your GraphQL API workflows. Thank you very much. I hope you've learned something about breaking changes in GraphQL.


React Summit 2022

<p>React Native can be much more than a toolkit for building mobile UIs in JavaScript. We’ll explore how to use features beyond the core library, and use the built-in native module system to integrate AR capabilities into your mobile app.</p><p> by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a></p>

Exploring AR Try-On with React Native

Wow, hello. Thank you all for coming. I'm really excited to be here today, and I'm going to be talking about exploring AR try-on with React Native. So, here's the mandatory intro slide. Hi, my name is Kadi. As Jani said, amongst his very kind words, I'm currently the head of mobile development at Formidable. I've been an engineer for about ten years, but for the past five years, since 2017, I've been building things in React Native. I've been very fortunate to be able to work on some really exciting projects in React Native, and I'm very excited to share one of them with you today. So, in this talk, it's going to be in two parts. So, first, we're going to talk in general about what's happening in the AR VR space, and in the second part, I'm going to go through a bit of a case study of how we actually implemented a virtual try-on feature in a React Native application. So, to kick us off, what's currently happening in the AR and VR space? So, I will do a quick clarification on the difference between AR and VR, because we tend to use those terms together. VR stands for virtual reality, and it is a fully simulated experience, so it may look like the real world, or it may look completely different. So, the distinguishing feature in a VR experience is that you will have some sort of a VR headset, so it will be an Oculus, or a Google Cardboard, or an Index VR, but the point is you need to wear something in order to have this immersive experience. An example of that is, for example, Beat Saber, which you will see on the screen. AR stands for augmented reality, and it is a process in which the real world is enhanced by some computer-aided graphics. So, usually, for an AR experience, you will be looking through a screen, so it could be your phone screen, it could be your laptop screen that has a camera that's recording the real world, and then your device will add some kind of computer-aided enhancements. So, for example, you could use it to place furniture in your space. If you've followed the news recently, you might have seen that last week there was a news story making rounds that Amazon has launched an AR-powered virtual shoe try-on experience in their iOS app. Now, this in itself is not particularly groundbreaking. Amazon are not, like, they're nowhere near the first, and they're not going to be the last company that launches something like that. But the reason that I found it significant is that it's speaking to us of a trend that is happening more and more, which is that in e-commerce, AR is going to stop being a gimmick, it's not stopping the cool thing that maybe 5 per cent of the people would use, and it's more and more starting to be an expected part of our shopping experience. And just to give you a couple of examples of myself using AR in my shopping experience, so these were a couple of things that I used before I even knew that I was going to be giving this talk. So, Bailey Nelson is a company that sells glasses, and I like their glasses quite a lot, and on their website, they have an AR try-on where you can try on glasses before you purchase them. I actually got this pair, so that was very pleasant. Another thing, so Gucci have an app that's just for experience features. They have a couple of different AR features. They have a shoe try-on, they have a make-up try-on, and in this example, you can also try on different nail polishes. I recently moved house, well, I say recently, it was the beginning of the year, and it was my first time moving into a completely unfurnished house. It was my first time moving into, sorry, I can hear some echo. It was my first time moving into a completely unfurnished house, so I needed to furnish it from scratch. Here was me trying to figure out how to place a sofa into my very weirdly-sleeping living room. As you can see, that corner sofa was wishful thinking. I did end up going with a smaller version of this two-seater sofa. Now you might be wondering how do I do this in React Native? Well, with everything in React Native, we're going to start by looking at the underlying platforms. Both iOS and Android provide an AR platform. In iOS, it's called ARKit. It was launched in 2017, and it's available from iOS 11 onwards. Android, not to be far behind, launched the equivalent on the Android platform, it's called ARCore, and it was launched in 2018, and it's supported on Android 7 and onwards. As ever with React Native, someone somewhere has written the React Native bridge for the native libraries, and in this case, it's called Duvero, which builds the bridge for ARKit and ARCore. It's an open source library. I think they've moved it into the community space now. They're not actively maintaining it. If you want to try out AR in React Native with no native code for yourself to write, then this would be a good place to start. Now, let's look at how we actually implemented a virtual try-on experience in a real-world React Native app. As always, let's start with the requirements. So, what our client needed was an AR shoe try-on experience. So, we are in the e-commerce space, we are selling shoes, amongst other things, and on our product details page, we want the users to be able to try the shoe before they purchase it, and hopefully improve conversion. They wanted this to be part of the main shopping app, so some companies have made the decision to have a separate app specifically for experience features, so Gucci is an example of that, but for this client, they wanted it to be part of the application that all the users will have, regardless of whether they actually use the AR feature. They also wanted this to be a bespoke UI, so the UI was designed way before we even got to finding a provider or building any of the code. And in terms of resources, we had in the order of weeks rather than months or years to build this, meaning that it's unlikely that we will be able to start completely from scratch. So based on these requirements, we found the solution that will work for us. So, because it's part of the main shopping app, the bundle size and the API level matter, so we can't add anything that will add hundreds of megabytes of space because every single user will have to download this app regardless of whether they use the feature. Also, with the API level, we need to make sure that our minimum API level is as low as possible, again, to make sure that the most amount of users are able to install this app. And finally, because we have weeks and not months to build it, our only real option is to use an off-the-shelf solution for the native platform and build the React Native integration with it. And just as a side note at this point, to really take your React Native engineering to the next level, I very much recommend that you start learning native code. So, if you're someone that came from the web, like me, you might find and your first experience with iOS development was a bit of Objective C. Sorry. Yeah. A bit of Objective C. You might find it terrifying. What are all these brackets? However, on iOS, you can use Swift, and on Android, you can use Kotlin, and both of these languages are much more lightweight, they're much more functional, and much more easier to grasp from a JavaScript developer. And once you get more acquainted with the native platform, native languages, it will really enhance the amount of features you're able to add to your React Native application because it opens the door of being able to install native only SDKs and write your own bindings comfortably. So, for our AR try-on, we looked at two different companies. The first company that we had used is called Wana. They are a company that specializes in virtual try-on. So, they have an SDK where they've implemented a virtual try-on experience for shoes, and you can use their SDK to basically build your own integration. You can actually try this out yourself. So, this is their example app, which is available on both the iOS and Android stores. So, this is an app that uses their own SDK, and you can see what the try-on experience would look like. So, from an implementation point of view, we got in touch with them. They sent us a demo SDK so we could have a look at integrating it and seeing what it would look like in our app. So, here are some screenshots of when we built the integration. This was obviously a proof of concept, so the UI isn't nothing to write home about. But in general, the API itself was pretty straightforward. There wasn't a huge amount of native code that we had to write in order to build the integration. It was fully customizable, so we were able to just render the virtual try-on video and then do everything else in JavaScript. The thing that was kind of a deal-breaker for us is that it had quite higher minimum API levels than what we were aiming for. So, it requires Android API 26, whereas we were at 24, and it requires iOS 13, whereas we were at 11. Now, this is a trade-off for some clients, for some customers, for some use cases. This doesn't matter, and you can just aim for higher APIs. But in our use case, our client was quite sensitive to make sure that no one gets missed out because of their older API levels, so we didn't want to upgrade. Did you know that Snap, the company that builds Snapchat, has a developer portal, and you can use a lot of their AR technology in your own application? You can check out developers.snap.com. They actually do more than just AR try-on, but the point is that they provide a couple of libraries, most notably for us, a library called CameraKit, which is basically the SDK that powers Snap itself. It does a lot more than just virtual try-on for shoes. It does makeup, it does clothes, it does front camera, back camera, everything you see in Snap, so it's very, very powerful. And under certain circumstances, you can use it in your own application. And something new that they've recently built to enhance it that's currently in beta is the AR Shopping Extension. So, this is something that Snap is providing. It's alongside their CameraKit, and it's specifically built to create an integrated experience for AR on the e-commerce product details page, so within the shopping experience. And using the Snap's SDK, this is what we ended up with. So, starting from the left, we have the product details page with the AR badge on the products that have an AR. Then we have the product details page with the AR badge, and finally on the right, we have the module with the actual AR experience. I realize this is a technical talk and I haven't written, I haven't shown you any code, which is basically a crime, so I've added some code. I'm not going to show you the native side of things, so I'm just going to show you what we actually import and use on the JavaScript side. So, on the product listing page, we have these AR badges, and what we need to know from the Snap SDKs, which is the source of truth on whether something has an AR experience, we pass in the product IDs, and it does its magic and tells us whether or not this product has an AR experience. If it does, we'll show the AR badge. We use the exact same method here on the product details page. And this is the interesting part. This is the actual AR experience. Being the React native developers we are, we made the conscious choice to have as much of the code as possible on the React native side. So, the attribution, the product name, the camera button, and the variant picker, these are all rendered using React native. So, the only thing actually rendered natively using Snap SDK is the actual camera experience. So, the way that we've exposed this is as a native component. And the way it works under the scene is that we pass in the product ID to this native component. Then using the Snap SDK, we fetch the products. So, this is from the shop kit. We fetch the products for that variant. Then we call the on products load at callback, which will then populate the products underneath the screen. Then next, what the SDK does is it fetches the lens for the selected product. So, a lens is kind of a Snap terminology, but it's basically the virtual reality experience with something inside. In this case, the pair of shoes. And then when the lens is fetched, we're going to call on lens loaded callback, which will then tell us that it's time to stop the loading spinner and the user is good to go. And let's look at this experience end to end. So, here I'm on a product details page. I'm gonna scroll down to the launch AR. So, in this case, this is the first time we're launching it. So, we have to say yes to camera, agree to terms, which we've definitely read. So, here we can also look at the 3D model of the shoe, which is actually built into the lens, which is pretty cool. So, you can change colors and see what it looks like from either side as if you were holding it. And then if you swap to the AR experience, obviously, you can look down and you can see the shoes on your feet, on your friend's feet. You can also mix and match and show one of your feet, one of your foot to one of your friend's foot. That works as well. And finally, you can take a picture and share it with your friends. So, in summary, the snap SDK, I will say that there was quite a lot of native code that we had to write. So, the previous slide that I wrote about embrace native code, it was there for a reason. I definitely had to embrace the native code for this project. But on the upside, they did provide us with a fully working example app. So, obviously, the UI didn't look like anything like us, anything like us. We had to change things quite a bit and build it from scratch, but it was a really nice help to get started. On the upside, it was a very, very smooth experience. You can really tell that this is an SDK that is powering a really powerful app, the Snapchat app itself. They've had lots of engineers and years and years of practice of making this as smooth and as nice as possible. So, it was a very nice end experience with kind of a minimal effort on our part. And very importantly for us, it works from Android API 24 and iOS 11 onwards. So, in summary, in this talk, the three main things I talked about was Vero, which is the React Native bridge for AI if you just want to try it, try out AI in React Native. And then for virtual trial in particular, we talked about Wana and we talked about Snap for developers. So, if you're interested in either of these things, I would definitely check them out. And just a shout out to Formidable, the company I work for, thanks to whom I am here, who are also with you lots of open source. Check us out at formidable.com. Thank you very much. Thank you so much. Oh, hello. Thank you so much, Catty. Now, we're going to do a brief Q&A. We're a little behind schedule, so we're going to keep this in with a few minutes. And then if you have more questions for Catty, you can find her at the speaker Q&A booth afterwards. So, the first question from the audience is, how did you get the 3D model for the shoes that you're selling? That is a great question. Actually, so there is another company called Vertibray that we work with and they are the ones that actually, well, they get shoes shipped to them, they take the 3D model of the shoe and then they work with Snap to get it integrated. So, could anybody just go and get their shoes modeled or is this like a sort of like an enterprise deal type of situation? I think this particular one is an enterprise deal type of situation, but I'm sure there are ways to do it as an individual person as well. I think the easiest way to actually do it would be to create a 3D model in like some kind of 3D modeling software and use that rather than the real shoe. That's cool. And by the way, I think we do have a talk about that. Sarah is talking about, Sarah Viera is talking about modeling in Blender later. So, that might be a good time. Perfect. I have a question for you. This is not from Slido, but you were given a brief to do this within a few weeks or within the timeline of weeks. That sounds scary and difficult. How did that actually go in the end? I think there was always, I think people tend to figure out things based on the time frames that we have. I think if we were told that we had two years to build this, we would have probably started from a much lower level and we're like, yes, we're going to build our own custom AR solution. But knowing that we had a couple of weeks, then that made that option go out the door straight away. So, we were like, okay, we need to find the best SDK, best tool for this job. Nice. Thank you. So now, if you do have more questions for Kati, that was all that we have in Slido. So, feel free to go and talk to Kati in the speaker Q&A booth. We're going to be moving on to our next talk. Thanks so much, Kati. Once more for Kati Krammer.


React Finland

React Finland 2021

<p><span>Quick tips on how to utilise the native mobile platform to help provide your users an upgraded experience with sounds, vibrations and animations. Small changes can have a huge difference UX-wise.</span></p><p>  <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a></p>

Haptics, Sounds and Micro Animations

GraphQL Galaxy 2020

<div><div><div><div><div><p>Let’s explore how the urql GraphQL client came to be and what makes it stand out. We will explore how various challenges were solved in new ways from first principles. Expect a look at future standard features such as Offline Support, an overview of small design choices that are baked into urql, and some features that are already standard and have first-party support such as authentication and file upload.</p></div></div></div></div></div><div><div><div></div></div></div><p>  <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a></p>