Hey, this is Brett and this 2019 Chevrolet Corvette 2LT Grand Sport Heritage Edition is stock number 13992Z. I am here at Summit Automotive in Fond du Lac, Wisconsin. You're new and use sports car headquarters. This 2019 Chevrolet Corvette 2LT has the 6.2 liter V8 gas engine. It's paired up with the 8-speed automatic transmission. It has the multi-mode exhaust, which this one does. It puts out 460 horsepower. This car has been fully-safetyed and inspected by our service shop. It has a fresh oil and filter change, all the fluids have been checked and topped off per the state of Wisconsin inspection process. This car is 100% ready to go, extremely clean all the way around. That's exactly what I'm going to do in this video. Go all the way around, start it up, take a look under the hood, take a look inside the trunk. Let's give you the most accurate representation that I can of the car possible. If you like the video, I shoot all my videos in 4K, and if you like it, you can subscribe to my YouTube channel, which is youtube.com slash summit auto. Click the bell notifications. You'll get updates on the videos I do each and every day. As well as having access to one of the largest catalogs of vehicle, and specifically sports car walk-arounds on YouTube, over 8,000 videos on my channel and counting. In the front here, you get the 19-inch painted black alloy wheels with the red lines on them, has the big Corvette brakes with the slotted rotors, and in the front you get Michelin Pilot Supersport 28530ZR19 tires. I would say these tires have probably about 60 to 70% of the tread left, all the treads on the inside of these tires, but that wheel is in excellent shape. Front fenders in great condition as well. You get these stripes with the heritage addition, and note all the fender flares have this metallic black finish to them, as well as the inserts on the hood and the inserts behind the door there. We'll go check those out as well. This one comes with the LED lights in the front, LED headlamps, running lights, and the LED side lights. I'm going to turn all those on at the end of the video, so stick around for that. It's really not that far away. These videos usually only run about 8 minutes, so definitely stick around for that. The hood is in fantastic condition. No major scuffs or scrapes on there. The front bumper and lower valance are in very nice shape. I didn't see any scuffs on them. It does have the bumper cameras on there. Passenger side front fender is in great shape. And the passenger side front wheel, no major scuffs or scrapes on there. Once again, you get that black finish on the inserts there. And as you go down this side of this 2019 Chevrolet Corvette, take note of how clean that body is, how reflective, and just nice and mirror-like that paint is. Very nice and clean. I take these HD videos, so if you're far away or even if you're close by, just can't make the trip down, but you're still interested in purchasing the vehicle. You can see the car, hear the car, and have confidence in what you're looking at before you even get here. So when you do get here, there's absolutely no surprises, and you can make a smart and informed buying decision from wherever you're at. Look at that lower valance. Very nice, no scuffs or scrapes on that. Always got to look at these on these Corvettes. They're so low. And if this video helps you make a smart buying decision, let your salesman know that you saw the video, that it was helpful. That Brett sent you back wheels in really nice condition as well. On the back, these are 20-inch wheels, and they are P33525ZR20 tires in the back. And you can see just how much tread is left on those. Very hard to get underneath this car with the gimbal, but very nice and clean under there. Coming around to the back of the vehicle, rear bumper area is in very nice shape. You get the quad-tipped dual rear exhaust with the multi-mode exhaust. You can always tell if it's got the multi-mode by that valve right there. You'll open and close that valve right there. That's how you can tell if you don't know the codes or if you don't know yourself. LED tail lamps. And we're going to start this up in just a minute. In the back, you get some really cool stuff. You get some nice red floor mats. You also get a yellow and red car cover. These are the original side markers for the vehicle, because they replaced them with those black ones. And you get a Grand Sport hat. And then that's your shade, or some other shade for back here. But very nice and clean.  And that's nice and solidly. One other thing to note, this one does have the etched windows. So basically, they etch a number into the glass, every piece of glass. So if somebody was to try and steal this car, they'd have to break out every piece of glass. So that's kind of neat. Coming around the driver's side rear quarter looks really good. No scuffs or scrapes. And for full disclosure, this back wheel is in fantastic condition as well. Coming down the rest of the side of the car, the door is in very nice shape. Do you get power? See there's that etch right there. Inside you get the adrenaline red leather bucket seats. Both of these seats are heated. Both of these seats are cooled. And they are in very nice condition. I don't think this car has ever been smoked in. Both of these seats are power. You get the special heritage edition floor mats on there, heads up display, power tilt and telescopic steering wheel, power windows, locks and mirrors, and memory driver's seat, Bose premium sound system. Hop inside, check out the miles, radio, and everything that this car has to offer on the interior. You can see that this one only has 5,127 miles on it. You get the nice digital instrument cluster. You get the flat bottom Grand Sport steering wheel, leather wrapped of course, Bluetooth and information center and audio controls on the right, and cruise controls and favorite controls on the left. You get the paddle shifters on there. This one does have the heads up display. Once the car is on, I will show you that. This one comes with the Chevy MyLink system. There is highway 41, so that is working nicely. You get AM, FM and Sirius XM radio capabilities, and then back to your home screen, this one does have the performance data recorder on it, projection where you can project your cell phone to the screen, and then you have those front bumper cameras, which the car has got to be on for that to work. You get storage behind there, and it comes with a cleaning rig as well. Down here you have your more tactile volume, tune and climate controls, including your heated and cooled seat buttons. You also get that Grand Sport badge right there, 8 speed automatic transmission, get your different settings. So that one is tour, sport, weather, eco, tour, sport, and then track. You can swap those, change those out. That's pretty cool. Electronic parking brake and the passenger side format and seat are in excellent condition as well. Once again, it smells very clean. I don't think it's ever been smoked in the headliners in great shape. You get home link buttons for your garage door security systems and lane systems on Star and SOS buttons in that rear view mirror. Start it up. Take a look under the hood, listen to the exhaust and check out all those lights in the front. You can see that heads up display right there, so that's pretty cool. Let's go check out all those lights and take a look under the hood. Kind of quiet when it's just idling. Sounds good though and runs really smooth. I would personally like to thank you for checking out the video today and hopefully from this HD video you've been able to verify the quality, condition options and of course cleanliness of this car all the way around inside and out. There are those LED headlamps and running lights. You can see those side lights are actually orange, so they're all legal light. They just are smoked out and under the hood we have the 6.2 liter V8 gas engine, 460 horsepower. Has a nice cold air intake there, shedding performance and size. There's the emission sticker and once again this car has been fully safety and inspected by our service shop. Has a fresh oil and filter change, all the fluids have been checked and topped off. The shocks are doing a nice job holding that hood up and this car is 100% ready to go. I would highly recommend it from a quality and condition standpoint. I would ship this one anywhere in the country in a heartbeat. Whoever is going to get it is going to be very, very happy with the quality and condition and I'd ship it anywhere. I'd sell it to a family member by myself. That's how nice it is. And to see more pictures of this car or one of our other 550 new and used cars, trucks, SUVs, minivans, Wranglers, sports cars, Corvettes, Camaros, Challengers, Chargers, Mustangs, GT500s, Grand Sports, Z06s, ZL1s, you name it, we got it. Go to that website right there, summitauto.com, full pictures and descriptions of every single vehicle, all at summitauto.com and if you'd like to check out more HD videos you can go to youtube.com slash summitauto. Click the bell notifications. You'll get updates on the videos I do each and every day as well as having access to one of the largest catalogs of vehicle and sports car walk-arounds on YouTube. Over 8,000 videos. In fact, in a second you'll see a link to subscribe to my YouTube channel, the upper left, a link to more Corvette videos I've done in the upper right, a link to this vehicle on our website, lower left and a link to one of our latest YouTube videos in the lower right. Click those, check us out. We're super excited to help you with this ultra clean 2019 Chevrolet Corvette 2LT Grand Sport Heritage Edition in black clear coat. Thanks again for checking out the video. Remember to like, subscribe and share on the YouTube channel. I really appreciate it. Thanks again.


Distinguished ladies and gentlemen, I regret that I'm not able to join you at this first International Biodiversity Congress, but my ill-recallings will be doing so. I am pleased, however, to be able to record this message to you. The planet's biodiversity is amongst its most valuable resource. Those in crop agriculture have long progressed in conservation and use of this biodiversity to improve productivity and adapt plants to the environment in which they are produced. In animal agriculture, we lag with respect to conservation of animal biodiversity, but we are moving quickly ahead to catch up with our plant colleagues on the use of this biodiversity to improve productivity and to adapt animals to the environment in which farmers use them. Long generation intervals of certain livestock and inadequate tools have prevented us from making the same progress that has been made in the plant world on both conservation and use of biodiversity. We are starting to use more adequately the animal biodiversity which is available to improve production and productivity, and to adapt livestock to the environments in which they are produced, including resistance to disease, heat stress, and so on. In addition to the work on animals, we are also working very assiduously on forages and are hoping to replicate the successes that were achieved in Latin America in places like Africa and South and Southeast Asia. In that regard, I want to congratulate the Indian government for the initiative they have taken to ensure that animal agriculture is more strongly premised on the use of indigenous animals. I am sure that at this conference, knowledge would be shared and many ideas generated, so I am looking forward to the results so that Illry and all our partners can capitalise on the advances in these areas and use more adequately the animal and plant biodiversity that are available to enhance the lives and livelihoods of the producers we serve.


All right, you ready? You ready to dream a little bit or a bit more hopefully? I'm going to try to navigate like I have a lot of energy and I usually walk around. I also walk in the middle of the screen. I don't know what that means for the recording but I'm going to move a lot like you're going to have a lot of work with me. This should move if I press this button. Yes, it does. Excellent. Okay, so the future of Drupal teaming. A lot of it is dreaming and a lot of it is very energetic. So get prepared to spend every ounce of energy you have for today the next 50 minutes. Okay, so my name is Mathias Pellebein. I am a freelance Drupal front-end developer. I am one of the organizers of front-end United which is a global organization where we organize Drupal front-end events but I'm not going to talk about that today. I'm also the inventor of Componi. Componi is the thing that I'm going to be talking about today. It's also the little trail you see on the ground. It's my personal, how do I call it? I call it my ambition. Some people call it my tunnel vision. If you feel like you want to reach out to me, please feel free to reach out over at Twitter, LinkedIn, wherever you see this face online or a face that looks similar. I'm not going to be able to give you a lot of time to ask questions in person because there is a lot of things to cover. I have like around 500 slides that I'm sifting through and I'm trying to squeeze four hours into 50 minutes. But if you want to ask me questions, please go to slido.com, fill in the hashtag front-end. You can ask questions anonymously or in person I'm going to answer them all on Twitter afterwards because a lot of them require half a blog post to explain and I'm sure you're gonna have questions. So what are we going to talk about? When I say we, I mean me obviously, I just said that you can't ask questions or at least that we're not gonna have a lot of time for that. We're gonna talk about three things. We're gonna start off with an analysis and that analysis hopefully is going to show you the problem we collectively forgot we had as a Drupal community. And once I've been able to show you that problem I'm going to make you dream up a solution with me. How does that sound? Good. All right. So let's get started. We are going to start with the analysis.  So this, I don't know how many of you do back-end. This will insult you. It's with good intentions. It will only insult you in the first half minute, I guess. So mind you, the numbers I'm about to show you are very holistic. It's also holistic because I'm a front-end developer. And it's also to prove a point.  We worked on this project for a year and a half with around 10 to 12 people full-time. So it was quite big. And after we delivered the project, we kind of thought like, okay, what did we actually build? What did we actually ship? What did we actually sell to the end user? And that kind of looked like this. Now the back-end layer, right? I'm going to start walking around. What you see here is the back-end layer, is the way of how we divide up complexity. So if you ship a big project, this is usually how that looks. So 62% of that you download. Drupal core. It's the big blue one over here. Okay? On top of that, now of course holistic numbers, but it's one massive project and it kind of fell to me that it was very similar to how other projects were. On top of that you download an extra 33% of contract modules, which only leaves you with 5% of custom code. Now when I showed this slide to my colleagues, my ex-colleagues, I was working with, because I'm a freelance developer, right? They were very insulted by this number. They felt like we worked on this for a year and a half. How is it possible? It's only 5%. You must have done it wrong. But the 5% is not a bad number. The 5% is an amazing number. The 5% means that you only have to write 5% and you can download 95% of it. Even if you ignore Drupal core, you can download, for every feature that you develop in custom modules, you can download eight other features first. That's massively productive. So it's not a bad number. The 5% means whatever you're going to build, you're going to have 95% built for you. A lot of tools are already there. And it's also one of the reasons Drupal got this big and this far because of this massive productivity. Now, we're going to do the same thing for the front-end analysis. And the number is going to be a tiny bit different. Yeah, so 4% is coming from Drupal. And this is just one project. Usually, right? Usually we try to strip away this little bit. We want to go ahead with this because we really don't like that 4%. And then we have 96% of custom code. You didn't follow the trail. So we have 96% of custom code. Custom code that we start from scratch nearly all the time. Now, what does this mean? It means that we don't really rely on already written code. We don't rely on what Drupal is giving us. We start from scratch nearly all the time. Now, if we put this back-end layer and front-end layer next to each other in perspective, then it looks like this. And the massive difference is really shown. Now, no matter if the percentage is a bit off or how much is going to be off, you're still going to have a picture that kind of looks like this, right? Now, this is what we call the back-end layer, right? Now, this is what we call the front-end layer. But that's a lie, isn't it? A layer. A layer for me in coding terms means an abstraction on which we combine things together. The back-end layer, we combine things like core and contrib modules and custom modules. We combine them all together with configuration settings and so on and so on. On the front-end, we don't really do it that way. It's not a layer. What you're looking at, in my idea, is a front-end blob. A blob because we have this personal need of compilation. And again, I'm a front-end developer myself. I can find myself in saying this, so I'm kind of bashing my own here. But what we're looking at is a front-end blob. It's a closely knitted together thing which you can't take anything out of. It's all stuck inside of it. Now, it's a bit silly if you ask me because how many of you do front-end? I hope to see as many. Ah, good. We all write SAS. We all write less. We all write CSS, right? Every rule of CSS, every selector that we write, we write component-specific, right? Everything we do is component-specific by its very nature in the cascade of CSS. Yet, as soon as we wrote that SAS, we compile it into one massive file, one massive CSS file, right? The personal need of compilation. When we write JavaScript, we do the exact same thing. Everything we write is component-specific. And then as soon as we ship it, we bundle it into one massive file. And then apparently, we seem to have a performance issue on the front-end. Well, yes, obviously, because we load in every line of CSS and JavaScript, any developer on this project has written for the teaming layer. So, yes, we're going to have a performance issue. Now, Drupal has been able to do it in a different way. Drupal has been able to give us the library's API. And the library's API, if you ask me, it's the single most amazing thing ever. You can't explain this to anyone else. I don't know whoever worked in WordPress or any other CMS. You can't explain this. The library's API, for those of us that are not deep into it, the library's API is a system on which we can teach Drupal to know when to load which assets. It's amazing. We can teach Drupal when to load which CSS file or which JavaScript file. Yet, how many libraries do you define in your custom team? I'm going to take a guess. One. Am I right? I don't know if I'm right, but if I'm right, then I'm probably also going to be able to guess the name. You're going to call it global. Right? Because this is one global blob of a thing. Now, if we start using the library's API, then a whole lot of options open up. Now, we have a 95% readability and predictability of what will come out of the backend. And if we have a 95% predictability of what will the Drupal backend give us, then why is it that we're not relying on any of it? And that's what's baffling me. If we would write all of our Shas and all of our JavaScript, the same way that we're doing right now, but we don't compile them together. If we get over our personal need of compilation, we're actually going to have components. It should load. Yes. We're actually going to have components. We're going to keep components.  All right. So if we keep components separate, we don't compile them together. If we get over that personal need of compilation, we're going to have an actual layer of compiling components together or bundling components together. This is a front-end layer in my aspect. Now, I've worked already quite a long time in this way. And what I find is that one in three components we can actually reuse. And all of a sudden, the amount of blue is going to stampede over the amounts of red. And that's my dream. The dream for me is that we have independently teamed, functional, cutting-edge, triple front-end components by just keeping them separate. It's a very small notion, but it's amazing notion. Now, I could say thank you all for coming, but I'm not. This dream I had a year ago, absolutely a year ago, around the beginning of December. And I was dreaming about it at home. My girlfriend didn't really understand me. Well, anyway. I also dreamed about it at work. I dreamed about it so much. And as a freelance developer, they kind of figured, like, Mathieu is no longer working on the projects we're giving him. So we're going to fire him. Which is amazing news, right? Because they fired me a year ago. And in this year, I wasn't sitting still. In this year, I figured, screw it. I'm going to go for it. I'm going to dream this up. And I'm actually also going to build it. I'm going to open source. I'm going to give it to everyone. And the reason why I'm standing as a Belgian in Australian room right now is because I have the feeling that I cracked it. I really have the feeling that I fixed it. And one of the solutions is that we have to explain it well enough to front-end developers. And there is, we can't really rely on backend developers for that and seeing up the history. But this is how the solution looks like. The solution comes in three layers. And it also takes the shape of this horse. Funny story. I asked the designer, so the idea is called Componi. Okay. So I asked the designer, could you please make me a logo? And whatever you do, don't make it look like a pony. I'm really not interested in a pony. And he assured me that it's a horse. Exactly. Very frustrating. Now anyway, hopefully that's the only confusing thing. The very first layer I'm going to talk to you about is the new team structure. And the new team structure is there because we have to have a team structure that stops accommodating us as front-end developers to think in a blob way. And as soon as we can do that, all the rest is like children's play. Now, the new team structure is the very first layer. And I'm hammering on this because it's the only required layer. The other two layers are optionally built on top. However you want to use them or not use them, it's fine by me, you're still going to be able to use the Fundaments of Componi. Now, if my first assumption is correct, that you're going to like the new team structure, then I'm also going to assume that you're going to want to build all of these components in a very fast way. You don't want to have to rebuild and rethink your entire tooling workflow. So therefore, I'm also open-sourcing a tooling workflow for everyone to use so we can get this going really, really fast. Now, if my first two assumptions are correct, that you're going to like this one and this one, which I haven't really explained yet, then it would be selfish if you're able to create by default a lot of independent Drupal front-end components. You're going to be able to build them really fast and you're going to keep them to yourself. I don't need to explain the advantages of open-source and to this room. Look where we are. So therefore, I also invented or I created a platform invented. I created a platform where we can all share our components. Now, the cool thing is, as all three of these layers already exist, the platform is called Componi.io and from there, you can download the new team structure with the tooling workflow embedded into it. You can download it right now. Everything is open-source. It's free to use in the spirit of the open-source of Drupal. Now, the very first thing, the new team structure, first layer. It's the longest one to explain, but I think you're going to like it the most, too. If you go to the platform and you download the team, the team is going to look like this. You have three files. You already know these three files if you've ever opened up a Drupal 8 team. So an info.yaml file, libraries.yaml file and a .team file. You also have two folders and the three files, you can order those. They're going to be the same like any other Drupal 8 team. The first folder says essentials, helper folder, also not relevant for this presentation. The only relevant folder is the components folder. Why? Because we're going to accommodate you and not thinking in a blob way, which means all of the CSS, HTML, JavaScript, PHP or Twig that you're going to write is going to belong to a component. However, it means that you can still have your global component if you really want to. But you're going to have to see it as a component. Now, this is just an example, right? Let's assume that we would have three components in there. As we start working in the beginning, you're not going to have any teaming in there. If you download the team, there's no teaming in there. It doesn't do anything. It's merely a shell to hold a collection of components. Now, it's relevant to show you this because it's important to know that all the stuff you're going to write in the teaming layer, by default, you have to think and do which component does this actually belong. Now, very simple to explain, right? You have now three components. Very simple to explain this to a non-Drupal developer. If you go to inside a component, this is where it really gets interesting. Let's assume we have a status messages component. Then the first thing you should realize is that we have two layers. We have the root, and then we have the disk in this component. Everything in the disk is compiled from things in the root. It's very simple. The SAS file is generating the CSS file. This JavaScript file is optimized and linted and being put in that JavaScript file. This mild SVG is generating the SVG in the disk folder. Very simple to explain. The only two files that I haven't shown you yet is the library.yaml file and the status messages as html.twig. You already know these files. You already know what these do. Yeah, it's the first time you see them inside a component. Now, it's really cool to see them in a component because if you open up the library.yaml file from the status messages component, then it's again very simple to see what this does. It's linking to a CSS file. It's linking to a JavaScript file. And where is that? Where are those two files? Where they're just in this, right? It's completely self-explanatory. Again, super simple. No rocket science here to be found.  We have an html.twig file and there we define html.component, right? But what if we attach the library that we just created onto the html that we just written or we just copied from core? Then all of a sudden we, what we're looking at, and you didn't realize these three slides ago, but this is the very first completely independent Drupal front and component and completely stands on its own. It doesn't need anything else, which is super cool, right? Because Drupal is going to load in this html.twig file and it's going to load in and they're going to see, oh, we're attaching a library called status messages. Where is this library? Well, it's going to find it in here, it's going to open that up and this one is going to link to the CSS file and JavaScript file. And a tooling workflow is going to make sure your dist folder is always compiled, which is pretty wild, right? We have, we're looking at the very first completely independent Drupal front and component. It's wild in my terms. Anyway, tunnel vision. What are the advantages of this new team structure while they're close to infinite? Like, I challenge you to keep asking me questions after the session. I'm going to be able to bore you to sleep. There are so many advantages of this, but I'm only going to be able in these minutes to cover the most cool ones, I guess. One of them is conditional loading. I've seen a lot of companies. I worked with a lot of companies, a.k.a. I was fired by a lot of companies, and they all are working within their own system of trying to find out how they can build front-end components and have Drupal load them in conditionally. If you work this way, it already is conditional. Everything is conditional, because let's say, let's assume we all know what the views in for the scroll module does, and we have to know for that that it's going to use this html.twig file.  It literally doesn't care. It will never load in this html.twig file until click. You enable the module. As soon as you enable the module, Drupal on a page that it's going to need, it's going to say, oh, I need this html.twig file. It's going to find it in your components folder, it's going to open it up, and again the same thing will happen. It's going to find that library, and it's going to load in that CSS file. But only on the pages that that twig file is being used on. Which is massive, if you ask me. And this works by default. This has been working for Drupal 6 already, yet no one explained it to us well enough. Now, it also means that we have a big advantage for maintainability. As a Drupal front-end developer, I have written JavaScript, and therefore I have broken entire UIs. But what if, if you write JavaScript for Node article, what if you only break the things that you wrote the bug for? That would be pretty wild. You're still writing bugs, I know, but you could only break the entire UI on the pages that are actually using that JavaScript. Which is pretty cool. And that kind of brings us to performance, because if we only load in the assets as soon as we need them, performance benefits are huge.  For example, if you use, if you write a Node component, and assuming now every time I'm going to show a folder the inner structure of this component is the way how I explained it, then the Node CSS is only going to be loaded on nodes. It's not going to be loaded in taxonomy term pages. Or if you have a page component, well that by default is going to be loaded on node pages, and on taxonomy term pages. It just works by default. You don't have to do anything for this. And it boils down that one in 10 lines of your CSS and JavaScript will only be loaded on any page. One in 10. I'm not saying that I'm going to be able to optimize 10 percent of your assets. I'm saying I'm not even going to load in 90 percent of it. It's a 9 and a 0. It's massive. And my terms, this is enough to start using it today. Now, obviously I'm very biased because this is my presentation. Right? The other aspect of one of the advantages is flexibility. If you now think like, okay it all sounds amazing Matthew, but I'm not gonna do it. Like I'm just going to use a global component and you're gonna have to leave me alone. It's fine. Go for it. Only use the global component. And when you're ready and when you have some time on your hands to kind of go, I might want to reuse something out of my global component. Well, maybe you're only gonna abstract four lines of CSS. Maybe only one selector and two lines of CSS. And you're gonna create a library.yaml file for it. So you're gonna have a CSS only component. That's perfect too. You're already optimizing. You're already starting to start thinking in components. Or maybe you're going to want to create a HTML only component. And maybe that component is going to load in that CSS component you created earlier. Like it's super flexible in terms of how many libraries you want to attach. Or maybe you want to have a JavaScript only component. Or maybe an HTML and JavaScript only component. Or maybe an everything component. Whatever combination that you're thinking of, you're gonna be fine. As long as you stick to the fundamentals of the web, which is HTML, CSS and JavaScript. In that order. But you can tackle me afterwards. Now, we have loads more advantages. Kind of summarize them here. One of them is that we never have to start over. And that feels really good to me. Like they, we start on a new project. You can already start compiling things together. Not compiling, grouping things together from different projects. And also for a lot of business owners, this is very important. The reason why everyone is going headless these days is because we can't find Drupal front end developers anymore. Nearly everyone died off, to be honest. They all went to JavaScript frameworks or this new fancy thing. But if we, why are we going headless is because the teaming layer became very complex to explain. If we make it simple to explain again, we're back to building things for Drupal. We can again use the power and the strengths and all the advantages Drupal is already giving us in the front end. So it makes teaming layer incredibly readable for non-Drupal people. And if you in the last few seconds heard that I'm against headless, then you're not not right. I'm not against headless. I'm against people that take the deliberate decision of creating an entire super expensive project and rendering it completely with a framework of choice. I'm against that. I think that's really obnoxious and really not very, what's the word I used? I didn't write it down. It's just not smart. Because whatever framework that you're using now, you have the possibility of choosing a framework that is going to become the future Angular 1. You don't know. You literally don't know. Like, and it's fine to use it. I'm not against experimentation. Go for it. Decouple the components that you want to decouple and build them with those frontend frameworks. If you want to have reactivity, look at where that reactivity will happen in your website and implement it there. But there is a very high chance your static footer won't need to react to render. It's a very high chance. So experiment. Please do. I love experimentation myself, but only on parts. Do it on components. And working with components will give you that flexibility. Anyway, that's the hairy part of this presentation. I'm glad no one is leaving. Now, that's the first layer. That's the only layer that is required. If I get anything across, I really hope it's up until now. From now on, everything I'm going to explain is optionally on top. I'm going to start with the tooling workflow because if you already like the first part of this presentation, you're going to like the second part too. The tooling workflow, for me, I built it with Gulp. Now, how does that look? Well, it looks like the internet is gone. No, there it goes. If you download it, I actually lied 26 slides ago. You actually have an extra folder in the team. It's called gulpfile.js. Who, by the way, knew that you could have a folder named gulpfile.js. Random. Anyway, in there, all of the Gulp setup is built. You don't need to open it only for having a bit of configuration in there. Now, as front-end developers, we are massively... Let's go. We are massively opinionated. We rather quit our jobs, like I do, than to give up our opinions. And that makes us very interesting human beings, but also very good at our jobs, I think. It's a benefit. But it's also very hard, I found, to group front-end developers together and trying to make them work with the same tools. So, therefore, I made everything within the Gulp player optional. Literally. We have... I counted it on the way here. We have over four million different combinations that you can have. And I'm very sure you're going to find one combination in there for you. Every setting is divided up over project-specific stuff or environment-specific stuff. For example, project-specific stuff, let's say me and you are working on the same project. I'm using auto-prefixers, so I'm changing my CSS file to include which browsers. Well, you're going to have to use it too. Like, otherwise we're going to have different CSS files coming out of our setup. And then environment-specific things are there for developer experience. If I'm using Browser Sync that refreshes my browser every time I change the SAS file, it doesn't really impact the CSS that we're going to generate.  Now, four million combinations, I'm not going to go into them, but the way I'm going to show is that it's super easy to set up all the files that you want to edit inside gulp file.js and on config.js. Super simple. Local configuration, project configuration.  The amount of advantages this is going to bring is huge. Kind of features. I'm not going to go into what SAS compiling is. I'm very confident in the skill of this room. We also have auto-prefixing as a feature. We have losses, image optimization by default. We have browser syncing if we wanted to. We're lending automatically HTML, tweak, SAS, CSS, JavaScript, YAML and PHP. We're having JavaScript magnification, not the same thing as aggregation. It minifies your JavaScript. We're also doing, I think the next one is browserify and babelify for if you want to write cutting as JavaScript. We just still want to support older browsers. We have tree shaking. We have component-based multi-team compiling. I love how that sounds like. Component-based multi-team compiling. Give me a beat and I'm there. I'm going to go into this one. So it's component-based. What does it mean? Well, if you write page SAS, you're only going to generate page CSS. It makes it incredibly fast. Same thing for any component. So the Gulp setup doesn't really care about how many components you have. It's going to stay fast. And for that sense, the multi-team part, well, it also doesn't care how many teams you divide up those components over. Like you can drag out gulp file.js onto the root of your project and you're going to just link to which teams are component-based and you want to have the Gulp setup running in. Which is pretty cool, right? Component-based multi-team compiling. I dream about this stuff. Now, rebuilding Drupal cache. The Gulp setup is capable of rebuilding your cache whatever setup you have. Currently, a whatever system is ever going to be invented to support Drupal websites. How is that? Because the Gulp setup, you can, in the configuration, you can fill in the command needed for clearing your Gulp, for clearing your Drupal cache or rebuilding your Drupal cache. So for example, for Vagrant, it's a pretty old one, you could go Vagrant SSH and then ampersand ampersand and then cd to the web folder and then DrustCR, for example. So it always works, which means this is also now becoming explainable to a non-Drupal people. Because that's insane if you think about it. Like if you change an HTML.twic file, if you change the contents of an HTML.twic file, you can just sometimes have to rebuild your cache. We're not entirely sure. Like sometimes it's cached, sometimes it isn't. If you change the CSS file, that's never completely cached if we disable the right amount of caching. If we change a libraries.yaml file, well, yeah, you're gonna have to clear your cache. If you change the name of an HTML.twic file and you don't clear your cache, you're going to have a wide screen of death. Like if you know Drupal, it's very explainable why that is. But for front-end developers that don't care about Drupal, it's impossible to explain. So therefore we taught the Gulp setup how to clear your cache, which is pretty cool. For example, if you rename test.html and the testy component and you say it's new, well, you're going to get a notification that it's rebuilding your cache and if you wait four more seconds or however fast your local install is, you're going to get a new notification saying that it's rebuilt. It's pretty cool, right? Another advantage is that it's very refactor friendly. I've been doing the session now a few times, been traveling around a lot and I've met a lot of front-end developers, but a lot of front-end developers claim to be doing front-end development. A lot of back-end developers, I should say, are claiming to doing front-end development. But you're not, though. You're adding front-end development. It's almost the same. It's also as much fun. Don't get me wrong, but it's different. If you're doing front-end development on bigger projects, you kind of always have to keep refactoring. Otherwise, you're working towards a legacy project and therefore the tooling workflow is built to help you and keep refactoring. It's very refactor friendly. It's even helping you in many different ways. For example, okay, so this GIF I'm going to show you. It's video. It's even faster than the way I talk, so I'm going to pick it up one notch. If you have a component called testy, for example, and you have a nested component inside of it, testy variation, have a dist folder, we're going to duplicate testy.js. You're going to duplicate it, and you're going to see it appear in the first dist folder. Here we go. If you now drag this file into the nested component, it's going to be removed from the first dist folder, and it's going to create a new dist folder in there, and it's going to put the compiled variation of JavaScript in there. Right? Like, it's really cool. We have auto-maintained dist folder, so and it's even smart enough to know when to clear your cache in doing so. You can nest components, you can group components, you can rename components. Gulp is always going to be smart enough to know when to clear your cache. The only thing you have to get is you have to run Gulp. It's the only thing. It's pretty cool. You have loads more, but again, I had to summarize. You have a browser-syncing SAS globing, source mapping, Gulp setup that is capable of cross-component variables and mix-ins. It's also auto-cleaning up empty directories which can happen with Git sometimes, and the best feature of them all is that every feature is an option. You can literally disable every feature and it won't do anything, and I'm not sure why I'm enthusiastic about this. Now, again, no one left. This is going way better than all the previous times. So, when we have the first two layers, right, and my assumption is that you might like it because I see some smiles in the audience, that we're going to be able to create Drupal front-end components. They're going to be self-independent, and we're going to be able to make them really fast by default. Then we're going to need a platform on which we can collaborate together, because if I can drop my components from one project to another, I can also give them to a colleague of mine, for example. Let's assume I would have a job and we worked in the same agency, or we can also drag and drop them between companies, right? And that's the basis of an open-source community, and that's what I'm here to talk to you about. The open-source, we can do this within Drupal. So, why don't we set up a way that we can collaborate in an open-source manner? Now, the new platform to share, how does it work? It works very similar to how Drupal.org used to work before Drupal 8. You go to it and you download from it. So, if you go to Component.io, you're gonna have a big button where you can download the team structure and tools from there, and then you can browse the platform and you can download a set of components that would fit your project. Again, pretty cool. Everything is drag and drop, and it will just work. No, not this one, this one. The amount of advantages this platform gives? Well, a lot of them are very similar to how open-source is going to work, but in order to be able to take advantage of everyone's work, we're gonna have to make our components project agnostic. Let's say I'm contributing a component and let's say you, for example, is going to use that component. Well, my orange component is not going to work in your purple website, is it? Well, I will, but I will look hideous. So, therefore, we have to make or stuff that we contribute project agnostic. And making it project agnostic on the front end is a very interesting concept. For me, that means we're gonna strip away the color fonts and variables, because even if we don't strip away the variables in any project, we already have 15 different shades of gray. So, this would mean that, indeed, yes, we're gonna have a black and white component, but that's what you're gonna want.   You're gonna define some colors within the components.  Now, the platform is there to, for us, to be able to share information on components. What that means, well, if you upload the components, you're gonna get a detail page. For each component that you can find on the platform, it's gonna have a detail page. For example, this one is build upon Drupal core, status messages. The name is status messages. The building blocks is HTML and CSS. This is how it would look like if you would give it some color, for example, and a whole bunch of things, and you can download the components from there. So pretty straightforward. Now, how do we actually do this? How do we accommodate this way of working? Is if we want to collaborate on components, well, no. If we upload a zip file with your components, the platform is automatically going to give you a GitLab repository. It's pretty cool. It looks like this. Let's go. Every time each component has its own GitLab repository, which means you can inspect it, and all the tools GitLab is offering us, we're also going to be able to use. Go on. There we go. It's better. Like a Web IDE, for example, or maybe the issue queue, hopefully it's not gonna be this big for status messages. Now, this is where we start deviating from Drupal.org. You might think, oh, Metru's making a new Drupal.org. Oh, no. It's a bit more complex than that. Like I already said that people, as front-end developers, rather give up their jobs than give up their opinion, right? And I believe an opinion is a strength of a front-end developer. Not something you should try to generalize. If you look at Drupal.org, let's say the Views module, let's assume it's not inside Drupal Core already, then it's demotivated for me to fork the Views module, change one little thing and contribute it back as an entire new module. That would be ridiculous, right? Let me collaborate together. But in Component, that's different. Let's say, for example, I've built a project. Nah, I'm not gonna use my phone anymore. There is a lag. Okay. Let's say I built a project called Material Cookie Compliance. And that component is built on top of the EU Cookie Compliance module, right? It's a very popular module in Europe these days, completely voluntarily. We have a detailed page on this, but I've teamed it following Google Material Design. I'm not here to try to convince you that my opinion of Google Material Design as a design language is good because I know it's an opinion. And because I know it's an opinion, you can fork this and make a new variation of this. Maybe you want to make smooth cookies. Oh, my mouse is still here. Maybe you want to make smooth cookies. Why not? Go for it. I mean, you're gonna strip away the Google Material Design things from it. And we can collaborate on whatever opinion you would like most. And you can make as many opinions as you would like, which it will end up, and now this is still in development, all the rest is still there already. If you go to the project page of this EU Cookie Compliance module, then you could now decide which opinion you would like that module to look like. Right? It would be really cool. It also fixes a lot of things where Drupal backend developers are kind of stuck and not being able to update their front-end code. That's a different story. The platform also accommodates collections. For example, form item collections is a collection of components. Very straightforward. There's just a bunch of components that you can download in one go. And usually after my session I get this question like, oh Matthew, are you already completely building an webpack or are you completely switched over to post-CSS? How about React View, less anatomic design? Oh, Matthew, are you already, everything is already built on top of view, right? Whatever question you have, the answer is yes. Yes, indeed.  And I would love to know what you come up with and how. Because it's community-based enhancements. So whatever you would like this thing to evolve into, I'm there to listen. And it kind of sums up now, and this is the end of my presentation, that I'm finally being a proud Drupal front-end developer again. If you think about when is the last time you updated your NPM packages? Successfully. What's the latest version of your Node.js that you're using? It's usually embarrassing. Like, I didn't know for a very long time until I made this girl set up. Because we're all working into our own silos of our companies. And we're trying to get this best set up for our own company. Yet everyone is doing the exact same thing. And we're all doing it on Drupal teaming. So why on earth are we not working together on this? Right? We all love Drupal for its open source collaboration, yet the collaboration seems to stop as soon as anyone mentions front-end. And that's what makes me very proud to put front-end developer. Or think about the last time you had to run DrushCR manually. Now, the platform offers lots more nesting, naming conventions, extending conventions for PHP. Documentations on the four PHP functions you could use as a front developer. And we also have version control of components. And now this is the third to last slide. I'm really proud of this because you know the layers, every time like there's a different color. Right? And now, really proud of this one. Okay. So I'm going to show you a GIF now. There's going to be a green background. Like, it's going to be a browser where I'm going to show a local development of a fresh install of Drupal 8. I'm going to go to the registration page.  Because if you base it on top of Classy, there's just no teaming inside of it.  And then from there, we're going to evolve to how we could use the platform to make that better. So this, for example, is a default registration page. This is, scroll down, the output of Drupal set message. If you inspect that to see where it's coming from, well, it's coming from status messages. So there's a very high chance that someone already made this component status messages. So if you go to the platform, white background, the platform, and you don't want this component, then, well, it would potentially work. Right? So you download the component, you download that tar, you unzip it, and you drag it on to your components. I should have made that a little bit bigger. Go on, please. I'm gonna try to, should I try to refresh this? Go on. This is the crown jewel. One left. No. Wait. And I'm going to hotspot it. Hotspot. Okay. So no one goes on this hotspot, right? I only have four gigabytes and I'm nearly broke. So where is it? Here we go. Data is temporary. Can all guess the password? It's poetic. Let's go. Yes. Here we go. So we download it to the status messages component, right? We drag it over. Very good at that. And we get a notification that Drupal is clearing our cache, which is pretty cool, right? So you wait until the Drupal has cleared its cache. You refresh the page and now have a look at this. This is the output of Drupal set message. It's black and white. I know, but it's functional. It's responsive. You could ship this if you're not against the emojis. Which is again an opinion. Now, if you go lower on this page and you view inspect the next thing on this page that doesn't look good, well, that menu of login, creating your account, register, we all already teamed that before, right? We already know how that every teamer has to do that. So it's called menu local tasks in Drupal. And would we have a component? Well, yes. Well, I know that this would happen because I made this video. All right, it's my presentation. So you go to the detail page of this component. You see it's responsive. You see it's functional, too. So you download it. You put it in, you unzip it. You open up your finder again. You drag it to your components. Yes, you have to manually drag it. But guess what? It's the only manual thing you have to do instead of teaming it completely by yourself. You get a new notification that it's rebuilding. You wait until it's rebuilt. You refresh and now have a look at this. I know what it's going to look like, but you don't. I know already. There we go. And you can ship this. It works and it looks good. And it's a certain opinion that you're going to download. And it's functional, too. So if you make it responsive and you click it open, it's functional because the JavaScript in the series is attached to that one component. It makes a lot of sense. Now, I'm going to skip through. I'm now going to show you how we can download the entire form items component. I'm 49 minutes in. So I'm going to go, number two is leaving. No. Fine. If you download an entire collection and you drag it onto your project, again, the same thing will happen. We use all three layers. You refresh. Go on. You refresh. And it's themed and it's working and you can ship this. And I find this amazing. Now, this is the last slide. I want to close down by saying my name is still I'm still a freelancer without a job and a group of frontend if anyone knows anyone. And I had the absolute pleasure and the absolute privilege of being one of the organizers of Frontend United. And I say this now because it's very relevant. Frontend United is capable in the last four years, in the last year of organizing 15 events in one year. I didn't do all of that. The only thing Frontend United was able of doing is combining the energy of all the volunteers involved. So Frontend United is the sum of everyone involved. Componi is the exact same thing. And currently, that sum of people involved is one. And I would love, well, now it's already a bit more but that's kind of how I prepared these slides. I would love for people to get involved. So if you think, if you're nodding like, yeah, some things made sense. If there's any bone in your body that thinks, I might get behind this. Don't just nod. Join me. Tell your colleagues if you like it. If you don't like it, make it better first. That's open source. And then tell your colleagues. Invite me for presentations. I do workshops. I even do birthday parties if you ask me. Nice enough. But get involved however you want to. And please do reach out or ask questions using slido.com with the hashtag frontend. The next frontend United is going to be in Minsk the 1st and 2nd of May. That's in Belarus and Europe. Well, Europe. Yeah, in Europe. But it's also going to be in 15 different locations around the globe. Possibly also in Hobart. Who knows. So do pay attention to that. Thank you very much.


Good to see you all here. I think I'll start with have you all, are you anyone using Knative? Can we show hands? You're not using, but you have heard of Knative? OK. So, well, this is maintainers' track, so we would be talking about what Knative project has been up to, and we'll also talk a little bit about what Knative project is. And I'm on stage with my esteemed colleague here. I'm Naina Singh. I work for Red Hat. Paul Schweigert, IBM. Dave Protisowski from VMI. Boran Huss from Red Hat. Maurice Salatino or Salavoy, and I work for a company called Diagon. OK, so let's start with what and why Knative? So the short answer is, it makes Kubernetes simple. And the long answer is, it is an open source platform that enables developers to create, build, deploy, and manage workload over Kubernetes through an abstraction layer. And it can do that in serverless fashion. It's just icing on cake. So now, our next question is how? So with Knative functions, well, let me start back. Knative comprises of independent components that all work together really well. So with Knative function, it lets you create a function in two steps. And deploy it on your cloud or cluster. With Knative serving, you can manage your applications that can scale up and down based on demand. It also provides you traffic splitting. That means you can test some particular new feature without disrupting your users. And with Knative eventing, it allows you to create declarative event-driven apps that can respond in real time. So to sum it up, Knative provides developers, or could we go to tool choice for developers to create, build, manage, workload of container-based applications? So I gave a glimpse of what the independent components of Knative are. But here they are. They're serving, eventing, and client. And we have a CLI that ties it all together. And we are going to go a little bit more into what these components can do. But serving is, I call them, that auto-magic HTTP services. You give us a container in one step. We give you the URL. Knative eventing is basically a whole gamut of tools or infrastructure, if you will, that allows you to create event-driven apps. And Knative functions that lets you bring your own code. We provide the project scaffolding, the templates. And we even take off the building of the container off of your list and gives you the URL directly. Knative is built on the plugin architecture. So as you can see, what it means is that you don't need to do something specific for Knative. It can work with the stack you have. And for serving, eventing, and functions, it is listing on the slide as to what technology it can work perfectly well with. And with that, I'll give it to my colleague to talk about serving. So serving, we said it's auto-magic HTTP services. Basically, if you're running an HTTP application on Kubernetes, there's a lot of things that you may not want to have to deal with that Knative can do for you. So it makes it easier to run HTTP applications. So for example, we can scale your application based on the number of requests that are coming in. So you don't have to worry about how many replicas you want based on how many you can set a concurrency level, the number of requests that are coming in. We can scale it up to meet that demand. We can do that automatically. If you want to do a rollout based on a percentages of traffic, we have a capability to allow you to do that. So you can give a traffic percentage for the different rollouts that you have. We take point-in-time snapshots of your application. So if you make changes and need to roll back, it's very easy to do that to exactly what it was you don't have to worry about. What did this Docker tag reference, that kind of thing? We do it. We make an exact copy of the configuration and your code that you can roll back to as needed. We add automatic health checks and automatic TLS provisioning. So a lot of tools that you can use to make things easier. And the nice thing about this is you can go from, you know, there's a lot of YAML that's required in deploying an application. You need a deployment. You need a service. You need an Ingress. With Knative, you can cut out all these little pieces. And you go from that behemoth on the, whatever this side is, left, audience left, to what we have on audience right, which is 10 lines, give or take a little bit. So it makes it easy to deploy applications. And with that. Hello. So some recent highlights is, this is stuff I've been kind of personally working on, trying to improve the stability. One of them being like, not dropping requests during upgrades. And then we also have this activator component that is buffering when your revision's scaling up, but it can take some time for things to do that. So then you want to buffer those requests. And when that goes in between the data plane and comes out of the data plane, make sure we don't drop requests when that happens. You also did some expansion for timeouts. So if your scale to zero and then activation fails, then clearly you would like to have a timeout there. And also per revision request timeouts was kind of important to add. Especially for like WebSocket workloads, you would want to set the timeout to be very large. And then also kind of set, for example, like kind of like the idle timeout. One outstanding bug we fixed recently was like with cert manager, there's a limitation on the domain length that you could do. So if you have really long namespace names or really long service names that is now fixed with sort of auto TLS. And something we've been focusing on is some security aspect stuff. So security guard is sort of like an extension that lets you apply some policies to requests that are coming in, aka like don't let reject certain headers, don't allow certain query params, kind of allow the operator to apply certain policies that way. And we kind of also finally took, change the default domain. We're using example.com everywhere. So when you do deploy, it would actually expose your ingress on that domain which doesn't exist. But we decided to take it more secure by default stance and make it cluster local than letting people expose domains after the fact or letting the operator do that. And for the roadmap, there's a link there but to highlight internal encryption is sort of a thing we're working on now. The reason why is cause there's PCI and this compliance is useful. You need to have like the data plan to be encrypted. A big project that I want to work on and it's been a while, we still use open senses but open telemetry is hitting GA for a whole bunch of their specs and libraries. So we want to migrate to that. Gateway API. So like Nina mentioned, we have like plugins for the different networking layers. You can switch from Istio to contour, et cetera. Each of those requires essentially like a special plugin. We want to opt out of that. And we just want to program the networking using the gateway API directly. And with that, I'm spending time in the upstream community there trying to break gaps, get positioning so that K-Native use cases are heard. So people use K-Native and want to use the API. Go look for those gaps and comment please. And finally like just more scale and testing performance. The serving API has been stable for like two, three years. And I just want to do scaling tests and things like that and improve the performance cause there's definitely some things to do. So I'll hand it off. So let's then go to the second pillar of K-Native which is K-Native eventing. And K-Native eventing is all about for creating event-driven applications which means you have get primitives for building up an event mesh. And in the center of this is the broker. As you see there are entities so everything is reflected by CRDs behind the scenes. And of course there's a control plane, a data plane who picks it up. And actually there are two main concepts of one of that of a source where you get pick up events. It's important to note that these events are in the form of cloud events which is also another CNCF standard. So actually these sources that create these cloud events are more like adapters that pick up events from the outside world like event from S3 bucket if there was a file change creates a cloud event and then sends it on to the broker inside. And the sources are connected to the broker and the broker is responsible for dispatching all these events to interested listeners. So you can have a K-Native service for that of course which has the big benefit that the service is not running so it's scaled out to zero if there are no events so it's perfect fit together so that if you use eventing with serving you can by the way use serving and eventing completely separately so there has no dependency between both of them that you can use either serving or eventing or of course both which makes totally sense. Yeah interesting is you have a flexible way how you can register your applications to the broker with so called triggers. The trigger itself can have filters where you just specify which type of events you want listened for. And also interesting is that your service then can return another event as a response so it's all everything is HTTP driven here. So you get an HTTP request with a cloud event your service returns another event which yeah cloud event this is then ingested into the broker again and dispatch to the other one. So you can really build a very flexible mesh with that and of course it doesn't have to be a K-Native service you can use a regular deployment so everything that has kind of a we call it addressable has a URL in this status can be used as a target for such an event. Yeah and then finally there's one interesting part that we're currently working on or kind of reviving the effort so it's about event discovery because you need to know which kind of event types are available in your system so every resources creates events of a certain type and this registry can be used for lookups and so that you can find out how you, where I can register just on this events. So this is kind of a nutshell what the eventing is all about. Now let's move on the recent highlights and also the roadmap. So one of the things that has been landed in a K-Native eventing recently was multi namespace API server sources. So I have to say that there are several sources that came out of the box with K-Native. API server source is one of them. This is just a source which runs constantly and listens to the API server and creates cloud events out of API events like that.  Now you can use a selector to select multiple namespaces and get that. So this is kind of a new thing. Another thing is the broker. I haven't mentioned really how the broker is implemented. You can by default there is a very reference broker so to say which stores all the events that are played within the memory of a process. So it's probably only suitable for development. But for more production ready systems there are other backends like Kafka or RapidMQ that you can use and plug in and also get more resilience features for your events. And for Kafka there is also now a way to scale up your broker and also your Kafka source where you import Kafka messages from a topic into the broker by Keter. So who of you know Keter already? So okay, some of them, that's nice. Because Keter is also a very interesting project and actually you often get the question whether this is kind of competing with the Keter but actually Keter and Keter are really complementary. So Keter scales on HTTP based load and Keter scales on everything except HTTP. So it scales based on number of messages in a queue for example and other stuff. And here we can use Keter really to scale our infrastructure data plane so that really the broker is only running if there are really also events in the system. So this is very, very nice for cost saving as well. And yeah, so these are kind of the highlights and then there's a roadmap. You'll find by the way, all the roadmaps that we're showing here also on Keter because they are all stored in Keter projects. You can follow those. So we are now focusing on production create features like security, connective TLS support out of the box which means we can already kind of use Istio and another service mesh for creating, for securing transport security. But actually there's also the need for some native support for TLS. We're working on multi-tenancy support which allows you to run multiple tenants that are separated by each other for events. Or IDC, so integration with Istio is also a topic so that you can really nicely play together with a service mesh. Or IDC client author report is used for to authenticate the sender to a broker because at the moment everybody can send to a broker or call this is not optimal. And therefore we need some authentication and authorization feature to understand that we can restrict the people who can send to a broker there. And finally, as I mentioned, event discovery is something which we also continue to work on to make it more flexible and so on. These are the roadmap of the eventing. And now let's move on quickly to next one. So this is kind of a interlude. It's actually a client. This is maybe you don't know the client well. So the client actually is a CLI for connective like cube control. Of course, everything you can do with custom resources, but sometimes it's much easier to have some typed interface or you can interact with your cluster. And their KN is very helpful. So you have this kind of CRUD operation that you can use for services for brokers. You have a flexible plugin support which allows you to extend the functionality of KN. We will see functions in a second which leverage at this plugin support. One special thing which is different from cube control plugins, actually it works nearly the same like cube control plugin. So the external command that you can run, they are found by a naming convention. But you can also inline them. So if your plugins are written in Golang, you can also put them during the compiled process within one binary and we have a builder system where you can select the plugin that you want to have. The benefit of this is that you only have a single binary where all your plugins are already included and so you can easily distribute it. And recently we have also now entries on artifact hub which is kind of a way to discover plugins and you can install plugins either directly by downloading it from our website or using some other installation mechanism. On the roadmap, there's one big thing which is plugin content sharing which means we want to allow that plugin can transport certain information to other plugins. So this is a little bit complex to describe but this is useful for running your plugins and so to make it more smoothly and make the user experience better. Then other user experience improvements are about event discovery. So the way how you find events and also automatic trigger generation when you want to integrate functions so that you can combine them. And finally, secret management is on the table and also improve the export. We already know how to export canative services for GitOps like operations so you can interactively create your service with CLI and then export it with a YAML file. Yeah, so there we are and that's so far for the client. Now let's go to functions. Let's talk a little bit about functions. So both clients and functions are CLIs but in functions we are focusing more on the developer lifecycle and we are focusing on that programming model of creating functions. How many here are like developers? Okay, yeah, okay. This kind of section is more on this client side, right? How do you consume Knative? And functions are created in the mindset of people that already has Knative for example, serving and eventing installed in their clusters. It could be serving, it could be eventing but now we are kind of more on the client side. And what we're trying to create here is a simple flow where we are abstracting away a little bit about like that our functions are going to be running on Kubernetes. So this is for developers also for platform builders that wants to provide like functions as a service experience on top of Kubernetes. So with Knative functions what you do is like you have the funk KN plugin or the funk CLI that you can use to basically create a function from a template. You can create that function from a template that can be in any programming language. So we have templates for different languages. And as soon as you created the function then you can just go and add the function logic in there like the developer will go write the function logic and then using funk deploy they can have that function running in a Kubernetes server with Knative and of course you will get the URL back to interact with that function. It's pretty simple. It's based on templates. The idea here is to avoid developers thinking about exposing ports or creating a web server so people can access their functions. We are just wrapping all that logic up. And it actually we have different templates for dealing with HTTP requests or cloud events. So if you are building more like an event driven system you want your functions to consume cloud events. We have some templates more specialized on that. And the idea here is also like try to again go one step further into removing all the developer tasks like creating Docker files for creating containers for their functions and all that stuff we are trying to hide away behind the funk experience in general. So when you want to build a function and deploy a function the idea here is that the developer will focus on writing code and the funk CLI will build a function container and it will also know how to deploy that function into the configure Kubernetes cluster. The function this is just kind of like how a function, very basic function template looks like. And again, when you do funk create a function you can specify the language that you want to use. So all these kind of like run times and text tags supported. So no, the Spring Boot, Rust, TypeScript, Python, Quarkus, and Go, right? Like this is the Go one. And as you can see here the function signature it's pretty simple. In this case it's one of these functions that it's expecting an event. And in this case it's a cloud event that's why you see the import there. So this function, whenever we call this function this function is going to actually get the cloud event, parse it, and have that event into a Go struct so the developer can do something with that event. And it can also return an event as you can see there. So this is pretty simple. So a little bit about what we are doing it's like the functions are working group. It's pretty active in a way that we are looking into not only how to improve the developer experience but also our target users are platform engineers that are trying to build these platforms. Pick up any functions and build an experience on top of it. So there is a lot of work around finding the right abstractions for platforms and making sure that we are not leaking anything from what is installed in the cluster into the developer experience. For that we are working on something that it's like a new scaffolding mechanism on how do we create these function templates and what kind of capabilities to enable developers to have out of the box and extend. So that's one part, then pipelines as code because we need to build these functions somewhere. If you try to build the functions locally of course for the thing that we have today like the last release, you need to of course have Docker locally so you can actually create a container. The user will not be interacting with Docker directly but the fang CLI will actually use the Docker demon to build the container. But we also have different approaches. So we can, if you use for example we have something that it's called on cluster build that was created by Svinak here that basically allows you to run tecton pipelines in the cluster. So if you have tecton installed in your Kubernetes cluster what you can do is you can say fang deploy and the build step it's going to happen remotely in a cluster which makes a lot of sense again for platforms, right? Like when you want to say, okay I don't want my developers to have Docker installed in their laptop, company policies or maybe because they don't have access to a registry like a public registry or the credentials for that or whatever you can just start using these remote builds kind of like approach. And then there is a project that is called pipelines as code which provides a more flexible way to define these pipelines that can be run remotely. So we are integrating with different technologies to do that. We are also looking pretty active at creating wasn't functions as well. That's not something that it's supported in the latest release, but that's something that we are kind of investigating and trying to include. And I'm also working a little bit on the dapper integration. I work for the dapper project as well. So kind of like making sure that we make our functions like dapper enable which basically means that when you want to access to generic infrastructure like storing data into a database or sending messages or like reading secrets and stuff like that, we go through this other abstraction layer. Again, from the functions perspective that should be completely hidden away from the user if the user should have some kind of like default functions and the function interface to interact with that. So what I wanted to show like in a quick demo today I don't know how much time do I have I have some minutes, okay. So yeah, yep. So I will finish quickly this. So what I wanted to show is like this new scaffolding mechanism that it's being created by Luke from Red Hat which is again like going through the investigation and the analysis of what are the lines like the boundaries for function developers and what kind of things the platform should be provided and what kind of behaviors for our functions. So we are taking kind of like a different approach from the one that we have released today. And this investigation is proven to be like very, you know, very eye-opening and mind-expanding. But yeah, I think that we are actually into the right track. So I will try to show something like that. It's very difficult if you don't know the functions project but I will just try to explain the logic behind the changes. With this new approach, with this new approach, we can actually run functions locally without the need again of Docker. If you want to create a local container for your function and run it using Docker you can also do that. We are looking into what are the, to define like more specifically what are the functions interfaces and what's being provided by the platform. And now we have kind of like this concept of instance-based functions, right? If you see kind of like this interface here, we will be creating kind of like, this is like static methods, right, like on go. So basically every time that the function is being called we are executing this method. But if you have like some initialization code or some shutdown code that you want to run or for example, if you have like, if you need to add like to your functions, liveness and readiness probes that are a little bit more custom, you need to have more control on that. And with our current approach, that's not that easy to achieve. So we are looking into expanding that. And of course, like the thing that I mentioned before from Dapper. So let's go to a short demo that I will try to show here. Let's see, yeah, I think it's going to work. Yeah, perfect. So let's do this. Let me see if I can see my screen. I will go here to my BS code where I created a new function that it's been scaffolded with the new method that we are working on. So this is based on a branch. Can you see the function there? Yeah, so as you can see here we have a little bit of a different function signature in this case. And as you can see, we are already part of a go struct here, like we're part of something. So this is kind of like a way to create like instance based functions that they will have some kind of context that we can use. And because we are now part of a bigger scope, right, like this is not a static handle method, we can start doing some other initialization code or for example, readiness and liveness props. We have before like the approach that we use with the static method approach is like we were wrapping our function code into a web server that was started with a bunch of default endpoints like for example, default liveness and readiness props. But again, if you wanted to extend that base layer that wasn't that easy, you need to provide your own base layer and that gets complicated. With this new approach, let me show you first how does this look from the terminal. Let's see here, let's clean the screen. Let me see if I am in the right place. Yeah, so I'm inside my function. The function is pretty simple. It's just a go project with the func.jambl file that described what the function is doing and the programming language and some other details. And as soon as I have these I can actually do something like func deploy. And this is going to actually build a container. In this case, with this new approach, we are not even using a Docker demon to build a container. We are using a library just that creates that. And by the end of this command, what we should have here is a URL for the function, right? So I went from having a function that it's written locally and it was created by a template to deploy this into a Kubernetes cluster where K&AD is enabled. So I can actually do HTTP and that URL. Just to make sure that it's actually running on my cluster. And there you go, so we can have the request received there. That's the most basic function that you can create. The function that comes out of the box from the template. But again, if you want to start customizing the lifecycle of the function, what you can do is you can start enabling, for example, some of the lifecycle methods that we have here. We have the readiness probes, so this is the function. And again, what I wanted to show here is that ready now, this function that is here, that it's part of my function struct, it's actually providing one of the lifecycle hooks that we provide, right? Where you know that when you deploy something into Kubernetes, you need to actually make sure that the cluster understand that this container is ready and it's actually already working and ready to be used. The same with the alive function here for the liveness probe, right? A more common use case as well is initializing code in the previous version. If you wanted to bootstrap or load some libraries or doing something before calling the function code, you need to do that per every call, but in this case, you have a stat lifecycle method that you can extend and you can plug in and do that. So we are trying to expand, again, like the function interface. Before, we didn't have a very strong interface. We only had the function signature, but now the function interface of the lifecycle methods that you have gives you more control to do more use cases, basically. This was one kind of on the major request. So if I do fun deploy again, I don't know if I saved the file, hopefully yes. But again, I would now should be able to see that the function has this custom liveness probe and readiness probe, which sounds like super simple, but again, when you are building real life applications, you will need to extend that based on the other services that are available, the databases or whatever that your function is consuming. So if I do logs, the function deployment, you can see that, yeah, okay. So it's now calling those custom endpoints in this case. And the same kind of for the starter thing, that's where you do all the startup stuff. I will finish the demo with something pretty simple and this is just something that we are evaluating. As you can see, the function doesn't include any dependency here, which basically means that all the methods here, like start, ready, or alive, or whatever lifecycle thing that we want to expose in there are part of the function signature. And that allows us to, for example, do some other stuff, like adding methods for saving data or emitting events or reading secrets, or even like communicating with the workflow engine and starting some business processes and stuff like that. These kind of signatures basically, the idea here is just to have a clear signatures to execute certain behavior without pushing the platform for a specific implementation on how do you actually implement that functionality. But in here, what we are doing is we are trying to give the developer the tools that they need so they don't actually need to worry about adding dependencies to a database or adding a dependency to a message broker and that kind of stuff, something that the K&A eventing project is also doing. And that's pretty much it. When we run a K&A function, so I also want to show here functions, case we see, let's see, that's a K&A service. You can see that it's running on a URL but if I list the POTS as well here, well, the function is no longer running. There you go, I will just call it so I can see it running. So yeah, as you can see here, we have the K&A proxy running in there but also right now the function project added that like dapper integration so you can see that it's injecting kind of like the dapper side that gives you access to all these infrastructure methods to do extended stuff. So yeah, this is kind of like the experiment that we are working. If you're interested in this topic or if you're a platform builder thinking about providing a platform as a service experience, we would love to get your feedback. If you are a developer and want to help us to create more templates for more advanced use cases, that's more than welcome. And I think that's pretty much it on my side. Yeah, is there any, yeah, I think that we are done with that, right? Like questions? Five minutes for questions. Yeah, we have a question here. Yeah, are they ready? Yeah, actually this is a very great talk. I like the updates. I do have a couple questions. So actually the first question regarding the KNIT function. Yeah. You mentioned the one upload code and on the line, the KNIT has gone to build the image in the end and to run the function. My question is, does that will impact, I mean the performance and increase some latency? Have you guys considered directly to run the source code in some bad manner instance which may have the performance which is maximum? Just wondering the syncing here and because in the middle layer, I know the underlying is running on ports, so the building image may be the one for the step, but in the future have you guys considered to make it more straightforward like directly to run source code and make the speed is pretty up? Yeah, so because remember that we're running on Kubernetes and we're running on top of KNIT, so we need to create a container. I think that we cannot escape that except for something like Wasm, right? We can just run Wasi to create Wasm functions and then just deploy that. That's like under current investigation and that will add another way of deploying functions. So Funk is really good because it actually, it's very pluggable, so you can say build functions in this way or deploy functions in this way or run functions in this way. Go ahead. Let's just add that if you're developing locally, you don't need to create containers, you can actually, let's say for example, if you're using Node.js function, you can use the NPMJS and all that stuff to do your local testing. Oh, that's very nice. Yeah, so the developer experience on your local does not need to be in container, so we provide that local tools for every language that we're supporting. Got it. And the second question is I do notice there's couple of patterns the KNET provided, especially the function and also serving and the event team. So if the user come to the KNET sometime and they want to like, solving some like a website or different using scenarios, which for the amount is multiple patterns is any recommended for users first to choose which one which is, can they most fastest to adopt their use case and is any recommendation or just depends on. Because I think it's mostly like going to serve, right? Usually we see, we see serving more. Yeah, I think like what's interesting about KNET is you can use different components independently. So like being at the booth, I heard some people using eventing but not serving. Some people using serving but not eventing. And interesting enough like you could use functions just to build containers that and then deploy them somewhere else. Like you don't, in using deployments and things like that. So I think there's a composability to all these components that like hopefully like using them together is greater than just using them individually. But I think the choice of what components used will depend on the use case. So I can't really maybe answer that unless you have a specific use case is my guess. Got it, got it. Yeah, lots of questions actually. Sorry I take too much time. I saw the KNET if it's kind of kind of related to more like serverless. So, but I know CNSF today doesn't have the service stack. So I'm wondering is there any plan especially in the future roadmap? I mean, do you have something around this area because I had a discussion yesterday with top TOC members and I am trying to see whether there's a chance to building a tag for serverless specifically. Right now there's not only, I think there's lacking this tag. So just wondering is any plan and any source here on your roadmap in the future vision to better align with the CNSF stuff? I would say if you form a tag around this then please include us. That sounds great actually to have a discussion. So you kind of fell into at least serving to the like the runtime tag but there's so many runtimes and it's interesting but like it's nice to have I think like a use case focus tag in this type of environment I don't know if anyone else has. Yeah, let's know the tag, yeah. We are out of time. Get a sign, but maybe if you have questions, sorry to be come to the front and thank you very much. Yeah, go outside.


So, in this module, I'll talk about the client side web database programming. If you recall, I showed you a diagram in the previous slide, what things are done at the client side, and what things are done at the server side. The objective is to bring the databases on the web, right? And what we need to do at the client side. So, we need to develop, do some coding at the client side, right? And we need to use some external application also there. But remember one thing, that the client has to be thin. It is advantages to have a thin client. So, we cannot do a lot of programming work at the client end. We can have interim solutions, but they are not good for a long-term approach. So, let me go into more details. So, what is used typically at the client end, or what is used, the programming done at the client end, which will facilitate, which will help, or which will all together bring a traditional client server database application on the web. Remember, try to understand what I'm saying. That what I need to do at the client side to bring a traditional client server database application on the web. That is an interim solution. That is a quick and dirty way of bringing the database on the internet. It has its issues also. So, I'll be discussing those issues and the performance for each of these programming techniques. Not the techniques, but the techniques and tools also, which is JavaScript, which is a scripting language, ActiveX controls, which is for the Internet Explorer, Plugzins and external applications. Plugzins are, remember, they are dynamically linked libraries, DLLs, which you may have seen or heard. So, JavaScript, JavaScript can be used and is used for creating and customization of the interfaces to an application. In the context of the database, remember one thing that it is not a binary or running something which in the binary mode, it is interpreted at the client side. Of course, if the client has allowed the JavaScript to run, JavaScript can be used for mathematical calculations also. For example, if I enter my date of birth, instead of going to the main server, JavaScript can help calculate my age. Or if I would like to do a conversion into units or other things that can be done using JavaScript at the client end. And of course, JavaScript is also used for validation. Validation means that if I enter an email address, then the email address should have the necessary add sign and other domains also. So, this is some of the applications of JavaScript. The main advantage of JavaScript is that JavaScript needs Java plugins. JavaScript cannot do something without Java plugins and CGI. Common gaze gateway interface protocol based upon which we have a CGI script written in C or C++ or Java, which will facilitate actions, retrieval, writing on the database without a three-tier traditional web-based database application environment. So, with JavaScript, you need to have plugins. Performance, that is the key thing, sending the final action. Instead of going again and again to retrieve something from the main server, the web server, the database server, a collective request is sent which gives good performance. But remember one thing, since everything is dependent upon the client, the state stored at the client is maintained at the client. Therefore, if the client exits, the session is lost. The state is lost. That is not a good approach. It is an approach, a quick approach, but not a good approach. ActiveX. What is ActiveX? It extends the capability of Internet Explorer and it adds functionality. This functionality will help in accessing the data in the database, okay, using client and programming, client and programming, not the server and programming. Server and programming for doing all these things is the correct approach. And there are more than 1000 controls, maybe more, which adds functionality to IE Internet Explorer, which includes the controls for database access also. And it is very powerful because it also has most of the Windows functionality, which means that using IE, I can actually go with the plugins with the IE. With ActiveX, I can go to my hard disk, access the files, even save the files so all or most of the Windows functionality is there in ActiveX. And with the performance, minimize the network traffic. Instead of sending everything to the web server or to the database server, it sends, it collects them, collects and then sends that reduces the network traffic. The control information is collected and sent, reduces the network traffic. As a consequence, the performance goes up and offers a rich graphical user interface also, okay, and this will give good performance. Performance in the sense that I can work better, not in the sense of CPU. CPU performance with reference to network traffic, I have already mentioned over here. What are the plugins? Plugins are DLLs, Damage Link Laboratories. They also add functionality. ActiveX adds functionality, JavaScript adds functionalities, DLL adds functionality, but there are certain issues with the plugins. You need to install them at the client side and it's not possible to install these plugins in at all the clients. If you do it is very expensive in terms of time and money, it's not practical. It's not feasible, it can be done, it's not practical and feasible. So that is not a good solution. Using plugins, add the client end programming for database access. And it's also platform dependent. It means that the plugins in which I prepare for a certain platform, they are not likely to work on another platform. So I have to do that work again. ODEVC Open Database Connectivity and Object Linking and Embedding, I'll be talking about in more details in the subsequent sections. The point over here is that these plugins are loaded on demand. Loaded on demand. They are there, a person has registered for those plugins. And when the plugin is required, then the plugin is loaded in the memory. As a consequence, they are not preloaded in the traditional way, because preloading will incur the cost of loading and occupying the memory also. They are not preloaded, loaded on demand. And they're written in native code, binary. It means you'll get good performance. Unlike JavaScript, this will give good performance. And finally, I have these external applications. They can be new clients. They can be legacy clients. These are interim solutions which are at my client and at my PC and which help in access this database. Help in accessing database. Okay. These are on my PC. These are the plugins. But the thing is that they are hard to maintain. I have to change it at all the client. I have to reinstall it at all the clients. This is not feasible, like in the previous case. But the benefit is that there's no repeated connection. Why? Because it is stateful, traditional client server environment. It is stateful. But all of these solutions, JavaScript, ActiveX, plugin, external applications, they require a FAT client. It advantages to have a thin client. These are interim solutions, quick and dirty approach to bring your database applications on the web. In the next module, I'll talk about server and web server and programming. Thank you very much.