Hello friends! Welcome to this month's edition of Wrap Up! Many of you all know this is a series where last Christmas I wrapped up all of the 2021 releases that I hadn't read yet and every month I unwrap and read one of them in these vlogs. So I am going on holiday in five days. When you're seeing this I'll just be back from holiday. So I am filming a lot of videos and editing a lot of videos in these five days. So I don't want a difficult book. I want a book that's very easy to get through. I've got a few points where I am going to read like in the evenings. I've got some reading sprints for my patrons. It's like I'm not going to be doing no reading but I don't want a long book. Does that sound like something you want? It is. Well let me tell you you'll never get it. So I think we're going to do the thing again where we unwrap two and I pick one of them to read on this. I really want to read the first one. I don't know what to open. Okay okay we're going to go for this one. Let's go for this first. Looks like a fairly short hardback. She'll stick. Oh my god. Okay that's The Perishing by Natasha Dionne. I'm actually all going to count this as one of the two because I'm reading this next month and I forgot to unwrap it. So we're not even going to count this. I should have unwrapped this before for this video because I'm reading this for a different video. So we're not even we're not counting that as one of the two. Let's go again. The rules don't apply. I'm going to go for this one. This is the one I initially thought about. Okay this one is everything we don't say which is a thriller I got from Book of the Month. Our main characters, neighbors were brutally murdered right outside her barn and her younger brother became the prime suspect. It's got a true crime podcaster. It sounds interesting but I think I'm going to unwrap one more just to see if I would rather read the other book. Let's do a paperback I guess. Let's go for this wherever this is and we will pick one of them. Oh okay I think I'm going to read this. So this is Love and Other Natural Disasters by Misa Seguria. This is a like contemporary romance book that I have wanted to read for ages. It was obviously an arc I got sent. It's been on like lists that I've reacted to. It was like oh my god I'm so excited to read this. I have the audiobook for on script. I think I have the audiobook for this as well though to be fair but I think this will be an easier book to get through and when I'm like stressed this week and I have a lot of work to do I think this will be a better pick because it will just be super easy and light to pick up. I really liked this time will be different by Misa Seguria. So yeah we're going to read this. I feel like this is exactly the vibe for this week. Right. I am 100 pages into Love and Other Natural Disasters. I firstly want to say actually no should I give you that? Tell you what they tell me. Okay I'm feeling weird right now. I'm feeling like so weird. Let me give you the plot first.  She's a very interesting main character and like narrative voice. I don't want to say socially awkward but she's like you know when she likes a girl she'll be very like awkward around her not knowing what to say and overthinking everything and getting nervous. I think that's a really like human reaction and it's like funny. I guess some people could find this narrator annoying. I feel like it hasn't had the best reviews. I've actually had a little look on Goodreads but I really like her because I feel like she's real and she she's so real. She's so real. She's a different main character than what I've read in a lot of like YA contemporary romance. I feel like a lot of main characters think they're awkward but they're not whereas she is. Anyway she falls for this girl in San Francisco and they start fake dating to make because the other girl was just broken up with her girlfriend so they start fake dating to make her jealous and Nuzomi's just like oh my god I love her so much I'll do anything for her kind of thing and first theme I want to say this is the perfect thing for me to be reading right now. This is exactly what I need to read. I have to finish six videos in the next five days you know six videos need to edit. I've done one so I'm not gonna have a lot of time for reading and I have the audiobook for this and it's just a very enjoyable read that I don't need to think too much about that is very easy to pick up and pick down. I have no doubt I'm gonna finish reading this in time and just for it to be really enjoyable. I don't think it's gonna be a five star this time will be different. I think I gave four stars and it feels again like a nice palette cleanser, a nice book to kind of get me back into reading without thinking about it too much. So I'm really really enjoying it for that purpose. I think it's the perfect book for me to read this week and like that hasn't been happening to me a lot lately. I feel like I've been reading books and quite not quite the right time. You know what I mean? Like a book I'd really enjoy but I just felt like I mean I'm not a mood reader so this hasn't happened to me a lot in the past and I don't want to see any comments saying don't be a mood reader. Mood read for a week. I know they're all like the best best of meanings and hearts and I know you're all gonna be lovely. Mood reading that's a living nightmare for me. I just can't do it right but there's been a few times where I've thought this just isn't quite the right time to read this book but I have to read it for a video. This feels like literally I could not have read this at a more perfect time. This is exactly what I need right now. Like I said I really like the main character. Oh this is in the back delightfully disastrous. That is what I would call her. Like she's like a bit of a walking mess but it's fun.  I've always had a bit of an issue, not an issue, like not like a moral issue but like I haven't loved many fake datings in the past but I just think it's kind of sweet in this one how she like just wants to be loved and wants to have that relationship. So yeah there's some interesting family dynamics in it as well.  So I am doing reading sprints again. I think in my last vlog I was like here doing reading sprints. I'm doing them Riley and her patrons and my patrons today so I'm just gonna go back to the live and carry on reading. It's essentially the plan. 200 pages, no 220 pages. I've read that much, got a much left of the book and I'm just enjoying it. Like what do you want me to say? It's such just like a fun way I read. I am so busy this week I could not have handled anything more than this. Like this is the limit. So this is basically a love quadrangle. I think it's the first time I've ever read a love quadrangle. I don't think I've ever read that before. So Nozomi is fake dating a girl called Willow who has just broke up with her girlfriend Anden who is dating Dayla. So yeah. Nozomi is hoping that by fake dating Willow Willow will actually fall in love with her. Now I've just figured out where this is going. I actually I'd figured it out maybe like 30, 40 pages ago but now it was just confirmed for me where it's going and you know what I don't mind it. I don't mind it. She's being a bit sneaky, Miss Misa Seguria. She says let me just sneak something by her. I just think it's an enjoyable YA romance. There's a lot of discussions in this about queerness and acceptance and particularly the intersection of race and queerness.  Nozomi's uncle is gay, is married to another man and her grandmother kind of doesn't recognise that. And so Nozomi's really worried about coming out to her grandmother and what her grandma would think of her but her grandmother is struggling with dementia and that is a really big part of the book. That's kind of like the second storyline to the romance and kind of her thinking about how it's fair to view her grandmother and how she should have a relationship with her going forward when she still loves aspects of her but she finds her homophobia really really difficult to deal with and I don't know I've found that section again it's not something I've really read before and I just really appreciate it. I think it's great to have in a YA book. I've read a few reviews, a lot of people find Nozomi annoying but I don't. She's just a lot, like she's full on right? She's like a very dramatic character. She has big feelings is how I describe it. She feels everything very strongly. She feels like when she's upset about something for example her parents divorce it's something that she can get stuck on when she wants to be in love so badly like she feels that so strongly and will do anything for that to happen so you know just because a character isn't neat and tidy for you you know just because the main character isn't simple you know in her actions doesn't mean it's bad. I think she's refreshing. I do think however if I were to just read this physically she could get on my nerves. I think the audiobook narrator does a really good job of bringing her to life and kind of bringing her feelings to life so I think if I were to recommend this I would recommend the audiobook that's primarily how I'm reading it. I could see how she'd be annoying if I just read it physically but yeah I'm really really enjoying it still. I think it's really really fun. I'm excited. I'm gonna start packing for my holiday tonight so I'm just gonna listen to the audiobook whilst I pack so I hopefully should finish it tonight just through that but um yeah I'm really really enjoying it so far. My whole life is packed up so I don't think you can see anything. You can see some random to my packing list. I loved this. Well I didn't love it. That's an exaggeration. It was four stars but I did tell a bit of a lie there. Like I said it was perfect for the moment. If you're craving just like a light YA romcom I would recommend this. I really really enjoyed it. Listen YA romcoms I don't know if I'm ever gonna be out here giving that like five stars. The only one I've ever given five stars was Fact Chance Charlie Vega. I did enjoy that one. This was just fine. Like it was good. There was nothing wrong with it. I really really enjoyed the reading experience of it. If I'm distracted I am so stressed about the fact that I forgot I have to take the thumbnail for this and like I can't take it where I usually take it because of all the mess that's in my room. I don't know what I'm gonna do and the thing is this video we'll talk about the book in a sec. This video is going up the day after I get back for the cruise so I'll get back like Saturday afternoon but on the sundance it's going up. I'm going to Yauk for one day which is YA literature convention here in the UK and part of it's like should I leave it to Saturday afternoon? When I know I shouldn't I'm just gonna take a different kind of thumbnail. Something nice and quick. Nice and quick for the girlies but yeah I think this book has really good. I mean the Love Quadrangle works really really well. It's very believable. I really liked Mizomi as a main character. I know she's like Marmite but I really really liked her. I also think there's a good slow build in this book. I mean Mizomi falls hard and falls fast. She's actually like oh but I think in terms of the other characters around her in this quadrangle there's a good build up of like relationships and slow burns of romances and stuff. Mizomi's like instance. She's like oh yeah I love this person now. Yeah we're in love. Whereas the other ones it's much slower I think to kind of counteract her.  She's like oh my god there's like many other you know. Her coming to terms with that and Mizomi coming to terms with what that means their relationship. Her parents also had a divorce and she's very mad at her mother for that and so it's her trying to come to terms with that and trying to forgive her mother. I think this has so much good queer rep but particularly queer rep for people of colour, for young girls of colour, for young lesbians. I think it's such good rep and yeah this is two romcoms now that I've given four stars by this author so I feel like she's a safe bet for me to read all her new releases just as kind of like palette cleansers you know. I really enjoyed how it subverted tropes like how it subverted fake dating or like all these different tropes that you get in like movies or whatever like old school movies. I really like how it kind of twisted them and turned them on its head so it was the perfect thing for me to read this week whilst I tried not to go crazy and now I have to take the freaking thumbnail and I don't know how I'm gonna do it but thank you for watching the vlog. I hope you enjoyed it. If you got onto the end of the video comment just a heart emoji because it's about love. Oh my god we're so in love. Yeah comment a heart emoji down below if you got into the end thank you thank you so much for watching and I will see you very soon in another video. Bye!


Oh dear. That would be horrible. My planet needs me. Are you nervous yet? What's the gig going? It's so much better sitting down. It's like informal. I know. All eyes are on there anyway. I know. That's why I've never understood why they record. I've seen that too. It's like you're just trying to set something up for the material. Are we going back? Do we have to hit a record button? Did they say anything about it? You're being recorded for speaking to Mike. Oh, I'm not sure he just said it. Pretty good turnout. The doors closed. Is that what we do? Yeah. What would the assistant be like to tell us that? To start. 1045. Except for when I'm not. That's true. All right guys. We're going to get started. If you guys have any questions, feel free to stop. It's in the middle or you can wait till the end. We've got a lot of stuff to cover, but we definitely want to leave time for any questions, any further explanations of the topics we're covering. It's a lot of stuff. But yeah, we can definitely make time for any questions. And if we can't get any questions, just hit us up after the session. Hello. Steve, can you go first? Yeah, sure. So I'm Steve Woley. I'm from Australia. I work with Aquia as a technical consultant. I've been here for the past two years. My day-to-day is kind of like running around, working out business requirements and mapping them to Drupal functionality and doing that kind of stuff. So it's quite challenging. It's quite interesting, quite rewarding. I wanted to talk to a bit of a story about past projects that I've had that's kind of led me down the decoupled space. So at my previous job, I was working with a large travel company. Then we managed around 80 different brands. And each brand had around 200,000 products that we were syncing between each site. So it worked out to being around 16 million database records across all of our sites. And most of that was duplicated content. And that doesn't really make sense to me. So I started looking at a way that we could centralize that data and then expose it via APIs to all of those 80 sites. So that was kind of just a brief intro into how I kind of got into the decoupled space and started looking at ways that we could use APIs to syndicate content around rather than kind of duplicating it through databases. Great. Hey, everyone. My name is Jason. I am not from Australia. I'm from Atlanta, a little south of here. I've actually been with Acquia for four years, and I'm the front-end lead in professional services. My experience with Decoupled Drupal started more intensely a year ago when I was tasked with helping lead several initiatives. So a lot of my day kind of stretches from multiple roles, but there's a lot of decoupled conversations, right? And we'll get into that as far as, like, is my project or is the scope of my project appropriate for Decoupled Drupal? I know there's, you know, a lot of things to cover with that topic. But pretty much, you know, my day-to-day, as far as like working through best practices with Decoupled, how to communicate the best use cases for communicating those scenarios as well. So, yeah, kind of cover things all over the place. Cool. So let's just jump into about the presentation. I'll run through these pretty quick. I'll give you guys a quick refresher on Decoupled Drupal. Obviously, since it's more advanced topics, we won't, you know, belabor the point for these items too much, but we'll give you, I guess, a little bit of a flavor of our opinions on it. Yeah, next we'll jump into React Plus Drupal, the new hot couple. We want to kind of cover React as, like, our framework to kind of discover and utilize the APIs, but, you know, we've used a lot of things like View, Angular, across the board. We just chose React because we wanted to, honestly, play, play around with GraphQL and React in our Decoupled Kit, which I'll get to in a second. Next, we'll cover orchestrating Drupal API data. We'll primarily use GraphQL as a way to communicate this, but there's, you know, several other options out there as far as middleware or proxies, ways to do this. We really want to communicate why we chose the path we did, which I'll get to in a second, as far as understanding architectures and comparing architectures, right? So, depending on your project and the scope of your project, various things are obviously required. So we wanted to kind of take a step back within our Decoupled Kit, which we bought, just to explore each option and compare, like, you know, why is the proxy helping in this scenario? Why are we not, you know, for example, interacting directly with the JSON API? Like, we really wanted to kind of dig into those scenarios just to understand them so we can communicate those out to help other people get their learning jump-started. Next, we'll cover Decoupled Development in the Real World, right?  That's, you know, a big passion of mine and Steve's as far as, like, choosing the right architecture for the client, not using the newest, coolest thing, throwing it over the fence, and, you know, just get Adeline out. And lastly, we'll give you guys a demo of our Decoupled Starter Kit. We probably didn't mention this before. This isn't anything we're selling. We've got a different source for you guys to download, play with, you know, use it as well. We used a lot of different toolkits. The React Slingshot, Headless Lightning, GraphQL, as I mentioned before. So, basically, our only purpose was to help further our own learning to help enable people on our team and people outside of Acquia. So it was essentially just, like, a developer, a developer's exploratory, you know, journey of understanding different architectures, discussing it, arguing about it, making the best decisions, you know, based on what we were trying to communicate, but also, like, understanding that there's a lot more things we can build, and a lot more things that, you know, we'd love to hear from you guys as far as what you would find interesting. Cool. Okay. So we'll run into some quick things with the basics of Decoupled Drupal. So, obviously with Decoupled Drupal, the main theme is that you're using Drupal as a content store, right? So, once again, this doesn't need to be, you know, just Drupal. So what we do sometimes is Drupalists, we focus so heavily on Drupal as, like, the main cog in the relationship of these different architectures. In a lot of cases, it's just 10%, right? Like, you're dealing with several APIs, legacy systems, old.net architectures. So I think it's important to kind of, like, scope it that way as far as, like, yes, this is an API-first approach to Drupal, but you're also dealing, you know, mini scenarios, which we'll cover in the Decoupled Kit other API scenarios. You know, obviously another big component of what we're talking about is shifting the responsibility of the presentation layer to non-Drupal applications. In this case, it's React, but it doesn't mean necessarily you're negating the front-end altogether. Like, we've explored a lot of scenarios, you know, with ourselves and clients as far as, like, stubbing out certain content types to be used, you know, to run, like, native React native apps, but it doesn't mean you're necessarily not using the front-end. I know there's a bit of, you know, discussions about that as far as, like, why would you negate so many things in Drupal? We're definitely not, you know, proposing that, and we'll make that really clear throughout the presentation, but we also want to kind of talk to that, too. And once again, you know, just enabling external applications. This could be several things. It could also be using external APIs to bring data back into Drupal, which we'll kind of cover through Marvel's API in a second with the kit. But also, like, understanding what that means as far as, like, best practices using OAuth, you know, validation, how to set your tokens, a lot of that fun stuff. Like I mentioned before, a big focus that we wanted to do was understanding how to synthesize non-Drupal and Drupal data and what that means. Like, is it better to use, like, if you're using, you know, for something more marketing for combining that data and you just want to, you know, essentially use, like, an external views mode, essentially to, like, pull in marketing data or things like that, or you're really migrating information back. So we actually, we'll cover this in a second, but we actually cover the scenarios of dealing directly with JSON API or using the orchestration layer, like we'll talk about. So just to reiterate the first point, API First approach, our version of API First Drupal isn't about negating features. You know, Drupal spent years and years doing things really well, trying to do things even better. We're definitely in no way proposing, okay, build your own editorial workflow. Like, hey, let's, you know, custom workbench and react. Like, to us, that's crazy because we don't want to, like, take away things that Drupal is good at to build custom solutions for. Our theories are more to extend and allow Drupal to power, you know, with editors having a comfort level, allowing that comfort level for them to, you know, go through normal, you know, workflows as far as we're going to go. We're going to go through a lot of different, you know, general experiences, but also power multiple other, you know, mobile apps, Alexa, things like that. So we really want to focus that as far as, like, you know, our big focus. This is a big question that we could probably spend three hours in here. I'm sure a lot of people have opinions, which is awesome. We don't see headless things. We don't see headless things. This is definitely dependent on the scope and various scenarios, like, you know, the technical scope of your developers, who you're handing this off to, how is this going to scale and things like that. So I'll run through these real quick. Typically in my discussions, we started with the client in, I guess, phrasing it like this. Is your business focused on making it more of a, is your business ready to work towards the directive of supporting and building on the API first. And the other things will kind of fall and sink after that. Also, is there a functional need to interact with data outside of Drupal? That's a big one, too.  Yeah. And a lot of this, too, kind of comes down to, not that it's necessarily a qualifier, but, you know, you talk to a lot of technical folks that, you know, have their preference of working with people. And that's perfectly fine. You know, you want to do what's right for your client first, regardless of who you work for or your role. So we try to really focus on what's the comfort level of the people that are taking this on and helping develop.  We also want to make sure that, you know, if they're willing to adopt as far as from a business perspective, that directive, then we definitely want to enable people and have them, you know, work in the direction they're comfortable with. Cool. So I think it's important to understand what a content API is and how Drupal fits into the mix in providing that content API to many different clients. So traditionally, APIs have been a way for applications to share data and the content API is no different to that. It's a way of sharing content from a source to many different clients. Where it differs from a traditional API is that content is much more different to typical interactions with an API. So content has references, content has relationships, and content has all this complex metadata around it that we need to kind of replicate within an API. So things like JSON API and HAL are standards around how the API can expose that data in a way that the application can already infer different references. So when we talk about Drupal as a content API, providing a content API, we need to really pull back a lot of what Drupal actually is good at. So controlling layout, adding classes, adding styles in line with whizzywigs and things like that, which is things that we allow content teams to do. We kind of need to pull that stuff right back and say, you can't actually do this anymore. So we want to make sure that we have enough data and enough content for people to build good experiences with. So content APIs like JSON API, like HAL and different specifications, they strive to maintain the relationships between content. So if you use JSON API, you'll see that any reference is a link to that reference and you have to make another HTTP request to pull that stuff back. And then you have then you can have a full understanding, a holistic understanding of what that content is. So this is also about kind of making sure that the content is available for multiple different types of clients as well, so not just websites. In the way that the landscape is evolving, we're kind of starting to see things like chatbots and, you know, Alexa integrations and all these kinds of things that can start leveraging the content APIs. And if you start putting presentation in the different interactions between different front ends for your apps. One last thing I think I want to touch on with content APIs and how Drupal can fit in here is that out of the box, the JSON API module will give you a lot of functionality with your different content types and do all that kind of stuff. But if you do have custom modules and custom functionality that you need to provide to your different front ends, you have the ability to use different REST end points and understanding how they handle the data that you transfer between both applications. In our decoupled kit, we didn't really want to go down that route and we just kind of wanted to use the out of the box experience with Drupal and try and build a content site based on that kind of out of the box experience without touching too much on the REST plugins, but that stuff is available if you need to go down that route as well. Security is a pretty big thing around APIs and how do you make sure that your API is secure and you know who's talking between who. A lot of the headless profiles come bundled with simple OAuth in Drupal and OAuth is the de facto open standard for securing APIs. We'll kind of touch on, I'll go through exactly what OAuth is. OAuth is token based authentication. Your client will send a request to some API credentials that you define, so you'll create a client, you'll set up a secret ID and access to a public ID and you will sign that request with the back end and it will give you a token. Every request from the front end then is using that token and that will then operate on behalf of the user that generated it. So the back end knows that they, if I request and I get an authenticated user token, then I'm an authenticated user and I can have access to the API. And this is all stuff that's handled by Simple OAuth as well. Simple OAuth also provides different grant types and this comes into consideration when we're actually defining applications. So there are two main grant types that you'll probably look to use if you go down the OAuth road, so there'll be the password grant type which is something that's typically used by applications and this doesn't have to be the source. It'll be between the applications to sign the request and generate a token for every request that that application will make. This is typically what you would see on like a mobile application rather than having your user login and you will get all of that content. The other one is the access code grant type and that is the one where you will click on the login button that will redirect you to the source and your login. And then you'll access the grant type and you'll allow the client to have access to your data. And all this stuff is provided by Simple OAuth and the decoupled kit has examples of how this interacts with Drupal and with the React front end as well. So we've got a page that we'll go through when we get up to the demo part about how and we'll show the workflow fully from end to end of how the OAuth signs the request and how we get to actually see a little bit of an example where content is restricted for certain user types. So you'll see how you can actually start to map that stuff by using these OAuth and the scope and the grant types. Cool. So we wanted to include some information as far as within the decoupled kit as far as how you're dealing directly with JSON API. Once again, we're in no way I'll probably say this twice more in no way are we proposing that you have normal node CRUD operations and outside elements. But we did want to offer basically examples of how we're requesting the tokens, the setting the headers and giving examples for each CRUD operation. So we just wanted to offer that maybe as a way to enable people to understand the normal workflow but also essentially what the requirements are. So we tried to make them really simple, really build out the kit in that regards too. We have things broken down by components for Drupal CRUD operations by themselves, namespaced accordingly and tried to isolate the scenarios in a very easy to understand scenario. So if we're looking at here, this is oh by the way, sorry for each of the components we have separate content types. So for CRUD operations we have dogs, no I didn't include cats. For the GraphQL orchestration layer, we included Marvel's API, a comic book sales API and a couple local storage devices. And then for the single relationship we included Pokemon, some base stats and then we also have another user type for basically user accounts that we'll show you guys how we deal with like mock APIs in GraphQL and kind of cool stuff like this. So this is just a quick example of a post request and with yeah any of the entity references you have to make two calls, you have to essentially build it to begin with validate and then retrieve the information back for the final post. So that's what essentially the post is. This is just a retrieval. This shows a little bit more about the content headers. I believe with the last release of JSON API we had to add like one more thing was content type to the headers but other than that nothing really adjusted. You know pretty straightforward as far as like making those declarations in the header, retrieving the information back and I'll show you guys how we have all this information stored not only within React but we also have it within Redux. I'm not sure how many you folks are knowledgeable with Redux but we'll kind of explain how Redux is used within React to maintain state and kind of track different scenarios. It definitely has some cool tools we want to show you guys as well. So with update requests it's pretty much the same as a create request it just needs to change the method that we send the request with. This actually requires that we configure Drupal in a specific way so Drupal's configuration as of I think 8.2 allows us to set API and the rest settings in the settings YAML files so you need to ensure that we have we're allowing the correct headers to actually make these requests as well. So if you ever want to go down the CRUD operations they need to accept patch, put, delete, post and it needs to actually be in your configuration otherwise it will not work. One other thing I think it's important to touch on with both update and delete is that the API doesn't do a confirmation so if you were expecting it to or like in the Drupal UI you click delete and say are you sure you want to delete this it doesn't actually happen in the API which is to be expected but it's just something to be aware of it will just automatically delete your content. No problem though. Cool so now we get into the fun stuff so orchestrating Drupal API data see this slide is called why use GraphQL but I think it's better to say that GraphQL here is actually a content middleware and GraphQL just fits everything that we needed to define for what a content middleware is so in a lot of our projects we see that we have multiple sources for data we have lots of different requirements around business logic on how to display that data and how to actually present it back to the user and what a content middleware will allow us to do is to provide a central place for all of that information so any business logic around how to display the content it's all in in one place it allows and that then will scale out when we need to add multiple clients to make those requests to the content so if we're adding a chatbot if we're adding an Alexa integration mobile app you don't want to have to reproduce all of that logic in each application to make sure that they understand how to read the data how to make those multiple requests to JSON API to pull back all of those reference fields do all that kind of stuff as well so the content middleware needs to be able to handle all of those use cases and provide a nice interface for all of our clients to interact with one other key importance here is that it actually even further decouples all of our clients from Drupal in a way that our front-ends don't even know what they're talking to to retrieve their data anymore and Drupal is purely providing the data to our content middleware so why do we choose GraphQL to do this so GraphQL I'll just go through quick basics run down of what GraphQL is in case you haven't read up on it but GraphQL is a structured query language that allows the user to define data types and it's done pretty straightforward in JavaScript there are a few different implementations in different languages as well but they're all roughly the same so you define your data types you define what fields they are what types of values those fields contain so you know your standard ints strings, floats, all that kind of thing and then what it does on top of that is it allows you to request for specific fields so whereas REST and those kinds of things will return you the entire resource GraphQL will actually allow you to say I only need to display the title so you can just do a query request to the GraphQL server say I only want the title and it will just send that back to you and that's a really powerful thing when you're creating front-end clients you can reduce the chattiness between your application and the back end and then when you start going down different types of integrations while it's fine with the web you can do those requests it's all fine but once you get into mobile apps you're running into restricted network access so you can keep the payloads between applications to a minimal so yeah that's it simplifies that whole request pattern as well another important thing to note with GraphQL is that it's not actually tied to a storage mechanism so where REST and stuff is typically a way to expose the database and the schema of your tables the GraphQL allows you to define exactly how you will pull that information from wherever it exists so you can define an API request to pull some information back so it can go to another service you could have it set up directly to query Drupal's database if you wanted to you could do it have another MongoDB on the node server that can have some data that you want to expose and you can do all of this kind of different things and you just define resolvers on how to actually access that data it's really quite powerful for that and the last thing to note sorry the last thing to note is that while it's mostly around reading data and retrieving data from different sources for it to actually stand up against other SQL languages it needs to provide a way for you to update those data as well so we have examples in the couple kit of how you can actually send mutation requests through to the GraphQL server and how we can then understand those and operate with different APIs to update the backends on how to change the data set cool so like I said we kind of broke each of these components out by their functional purpose right so in the example that we built with the Pokemon we're just dealing, I'm not sure if you guys can see the graphic at the bottom left we're just dealing with the one-to-one relationship as far as having GraphQL in the middle so we'll get to the next example in a second as far as like the multiple APIs but in this scenario we dealt with just constructing things in GraphQL so we could use that middleware layer to define the schema types so essentially most of the work was done in GraphQL as far as identifying those schema types and then defining those queries to accommodate in this case it's just a single request but we'll show you guys how the resolvers are addressed later on and then finally just requesting that JSON API data from GraphQL and as Steve mentioned it was really efficient as far as nested things like taxonomies, images, things like that where you have to typically hit multiple endpoints, accommodate logic, pagination, things like that but within GraphQL it was way easier so we essentially did most of the work within that and then kind of followed that route and then finally we'll get to the React app as well as far as making essentially those queries to call that information we're not really running any update operations so it's pretty much just fetching those nodes but we wanted to show a really simple example for you folks as far as understanding how to do that before we get to a little more complicated scenarios the decoupled kit also has a way as we were saying before a lot of business requirements end up having us talk to multiple APIs so a legacy API internally or an external API that provides additional content to help expose some of the data that we need so we set up a, there's an example there of how it looks architecturally we've got a set of marble characters coming from Drupal and we actually wanted to augment that data with comic book which comics they appear and then another API provides the sales data around that as well so where the GraphQL server can handle talking to Drupal to get the initial result set and then also extending that through to different APIs to resolve for fields one interesting thing to note with GraphQL is that if you don't actually request those additional fields so if we don't say we want the comic books return without request GraphQL doesn't even make those API requests to do it so it's another kind of performance win on the content middleware layer where it's only going to fetch the data that we need present that through to us on our front-ends this is the example that we use to set up a mutation so we can add additional heroes to our back-ends we can go through, when we go through the demo you'll see that we've got a drop-down it kind of is also powered by GraphQL and another different type of data storage mechanism and it will send us through a list of heroes that we can use to add to our source automatically update based on GraphQL knowing that we've got this hero name we can go through the different APIs we can pull in all of that data and it's all kind of automatic after the initial update we also started to as we were developing this we kind of ran into a few issues with performance on the middleware so once you start to add all of these different API requests it's probably not the same if you've got databases that are much faster but API requests end up being slow what we were using is quite slow so we're like how do we improve the performance of our middleware here and that's when we found a set of tools from Apollo that allow us to actually cache those requests in the middleware so it augments the GraphQL schema definitions with some cache tag availability so we can start using a local in-memory cache for the GraphQL server so it doesn't actually have to make those requests again either so we get another performance win from the middleware it's already built the resource that already knows what the data is stored in memory until the next time it clears or until you manually perform a cache clear cool okay so next we'll just jump into a couple topics with like I mentioned before we're not really calling these best practices this is more just the reality of developing in things that we're encountering as we're building the kit but also things in conversations with clients so obviously when dealing with an API there's several scenarios right like Steve mentioned with caching we handled with Apollo but we also wanted to understand what it meant for local development understanding dependencies on outside APIs but also really like you know failover scenarios like what happens if your API is down what if the wrong things are cached what if you know how are we going to address cache busting on non-static elements so we really wanted to try to understand those and include those in the kit which we addressed as far as those typical workflow scenarios but you know as you can assume most of the scenarios are typically with multiple things depending on the speed of transferring data between those things so that's what we try to focus on a lot as far as like understanding the right level of caching not over caching cache busting things like that and also like securing and tracking authentication obviously as we mentioned before it's a big focus but we wanted to kind of segment that information out too you know so you guys can download and understand cool so the big one is API fillover right it's something you know just like deploying on a Friday or slow latency you know like until it's an issue for you it's not an issue right but we need to we really wanted to address like normal scenarios so we I think I want to step back just for a little bit as far as like the high level right so like when we're talking about normal development you're dealing with like scoping and allowing for plenty time for like functional and unit testing it's the same way with like any type of couple structure right like it's really about planning and understanding like stability patterns you know circuit breaker design pattern Steve mentioned to me yesterday the chaos monkey which Netflix uses as far as like just trying to break down your system at different parts so a lot of that is just having the right things segmented for failover or caching things appropriately and understanding things on a timing function so that you are addressing if things are down you can essentially store the last best scenario with that data so the user's not seen any downtime but then also checking periodically depending on the scenario just like normal circuit breaker architectures we also wanted to simulate API connectivity with local tasks I'll get to that in a second but you know we rely heavily on mock APIs GraphQL offers you know something out of the box Apollo but there's a lot of things you can include with react not only with just test and you know other functional testing suites yeah so let me jump into caching mechanisms which we once again all these examples we'll get to in a second but we you know segmented these out as far as each scenario example so this is just a way that we can use the client side caching mechanisms as well so this is just adding more robust failovers for our whole decoupled application so you've got proxy caching on Drupal you've got varnish and CDNs and all that kind of stuff to make sure the JSON API responds well you've got the in memory caching GraphQL because all requests there are post requests so you know setting up reverse proxy caching is a little bit more complicated and then we also have the client side to deal with and the client side has a few different caching mechanisms that we can employ so we've got them here and we've got examples of them in the decoupled kit as well but I'll quickly go through what Caches is a new API that the browsers are providing for us and it actually is designed around caching HTTP requests so it will respect HTTP headers and it will also create different caches based on the very header that's sent back from the API or the HTTP place that you're making the request to the local storage method is using window to local storage and it is kind of a simple key value store in the browser client's browser so I think it's limited to 10 megabytes of data so it's usually for really simple kind of content structures that you go the app can't not have this stuff so we kind of need to put it somewhere in case it doesn't ever make that request again this is the simplest method to implement of all three but it does have a limitation on the size and it's much more restrictive than the other two and finally we have index DB which is an in-browser relational database that is limited to 50 megabytes per browser and some browsers have slight variations but on average it's 50 meg and then you have a full API around creating a local database for each browser that makes a request to your application this is quite complicated and it doesn't use promises which most new applications that you're developing in JavaScript will want to leverage your application because it makes controlling the flow of the application much better, much easier so in the decoupled kit we actually found a library that will help add promises around the browser's API for Windows index DB and it's called DEXI so if you ever download the kit you can have a look at DEXI and see the API that it's got which is quite useful and quite easy to use as well cool so I'll touch on this real quick you know I know Mock APIs are synonymous with sexy development why use Mock APIs I'll let you guys read through the list but essentially we're trying to emulate things on a local development level but also working with other teams and external APIs can be a bit taxing as far as rate limits and things like that so we want to kind of address a way to simulate data as we're testing but also like say you're creating a jura ticket and you want to scope out what does it mean if we change the API and construct it this way well Mock APIs are great because we can actually you know if you're working with another team and we're understanding what needs to be requested we can actually Mock that up with a proper schema and the right tools and offer up that data to essentially demo and say okay would this work you know and especially when you're dealing with like external teams or external dependencies you don't want to be you know throttled by whatever's going on with the other you know scope or the like testing coverage is obviously big not only with continuous integration but local development so we want to like really focus on like you know for the proper times understanding run through like Mock's you know retrieving basic data and not getting too complicated with it but at least address addressing the main like breakpoints as far as like hitting the right things with the circuit breaker scenarios just so we're understanding things. Here's a couple methods that we took a look at tools package so we're using that as far as like emulating the user information but there's a lot of different options right like with react with react-adjust you can test things node comes with JSON schema faker and also node you can just use JSON server to use like a JSON file and it'll build from that schema construct and serve up that data for you for local testing cool all right so now that we've talked about the coupled kit for 35 minutes we're now ready to show you guys Steve do you want to cover the GraphQL stuff for first yeah we can quickly go through this so this is if you run your GraphQL server in dev mode they give you a schema browser called graphical I think it's a browser yeah and this kind of let you just kind of really quickly query that the schema types that you set up so you can go through and you can show exactly what fields you want what fields are defined and how the server should respond to those things as well so if we step through this we can kind of see that we won't go through the code but I understand like I know that here the ref types is an actual another reference field in the Drupal JSON API so this is just kind of showing us that we pull it all back in one request we make a query with all of these fields and we need them all to display our to build our front end API our front end UI and it will automatically make that request to Drupal again to pull the ability types back it will make that request again to pull the ability types back and it will do that all on the GraphQL server and this kind of just explains how that works cool yeah and with the kit we also included a bunch of documentation not only within the code itself but also we built up a lot of readme files and read the docs if you guys ever use it it's pretty rad so we tried to step through the code as far as like what are we trying to do this function does this this function is expecting this we're expecting here just to you know essentially communicate and help everyone understand our typical workflow and our thinking as you know as far as the time we were building it yeah and the code has pretty good documentation as well so if you pull it down you're all if we've ran into something that we had issues with we kind of documented out our approach and why we chose a certain way to solve that problem yeah minus the curse words so if we look at the first example as I mentioned before we have things kind of broken out as far as this is essentially not using GraphQL at all it's just dealing directly with those JSON API calls so we have like an example for each of our dogs as far as like creating a new node looking at retrieving a list of nodes with each dog and then using React to essentially like build build in have an editor there upload a new image and also removing the node so we we broke these out like in a very simplistic way but you can definitely get way more advanced with a lot of these things we just wanted to at least for the baseline communicate that pretty easily and then get a little more jazzy on the feature branches yeah and it shows you how the interactions work with Redux as well so we'll go through the action flow from Redux and we'll go through triggering an event with Redux and sending that through and then sending that back to the front-end so it updates and manages the state that way yeah and here's the Redux toolkit the window is kind of small but it's kind of neat because you can actually bring things through as far as like the state timeline and actually emulate you know like the typical workflow of like retrieving the data interacting with the data and you can actually step and debug back through the code as far as how that is updated within Redux so as I mentioned before this is the one-to-one relationship with the Pokemon data and so we essentially have like the query here with exactly what we're using in GraphQL as far as fetching that information from GraphQL on that proxy layer and then each of these is just like a node example as far as expanding it down showing the different attributes things like that not all the attributes but just a couple there's a lot so at the bottom we also have like a quick example as far as like we wanted to you know a lot of us are you know started out or mainly Drupal developers we wanted to show like some pretty simple cases but clearly communicated cases as far as like React how we're doing like data comparisons and things like that so we have just you know like a real simple game as far as like matching one-to-one like he would be the winner based on attribute but we definitely have some stuff upcoming that's a little more you know verbose as far as like visually cool so Steve yeah so this is the example where we're synthesizing data from multiple APIs and we've got little badges on on each row where the the data comes from so it makes a request to GraphQL and it says that I want the comics and the comic sales and that will then fetch those requests as well and we've also got here this is adding another this is a mutation so this is an example of sending a mutation query to the GraphQL server it setting it up doing that inserting that node into Drupal and then we have access to all this other data because those services know already that Black Panther is a Marvel character and the APIs know how to pull that back so really quickly we get all this extra information without ever having to migrate more of that content back into Drupal we've got the middleware there pulling information in from other things based on how we know the APIs work cool yeah and just to be clear like a lot of the work too with as far as like synthesizing the data it was mainly declared in GraphQL right like so yeah most of the work we're looking at different services there's a lot of obviously different services you can use but we want to use things like Marvel that had large data sets but you can do a lot of really cool things as far as like having like 10 different APIs that you're essentially blending together and constructing it away in GraphQL it's like really really easy compared to just dealing directly with hitting those endpoints you know one off yeah and if you also download this the decoupled starter kit this is the page that is leveraging the Apollo cache as well so you'll see that the first load on this page will be pretty slow because that's a lot of data that's pulling back from a few APIs but every request after that will be pretty quick yeah I before we used Apollo I think we were at like 40 seconds yeah yeah it was a couple tiers in our eyes but after using you know the right configuration layer for the caching definitely got a lot better so this is our example on the different caching mechanisms in the client though so this is the browser's cache here window.caches we've got a bit of a write up on how they work so windows.caches requires a service worker which is also a new concept in JavaScript land so that basically the browser your website will deliver another JavaScript file that the browser will run outside of your page and it will set up a few different environment variables for that browser tab and what it does here is it actually creates the cache for our frosties window.caches after that we've got the local storage one and that's just simple key value pair that stringifies the response from the API and the last one is actually using a local database you can actually if you open the developer tools you can see how much data each one is using as well and Chrome has some pretty good developer tools around this stuff I believe it's in memory cool yeah with the API DocMate Datamock as I mentioned before we're using GraphQL but I've used other JSON services as far as far as marking this up we have most of our variables just included in a local .env file which you can obviously use for hosting deployments to contextually switch between different APIs but for our local storage we're just using a couple different variables not a lot a couple key pair values from Apollo and for this one we set mock to true it's just a true false and then based on that it will actually build whether we want to use real data from GraphQL or GraphQL to generate the mock data so that's essentially this example we jumped into a chat box integration too with the Pokemon data just for fun really this one shows another client that's talking to the GraphQL server to pull information back you can see there that it made a request and it knows it asked for the field speed into the GraphQL server and it pulled that value back we can start interacting with our content in different ways this is the example that we recently set up and it kind of shows the workflow of an OAuth request making sure that we can generate a token for a particular user so if we log in it'll actually redirect us to the Drupal site we're already logged in here so it'll ask us to grant the permissions, we grant them back and it sends it back the token it sends back an access code which we then use to generate an OAuth token which can then be used to request information from the API on behalf of that user so we see here that Drupal roles has too, it has premium and authenticated so one thing I didn't touch on when we were talking about OAuth is that simple OAuth uses Drupal roles to control scope so in this case we asked for the premium scope to be added to the user's token when it generated it and what the simple OAuth module will do we'll actually do an intersection between the roles that the user has and the roles that you're requesting so in this case if we log in with the standard user so we've got two users here, standard user doesn't have the premium role even if we do request the premium scope simple OAuth won't generate that token with that scope so this content here would not be visible to the standard user and that's it let me check time real quick okay cool, yeah, I wanted to allow definitely allow enough time for questions if you guys want to kind of jump into it that a couple kit is here for download but yeah if you guys have any questions please hit us up afterwards we can talk over Steve Febier and a Zima for me because I'm a gentleman but yeah let us know if you have any questions just hit us up too on Twitter or you don't use Twitter yeah anytime after the conference at the booth we will have a demo again in the booth tomorrow I think is it 12 o'clock so if you have any questions we can't answer here come up and have a chat yeah and when everyone's downloading and trying out the different features we'd love to hear feedback we're definitely going to make this an iterative process as far as like adding new features exploring different architectures which once again is just to help enable other people provide feedback contribution things like that we'd be super happy as far as like if you guys have any information you want to transmit back to us so we can help include in our roadmap yeah thanks yes sir is there any reason to choose React as opposed to Angular or something like that as far as Drupal is concerned or you know for any reason not really it was just a personal preference we wanted to use GraphQL so we thought it you know yeah and Facebook so trustworthy we decided to go with React but no yeah no it was just essentially just a preference I have worked with Angular in the past before so we wanted to essentially try React to understand like Redux especially with the binding of the data within the API so that was the main reason yeah and hopefully we can get in and write a framework similar to the React one with the other front ends as well so we can use View and Angular and there will be a different starter kit kind of thing for each different JS framework yeah precisely yeah so with JSON API you're passing structured data but it doesn't directly address handling serving up files like CMS managed files including images and PDFs do you have a philosophy or suggestion about how you would do that and do you proxy it or like in our case for Edutopia we wound up spinning it out as a separate service yeah up to this point probably our opinion would be the same just because what we discovered was not only with like the complications of doing like the round trips just the caching was an issue dealing with like a CDN because you're essentially sidestepping what you can do in Drupal and sort of those assets or address it CDN we tried a couple different scenarios I think currently we're just using like file entities but we I think next like number one party on our list is look at different ways to address that so we'll probably have examples as far as like serving it up even from like a third party CDN or something like that just to make it easier but that is yeah definitely one of the big you know bombs yes sir you probably have total control of the data coming from Drupal my question is could you have used the GraphQL server to grab data straight from Drupal instead of going to the JSON API you could you'd need to expose the database to remote requests but you can do that as well so there are node there are node packages in this case in our example we're just using a Node.js server for the GraphQL server there are node packages to integrate with a MySQL database so you could have that queried directly to the MySQL database to pull those fields back and that information back as well you don't need to go to JSON API but it's not part of a kit right now not right now thank you any other questions yeah cool awesome well yeah thanks everyone yeah absolutely thanks so much I really appreciate it thank you thank you first time ever for that thing first time was it alright yeah thanks thanks thanks thanks thanks thanks thanks thanks thanks


Rude mom tells daughter we don't talk to dirty bikers, bikers response goes viral. You've probably already heard the saying, don't judge a book by its covers. But lots of people tend to do the exact opposite of that and persist formulating an opinion about others by their outward appearance. Yes, if you turn around and open your eyes, you will notice a lot of people that are quick to judge others by their looks. Then, as if that isn't enough, they tend to formulate their opinion on the first impression and oftentimes that can do a lot of harm to someone's psyche. A biker named Luke Parowalt is familiar with these kinds of judgments formed after the first impression. He knows the feeling of being the target of tons of stereotypes because of his 280 pounds and his dress code. Luke is a biker and he loves to dress like one, but because of his size and his clothes oftentimes, people tend to make assumptions even before they need him. And one day, when he went into Tim Hortons for a cup of coffee, he found himself in the worst situation ever after meeting a woman and her daughter. It all started when the young girl approached Luke and tried to greet him and say hello to him, but what happened next will leave you in awe. After the girl's mother decided to pull her daughter away from the biker, he was a bit confused. But, it soon all got a lot clearer. The mother said to her daughter that she shouldn't talk to dirty bikers. Luke was understandably shocked by everything that happened in front of him in the last couple of minutes. He couldn't understand why someone would not be okay to talk with just because of the fact that they decide to dress in a different way. He was emotional because of the event, but kept his cool. Then, he decided to take the rage out in an emotional and powerful message on Facebook. In his Facebook post, Luke turned all of the attention to the family in the red SUV at the coffee shop. He continued by admitting that he might look a bit intimidating because of the way that he dresses, or the words that he uses to express, or maybe because of all of his tattoos and the fact that he is a welder. But, he continued that these facts don't give them the right to offend him and keep their daughter away from him. He stated that he is a proud father and husband and that he has graduated from college. He then shared a story where he spoke about his daughter and the time that she broke her arm and how he cried more than she did. He finished the post by explaining to the mother of the girl that despite the fact that she heard his feelings when she said those words, he is going to be the first person running into their burning house to save her daughter's goldfish just so that she doesn't feel sad. Today's internet has a lot of power to influence something. So, it did just that on Luke's post because of the nature of the event, it gathered a lot of attention and a couple of heated arguments in the comment section. Lots of people shared the post, and many others commented and reacted to it. Luke's story got covered by many news outlets as well. I think he understood the whole moral behind this story, but for those of you who didn't, don't judge people just because they look and seem different.


Good morning Cybertraders, happy Monday everybody good to see you all welcome back good to see you Phil Lawrence Michael good to see you Brad everyone at cyber trading everybody welcome back. Very excited for a wonderful day here, beautiful weather here in New York thank God, it's been raining I've been living with rain for the past three four weeks even I came back from Easter, we had that big rainstorm which a lot of you know what happened back in. Back on Easter, I got 24 inches 27 inches and Fort Lauderdale was disaster, but looks like we have a nice weather and you know what we had. Let me tell you something last week was has to be one of the one of the greatest weeks that we had in a long long time. I'm not talking, you know, like weeks I'm talking months. I mean I want to start off talking with that top trade right there. So top, you know, it's funny. I know a couple of people like I told you and fortune had to go to a funeral. You know I lost a very dear friend of mine last week and but throwing off the old Normandy industry know talking about the stock top. Holy cow this thing was absolutely incredible so start on Friday and you could see it right here the thing ran from $50 shop all the way up to about 150 and you know I know a lot of people got out around 200. And I think came all the way back down to 120. I mean this thing was just one of one of the greatest shorts that I've seen in a long, long, long time. And we see what short go from like $30 to $2,500 was it 8 HKD with it was one of those stocks that we traded. But yeah, it was a lot of stocks that was going on. Anyway, that was a lot of fun. It was a little dance a little dangerous and be careful. But but you know if you wanted the advanced trades did pretty well. But there were a lot of good stocks. We're going to talk about those. We're also going to talk about some of the stocks and moving this morning. Now just a couple of quick little news before we get started. We all need to know what needs going on this week. Okay, so we all heard the news probably over the week and we finally got a buyout in an FRC first first Republic Bank and one of the other companies, you know, California companies went out of business. JP Morgan Chase bought them out and I want to keep an eye on it. You know, usually that's a good sign. Usually when a company gets bought out, you know, the other company does bad but Chase is doing pretty decent. I don't know why Chase will go up JP Morgan right here. You can see it's up on the day. That stock is obviously doing pretty well. It's usually the opposite. You know what's scary that, you know, a lot of these smaller banks actually wasn't small bank at all. It's actually was a big bank at one point. But, you know, you could see a stock was all the way at 150. This stock was more money than JP Morgan, believe it or not, which was crazy.  I mean, these things do a phenomenal lot better than JP Morgan. You know, it's funny, you don't really hear too much about these companies.  Anyway, it's got a big buyout. I would keep a close eye on it. It finally looks like it built some support levels at a buck 60. You know, it's not open yet. It got halted. We'll see what happens when it opens up with the overall buyout price is going to be on it. But that was moving pretty nicely. And, you know, and another big news that's coming out. There's a Fed meeting that's going to come out on Tuesday to Wednesday. Markets should be kind of shitty going on. I would probably say for the next two days. But listen, for us, you know, we're trading the big percentage gainers and losers. There are a few stocks in there. We're going to check them out. And then also if you're watching, if you're here, if you're a student of mine here at Cybertree University, we got phase two that's going to be finishing up today. And then obviously phase three is going to start tomorrow and on Thursday. So that's what's with the big news. It's going to go on this week. Let's go over and talk about some of the stocks that we traded on Friday and last week. And then we'll talk about what's moving this morning. So the stock, let's listen tops. All right, enough. Let's get done with it. I told you, if you're not an advanced trader, it's one thing. I didn't think it was going to be a good stock in pre-market, but she moved pretty damn good. You know, once the market opened up and she just literally just took off. So that stock moved pretty well. Just stay away from it. The stock is very, very dangerous.  If you're on, if you're on one of these social media networks, if you click on that and just take your phone and scan it, you can always join our trading room. And we got a free workshop that we're going to teach you on it. So go ahead and scan it if you want and join us. But listen, if you're in a side group room, when we start doing commentary, if we do see something, I'll say something. You know, that's, that's our, that's our whole motto, but just be very careful of it. I know everyone's sitting there trying to get on that bandwagon and absolutely have no idea why it's moving. Another big winner that moved really nicely, something that was even more comfortable. I think a lot of you guys did really well on this one. This one was awesome. This CXAI, this thing just ran from $10 all the way to $17. Let me repeat that. $10 to $17. If you just got even like 5% of that move, 10% of that move, you still can make on a thousand shares, you're talking a six-figure salary. That will move pretty well. SAI, another AI stock moved pretty nicely. It wasn't as nice as the other one, but you remember this stock back in April, early April, it was at $1.20, it ran at about seven.  I would stay away from it now, but that one moved pretty nicely too. I thought this was one of the best ones of them all on Friday.  So sometimes you're kind of wondering, hey, can I still trade in the middle of the day? Do I got to be here all day? This one worked out awesome going all the way to the close. This stock, I mean, this was unbelievable. This thing ran from 12 o'clock. This was where we get program trading kick in. Ran all the way to, from two, was that two? It was three. Three, three 40, ran all the way to seven, right? And about a 30 minutes. And then did a little shake, which we all know about. Didn't break down. Boom, another pop, up to nine. Did a little shake, held on there right on three o'clock. This thing just literally just took off like a rocket. $8 all the way to 14. It was fabulous. Unbelievable move. Great moving stock. That one. And then last but not least was the MEGL. It was okay. It was a little bit all over the place. It was one of the stocks that was from the day before that gapped up, but those other ones were off the charge. Actually, Friday was actually surprisingly, it was a pretty decent day. I don't like trade on Fridays, but that obviously was one for the record books. Now let's go hop on and talk about what's moving this morning. Now there's one stock that you guys have been trading this morning. It's been doing pretty decent. And it's a stock QH. Now QH also yesterday, once again, on Friday moved really, really nicely too. I didn't want to talk about it yet. I wanted to wait until today. Wait until now, I'm sorry. About one of the stocks that moved, but this one also it was, it was more of an aft hours trade, you know, and you could see it right here. It kind of moved right in the aft hours from $1.60 all the way to about $3. She's gapped up this morning. You could see it right there. She's holding pretty strong. And she's, and you want to use Friday's resistance aft hours going into today. Now let's go hop on what we're really, really known for. Okay. Which is level four. Now when I hop on the level four bandwagon, I want to see what's going out there. I want to know where the orders are. Now there was a little bit of a buyer right here. You could see right around $3 from $9,000. And then when we get around here, there was a big seller right around $380 and a little bit of $4. Those big resistance levels, those iceberg orders that we're looking at is those resistance levels right here. And that trickles on from yesterday. I mean, from Friday. So once again, just because you have resistance in the past is not indicative of the future. How do we predict the future? Well, if you want to know if those resistance levels are going to be existing in the future, you got to follow those orders. And that's why we use level four. So that stock is moving pretty good. We'll keep an eye on that. We also have the stock SNTG that's moving pretty decently. And she got a big pop early at 7 a.m. in the morning. $3 to about almost 7. You could see that long, big spike right there. But the stock is a little bit all over the place. I mean, I would probably be really careful on it. You could see the spread. The tier size is very important. That's about 50% of the failure rate. So it would be a little cautious on that one, on that stock. So don't get too crazy on this one. I'm going to put on my watch list also. Listen, the stock's up 117% on the day. Now, there was this stock I looked at if I'm staying away from it. It was a big gap up. Third biggest percentage gainer, 86%. Really not Alforte. We'll stay away from that. Not really a good sign. What else did I have? Anything? Because usually we get some stocks that move up pretty big. Now, there's this stock right here. It looks like she just started making a move right now. I don't have it on level four. I got to see what the orders are. N-N-O-X. Yeah. Okay. So this one looks a little bit decent. You got some big orders. That's not a lot. You know what? Tier size are really small on this. I would probably stay away from it. I'm seeing like 4,000 very small tier size. You could even see their level too. We're seeing 200 shares to get it scratched that one. Once again, always remember this. And if you're watching on YouTube or Facebook or watching this stream live, Traders in the Cyber Group, you know this. 50% of the people fail. Fail because they trade something that they shouldn't be in the first place, meaning it's got a big spread. It's got very dangerous volatility. You got to be careful of those things. So I'll be careful of that one. I'm not a really big fan of that one right now. Once again, we'll see what happens when it opens. I'll put it not even on the B list. I'll put it on the C list. So I'm not putting it on my A list. I can tell you that. We've got another stock that's up 37%, 3 million shares right here. This stock also, not really that many orders out there. I'm seeing some big buyers right around here around $1.70, $74, $76. Not a lot. No really big iceberg all over. I'll show you right here, everybody. You can see there was someone out here at $2.40. He looks like he canceled. But you got these buyers now holding it pretty strongly on his book 75. And you could see it right here. It kind of makes sense why it's holding right here. I mean, we'll throw it on the watch list. We got to lose, right? Listen, it's not so far a good Monday. I could tell you that right now. The only stock that looks like it's starting to make a little bit of a move. And if it does get broken out, it's the biggest percentage. It's the most active stock on the NASDAQ. And it's also the biggest percentage gainer on NASDAQ. It is the QH. You could see it's moving up pretty nicely. It's getting close to our $4 iceberg border, which I told you earlier. Is there anyone else out there? There's a $20,000 share at $5.50. That's a pretty different substantial run-up if it did do that. What else did we have over here? I found the FRC. Like I said, that's out there. I mean, that stock is halted. So I can't even see. There's no orders going on right now. We'll see what happens when it opens up. What else did I have here? Let me see if there's anything here in New York. 33%. Stock was gapped up big. Didn't do anything. Garbage, garbage. I saw Carvada in here. I don't know what that's all about. It's only 4%. CHGG. I know that. We traded that stock in the past. Not really moving that much. Yeah. Silver's moving pretty good. Looks like metals are moving. OK. SLV. OK. We got all the silver stocks. OK. We got SIVR. We got SLV. We got Pan American Silver. It was at Posh. They're not moving too much, but that one's moving. Not too crazy. It looks like silver's all moving. Steve almost says, any thoughts on IC? I didn't see it on the watch list. You know what? I didn't want to put the, I saw it there, but it's gapping down. The thing's up huge. To me, it looks like almost like a buyout, but maybe not. I mean, it's up a lot. It's starting to trend down. I'd probably stay away from Steve. I'm going to pass on that one. All right. Anything else, cyber traders? I mean, listen, it looks like metals are moving pretty decent. So I would keep an eye on those. Look, J-Nut is on here too. J-Nug. J-N-U-G. Keep an eye on that one too. It looks like all silver stocks are moving. There's Pan American Silver. Nuggets on there. Yep. Silver looks like, I don't know what's going on with the metals, but we'll check out the news on it. But it looks like those are moving pretty nicely. Is this a metal stock too? E-X-C. The old silver on here. All right. PSLV. Yep. Old silvers. All right, everybody. All right. So let's get ready for the market. Open up. Listen, it's Monday. Let me repeat it because some of you are logging in late this week. You just got to be really careful. We got a Fed meeting. It's going to go on through Tuesday and Wednesday. I don't expect to be super crazy what's going to go on. So we'll see how that works out and see what they do at the Fed meeting. You got classes going on this week. Today, we got the end of phase two, then we got phase three. So if you're a student, just get prepared for that. If you're watching on here on social media, once again, don't get to take your phone. Scan at your QR code. If you want to get into the trading room, if you want to join us on a workshop, we look forward to teach you. Listen, you got to learn before you can earn cyber traders, right? Fellow traders out there. That's where it all starts. But listen, we'll start commentary once the market opens up. We got about 15 minutes. Just don't get too cocky. It's typical Monday, right? Remember, Tuesday, Wednesdays, and Thursdays are the best days to trade. But if you see something, say something. Good luck, everyone. We'll see you back here at 9.30. We'll start commentary. Everyone on YouTube, Facebook, social media. We'll see you back here at 2.30. Thanks, everybody. Happy trading.