Everybody thinking about, well, I need to have a healthy life, not earning our new generation, young generation with a very sporty person with those wearable devices. It is actually our elderly person, our chronic disease patient, and our sub-health population who has strong needs in healthy lifestyle with good health care management solution. But who will be the one to provide us the health care management solution? Some people talking about self-management. But in the health care area, actual self-management is not good enough. We need support from the professional team with senior doctors behind it. This is our user trust it and looking for. But where's our senior doctors? Senior doctors are stuck in major hospitals, especially in mainland China. So you will see the situation like this. Why this happened? Because patients trust senior doctors. Cognitive disease patients go back to the hospital very frequently, which is not necessary. So we cause our senior doctor 80% of the time handle the chronic disease patient. And this is the key to change, to change our patient distribution. We should let our senior doctor see more, focus more on the severe cases and reduce the number of chronic disease patients revisiting it. But how can we do this? We have a new health care service delivery model. So the senior doctor, made with the chronic disease patient, he gave the suggestion on how to conduct health care management outside hospital. And all the vital sign information monitored outside will be transmitted wirelessly back to the hospital. When patient needed, he can talk to the doctor via mobile apps without going back to visit their doctor so frequently. They need a lot of technologies to support this.  So here I just give you a very simple example. In China, actually there are more than 50 million of users are suffer from SNP apnea. And due to the very inconvenient way for diagnosis, 90% of the users are missing their most suitable time for treatment. Well, what we can do actually provide you a very comfortable solution. You have wearable device at home. You sleep at home in a comfortable environment. And your SPO2 value will be monitored when you're sleeping. And once the SPO2 value dropped to a certain level, which indicate SNP apnea happened, and this will trigger the alarm. And the alarm information will transmit wirelessly back to the doctor. So doctor, who is now in the remote sleep center, can find out all this information and take the action accordingly. What kind of action he can take? The very interesting observation we have is your pillow actually is magic. The shape of your pillow actually will affect the sleep gesture of the user. So if the pillow's shape has been changed, you always open, the apnea situation can be elevated. So with this very nice observation, what the doctor can do is, sitting in the remote sleep center, find out SNP apnea alarm happened, and help you adjust your pillow you have at home wirelessly remotely in his sleep center. And bring you back to a very comfortable situation.  OK, so this idea not only apply for SNP apnea management, but also for various type of chronic disease management and also the wellness management. So with the daily monitoring and management for people's health information, so we all have a much deeper and accurate understanding of our user. So many personalized recommendation services can be enabled. When you are as a patient, the service will tell you what kind of exercise you can take. When you're trying to take medicine, the service will tell you, well, with this medicine, you cannot eat with a certain type of fruit together. When you're trying to order a pizza, the service will tell you this type of topic is not good for your health. So all of this will bring us a really very healthy lifestyle.


With forward pay from Appalachian Wireless, you'll avoid contracts and credit checks while taking advantage of some awesome perks, like unlimited talk, text, and three gigs of data for just $44.99, or with five gigs for a mere $59.99. Forward pay. That's today's Appalachian Wireless. About a month out from the presidential election, Senate Majority Leader Mitch McConnell paid his 30th visit to Pikeville to speak to the southeast Kentucky Chamber of Commerce, and heavy in the discussion at Tuesday's event was the election. McConnell, of course, favored Republican candidate Donald Trump in his remarks, but he also acknowledged that the election is far from decided. We have long odds because we have a lot of exposure. So I think it's a 50-50 proposition, and we're hoping for the best. But McConnell's most extensive remarks, of course, revolved around coal and the Obama administration's perceived war on coal. They cut coal jobs across the state while raising electricity rates by double digits, and the most frustrated thing about it, all of it having zero impact on global emissions. You know, I don't have to remind you that we've sort of fallen out of favor with sort of left-wing elites in the country. But I tell you, I'm proud to represent this state, and at least as far as our votes are concerned, I think we're likely to send them a very strong message next month. McConnell joined the two topics by saying he is confident in Donald Trump's support of coal, and he said coal has a future. Mr. Trump has made it very clear he's pro-coal, and if he were to be elected, I think we would be in better shape unless Hillary Clinton has a different point of view after the election from what she expressed before the election. Coal has a future. The question is whether coal has a future in this country. The Germans are now importing coal. The Chinese are still building coal plants. Coal has a future. The issue is, does coal have a future in this country? McConnell filled out his remarks by detailing actions he's taken in Washington to make eastern Kentucky's voice heard. During his time in Pike County, he also visited Coal Run Village for an event, but media was not allowed to attend. Reporting in Pikeville for EKB News, I'm Chris Anderson.


Yeah, so my name is Brian Weinstein. I'm a solution consultant here at workado on the embedded platform team. And so today, I'm going to be talking about the embedded platform solutions offering, solution offering, right? So what is the embedded platform? What does it do and how it can help you and more importantly, your customers integrate and automate their different applications together? So a little about workado just before we begin. Workado is a market leader in integration and automation space, powering mission critical business processes for some of the largest and fastest growing companies in the world. We are really humbled and thankful to our over 7000 now customers who have entrusted us with their support in this journey. So our earlier sessions of workado kitchen have been focused on achieving automation to scale for many of our direct customers. But today's session will be focused on another segment called the embedded platform, which targets top B2B SaaS companies and product vendors who want to leverage us in their integration and automation journey. So adding to the large set of direct customers as an embedded platform team, we have been seeing really, really large stagger honestly, staggering growth in the last 18 months. Being part of this embedded team, I'm really excited to show you today how we can help you on that integration journey. So as an application vendor, why would you be interested in this embedded integration and automation platform? The reason is that there's been a massive explosion in app usage across all major lines of business. And we've been seeing a 30% increase in SaaS apps used by businesses. So even in a single business use case, there can be many applications that need to be integrated. This means that customer information is spread out across many different applications and it becomes a necessity to have access across all these applications and share data between them. And this is becoming increasingly more important as more businesses are leveraging specialized cloud applications. So as specialization is disseminated, as it grows throughout the business, you need more and more help with integrating those applications together. So with this demand for integrations between the growing number of applications, teams have to assess how to create scalable solutions. And we have seen several approaches. Application vendors have made significant strides in this space through providing APIs, but APIs alone don't solve the problem, right? Sometimes in order to leverage the APIs, you need to have advanced product knowledge as well as have access to a sandbox environment for each one. So often, the difficult job of leveraging application vendor APIs can fall on customer success or professional services. And those custom coding costs add up. App vendors often, they can have integration referrals, which work well for small use cases, but scalability can become questionable during the sales cycle, right? And the final option there is to build in-house. So more than 60 of our embedded platform partners have taken this route. But due to the demands of integration and automation, ended up partnering with us to help bridge the gap, right? They may be still used some of those integrations that they'd already built instead of just flat out replace them, but they used us to take it to the next level, right? So that brings us to building versus buying, right? So over time, as you grow, the answer to some of the, you know, the building versus buying questions can change, right? There's cost, right? The number of integrations and, of course, the complexity of the integrations, they all play a role in determining if an iPass is right for you. So a quick stat is that over 70% of the largest SaaS companies out there offer an app store for integrations. It's something that has just has to be offered. I think it's table stakes at this point if you want to scale. So when does it make sense to build? Because it does make sense to build some of the time, right? It makes sense when the user experience is paramount and your use cases are very narrow and they will remain static. If it's also strategically important, it might also make sense to build depending on the size of your company. And as far as when it makes sense to buy, that's a bit different, right? One important factor is speed and time to market, which is really critical in the growth stages of in, you know, in our ultra competitive landscape, right? Another factor is you is I guess your product team and the team that is responsible for building it. So that team, of course, needs to have bandwidth to focus on the core features. And if they don't have that time, they will get bogged down on maintaining these integrations. And even if you offer only 10 or 20 integrations, you know, how many of these need to be customized for each customer? So a quick story here is that we actually have a partner Tango card that used a combination of building and buying in their solution. So for the most, for their most important integration sales force, they decided to build it themselves, but used Mercado for the rest. So, you know, there can be a balance there between building and buying. And we encourage that. So how does the embedded solution for Mercado come into play? How I bring the power of the, you know, how do I bring the power of this platform to my customers while still preserving the really important seamless user experience that I've worked so hard to give them as a product owner, right? I've worked so hard to provide them this very carefully put together user experience. And I want to preserve that. So through this embedded offering, we're providing a robust, flexible and most importantly, scalable solution for you folks that are looking to partner with us in their integration journey. So why Mercado? With the foundation in Mercado's best and breed and low code, I pass technology, the Mercado embedded platform layers a multi-tenanted solution architecture, critical management capabilities and an outcome oriented approach to implementation that efficiently solves your in-product integration and automation needs. The embedded platform customer has a global administrative instance of Mercado, so the embedded platform customer in this case being you, right? So your account is where you build out, test and deploy recipe templates and global administrators can manage customer accounts, the governance of those accounts and recipe distribution programmatically. So we give you the option to manage all that through the UI if you want to or programmatically if you need to. The global administrator account can also be used as a demo instance for pre-sales efforts. And this scalable approach allows you to create templates for the common business processes you'd like to automate for your customers. So that once they're deployed to your customer accounts, they can be modified based on their unique business needs, right? Common modifications your customers would make to a recipe include, you know, of course, authentication to their different applications, custom field mapping, logic and configuration and other customer specific business process considerations. So Mercado is built to provide the most efficient, secure, and of course, like I said, scalable solution for teams looking to solve in-product integration challenges. And the Mercado embedded platform partners, so what it will be you guys could take our existing I-Pass platform and the connectors that we already have in our ecosystem to solve for the technical challenges of integrations and automations and turn their attention to the core products that are unique to their marketing customers. So you guys, what that means is that you guys can take, you know, what we have done, use it to instantly upgrade your application and the features that you guys offer and then return back to enhancing the things that you guys already do well, which is your core product, right? Embedded integrations from a solution like Mercado alleviates those engineering teams from setting up, or from staffing up, I should say, for expertise in API building and freeze up Scrum teams from DevOps work to focus on new feature capabilities that are unique problems for the target market and product. And since Mercado takes on the burden of API maintenance, post-implementation platform management can live with non-technical roles like product management, product owners or business analyst roles who will leverage the global administrative account to manage accounts and develop and distribute new recipes. So what's the experience like for my customers? I'm sure you're asking yourself right now, right? There are several different ways to deploy or embed the platform in your application. It depends on several factors, but everything is managed through a specific combination of APIs and iframes. So if speed is important to you, then taking a partner-managed approach is probably best. This option allows you to embed iPass and brand it as your own. This can be rolled out with little effort and time in weeks. Another option is the seamless redirect. So you can simply provide a link for your customers that takes them to a branded and customized instance of Mercado. This Mercado instance has a very simple and intuitive interface, and with a built-in marketplace that your customers can use to search for different integrations and install them. Finally, there is our fully integrated option. Through a combination of, like I said, APIs and iframes, you can build essentially any part of the Mercado platform directly into your product, which is something pretty cool, I think. And we have customers across each of these different deployment models, and many of those customers that use a combination of these things depending on the customer that they're talking to. And many of our customers have actually, our partners, I should say, have matured from left to right, so whatever suits their strategy at that time as they grow. And at the end of the day here, the bottom line is that our solution is highly configurable to fit your product. And then now we're going to do another quick poll. Based on the configurations that I've already talked about, which ones are lying to your ideal integration strategy? So we have pre-built integrations, a branded experience, or the fully embedded integrations. So go ahead and answer, and then we'll see. All right. So it looks like most people prefer pre-built integrations, but it also seems like it was pretty widely distributed. And that's okay. I think most of our new partners, before they I think understand what goes into embedding workado fully, they probably want to offer like a pre-built integration, that's fine. Thankfully, workado is flexible enough to accommodate for all of those use cases. So now that we have talked about the different, what actually embedded is and what the, what some strategies around deploying workado embedded are, I want to actually show you what workado is, right? And demonstrate the power of this platform and what actually goes into embedding it. So one quick note before we begin the demo, I want to talk a little bit about the two types of personas that we'll be exploring as it relates to the embedded platform. So we have both an embedded partner perspective, so that's you, and embedded customer perspective. So that's your customers. So I want to keep these persona names in mind as I go through the demo. And I think that will illustrate how each of these different personas might leverage the platform differently. So in this case, ACME as an embedded partner, which is again, you might have an integration administrator or professional services or a customer discuss manager that actually manages the embedded experience for the customers. And Clone or Pipe Piper as embedded in customers, meaning your customers, might be administrators or users within their business and IT departments. So let's actually dig in here. I'll show you what it would look like. So this is a little demo environment that we put together to illustrate how all these pieces fit together. And right now I'm in ACME ERPs integration hub, right? And I'm logged in as Pipe Piper. So in this case, I'm Pipe Piper. I'm the customer and I'm logged into ACME ERP. Here I can see a dashboard of some of the activity that's gone on in my account. But the really cool part here is going to be in this little connect section here. So as Pipe Piper, I might have a few different ideas about the kind of integrations and automations that I want to implement, right? And as ACME ERP, I can display some of the applications that you guys might have recipes already built for or some of the things that you think your customers might want to see here, right? And you can organize them in any way you want. You can pull these from work auto itself and then display all the different kinds of options that you might want to provide, right? So let's say as Pipe Piper, I want to integrate ACME with Salesforce. So my instance of ACME with Salesforce. So I click on Salesforce here. And I'm displayed with a few different things here. The first thing I probably want to do is actually connect to my Salesforce instance. So I can actually click connect to Salesforce. And I'm presented with this little iFrame here. So this is actually something really cool. This is an iFrame that's linked to Pipe Piper's own work auto workspace, right? So their own tenant. So that's really important in how work auto is architected as we have a multi-tenant approach to architecture, meaning that Pipe Piper, as a work auto customer, or as an ACME ERP customer, I have my own workspace. And I have my own set of connections into the different applications that I want to integrate with. So in this case, I'm integrating into Salesforce. And when I click connect here, I'll authenticate into Salesforce. And my Salesforce connection will be, will list as connected in my account here. So if I click connect, I just log into Salesforce. This is an OAuth flow. So I'll be redirected back into work auto. And then it should say connected. And now I'm connected to Salesforce. Now that I'm connected to Salesforce, I have a few different options as far as what I can do here in this integration environment, right? We have this concept that you might want to offer your customers called quicksyncs, right? So these are pre-built recipes that you load into the customer's workspace, right? So into Pipe Piper's workspace. And give them the option where there's not really a whole lot of like, you know, configuration that needs to happen before they can just run this sync, right? So it's pretty low on the configuration, not a whole lot of like remapping. So let's say as Pipe Piper, I want to sync issues from Acme with Salesforce cases. So I can click on this and I present it with some details around what the sync is. And then a few different configuration options here as well. So as Pipe Piper, I might want to, you know, dictate what the Salesforce case status should be when the Acme issue is in the new state in Acme. So what I can do is I can actually select from this list of Salesforce case statuses what I want the mapping to actually be. So something really cool here is that we're actually using a couple of things here. We're using a metadata API in the back end that actually goes into Salesforce, pulls that list of Salesforce case statuses and displays them here to the user. So even if the user has a really, you know, has like a hundred different Salesforce case statuses for some reason, right? We can display them all here and they'll be able to see all the things that are unique to their account. And then through our pick list APIs, you're able to actually set these values in the recipe itself before you run it. Which is also really, really cool. So if I want to set these as my example, right? I can go ahead and click start, right? And the recipe should run with these two parameters set, right? And the way that that works is through our, you know, our API platform, or I'm sorry, our platform API, a little different, I want to click start and actually we'll go through the API in the back end and start work auto. Sorry, start this recipe in work auto and the sync will begin as ACME, right? And as ACME, right? My users, you know, they might, depending on their use cases, they might, you know, not really be able, you know, these quick syncs might not cover it for them. You might want to give them more options as far as what they can do in your integration environment. So if you want to offer this, you can offer them the ability to actually start building recipes directly in your platform, right? So I'm still an ACME ERP, I'm still as Pied Piper, but now I'm actually in the recipe builder and I can actually build a recipe from scratch, right? So lots of flexibility there. So, but what if you want something in the middle, right? You don't want to necessarily offer them, you know, all the options under the sun is in terms of like actually building recipes from scratch, but you need to do more than just quickly sync something with, you know, with some small mapping elements in there, right? So what they can do is they can, you can offer them some automation templates. So as Pied Piper, I can see different templates. This is obviously workday, right? I can see some templates that you guys have decided as ACME ERP to offer them that they can use based on use cases that you think that they might have, right? So let's say this looks interesting to me as Pied Piper, I can go ahead and view this template and I can actually see the recipe as it exists in the recipe editor and, you know, click into each step, right? See the configuration of each step, right? And then if I want to use that recipe, I can actually use it and then modify it if I need to or just, you know, do some quick remapping and move forward with it, right? So at the end of the day, there's a lot of, you know, the bottom line here is that there's a lot of flexibility in how you offer this, you know, bypass solution embedded for your customers into your platform as ACME ERP. So that's all really cool, right? But how do I actually manage all this stuff, right? As ACME, how do I provision my customers, my customer accounts? How do I move recipes in and out? How do I actually, on a day-to-day basis, manage this stuff?  So let me actually go back into the Mercado platform here. And now I'm actually logged in as ACME. So I'm logged in as you in your admin account. I don't know if you guys have seen Mercado before, but I think if you have, the first thing you'll notice is that there's lots, this is really similar to a normal account, a quote-unquote normal account, right?  And in this section, this is where you, or perhaps a partner would develop and maintain those recipes that you would like to build for your customers for them to use in their accounts. Generally, our partners use this as a development environment to build and test what we call template recipes and custom connectors that can then be inserted into individual customer accounts like Pied Piper for their use through our recipe lifecycle management tool. And just like you would see in a individual workspace or tenant account, I have the ability in this account to bring in team members and actually collaborate with them within this environment. So if you have multiple people working together on building recipes or working on connectors, you can bring everybody together to work in this one centralized account. And with a focus on team cooperation, this admin account is designed for our partners to easily build, deploy, and importantly maintain customer solutions without reinventing the wheel every single time you onboard a new customer. So you can build and keep those template recipes in this account that might account for 80% of your customer's use cases. And although it looks like a normal account, there's a couple of things are still different here. So of course at the top, you'll notice that the logo has changed. And for your admin account, you can insert your own logo here as well as your own brand colors to the upper banner section. And the key differentiator here, the most important thing between this special admin account and normal tenant account is this admin button. So if I click on this admin button and go into manage customers, I can actually, I'm actually in the admin console now. So when we jump into our admin console, we're first going to land directly on our customers page. So imagine that this table of, I guess it says 91 customers is your list of 91 customers using this integration platform. So from here, you're getting a quick look at the management of them. And this whole purpose of this console would be to manage and maintain these integrations from both a go to market and billing perspective. And you can track their usage through various metrics that we display. So you can also filter them down by what plan they're on. And I'll talk about plans in a minute, what statuses they have if they're in trial or if they're active, different applications that they're using, et cetera, right? You can filter them down and organize this admin console list of customers by whatever you want, right? So if we want to actually add a customer, what does that look like? So if I click add a customer here, I can provide their name, the notification email. And of course, when you're creating a customer, this would be a net new workspace or tenant, right? You would use this form. The notification email would tend to usually be someone within your organization, unless you want your customers to directly receive error notifications, which is totally fine too. And the plans which I mentioned before are things that we would curate with your team during the onboarding process. And this list would really depend on the go-to-market strategy. So for example, if you're using connection-based pricing, you can put your customers into five, 10, or 20 connection buckets, and then we're able to alert you once they've reached their limit. So the best part about this customer tenant provisioning process, I think, is that it can all be done programmatically, right? And it would be part of the whole onboarded, sorry, automated customer onboarding workflow that you could create, which would involve programmatically creating users, giving them roles, assigning them a plan, et cetera, right? So if I want to click into this customer account, let's actually go into Clone. Let's assume that Clone is one of your customers, right? And click into the account, see some high-level metrics about how they're leveraging the platform. And for example, you can see what connectors they're using if I go down to the bottom here, sorry, connections, and as well as the tax percentages and connections that they're using.  That's pretty nice. So they won't run out of connections or tasks, but you can see those metrics here. So if I click on collaborators, I can also see the list of collaborators that are part of this account. So you can see who in their account, who they've invited into their account if you want to actually give them access to their Ricardo tenant to actually add users. You can see who they've added, who you've provided access to in that account. And in the Settings tab, we have even more options for control over this user account. So this is where you could modify their usage plan or flag them as a trial account. And the additional piece to all of this is actually being able to access the account and modify it just like any other admin within that account would be able to do. So given the right roles and permissions from an administrative perspective, you would be able to see this switch to this account button, which actually allows me to get into the tenant itself. This is where our multi-tenant approach to embedded customer management, I think really comes into play. So I could switch into this account. And now you can see up here, this has changed. And now I'm actually in clones customer account as an individual account within this tenant. But I do, of course, roll up into your admin account that I've adopted. I've adopted your branding, right? And obviously you've got purview into this account. So as a professional services consultant or maybe a support rep, I can go into this account and create new recipes, enhance existing ones, fix bugs, or do whatever I need to do on behalf of the customer. And of course, the recipe that we started earlier within the Acme ERP integration hub would be here, right? So the other thing I can do is click on the community library. So should you decide to provide your customer's access to it, they will also have the ability to search our community for new connectors, as well as pre-built recipes that they might want to leverage for their integration and automation use cases. So this ability to self-service will save your customer success in professional services teams lots and lots of time. Because a lot of times customers know what they want and they're technical enough, which isn't really that technical platform, but they know enough about the platform to do this themselves and build from the ground up. When you put it all together, the bottom line is that through our robust API platform, as well as iFrames, any of the work auto experience can be embedded into your platform. Hopefully this quick demo was able to demonstrate the art of the possible within the work auto embedded platform from both a front end perspective, so what your customers would experience from a back end's perspective, which is all the admin tools that I just showed you. Work auto embedded offers, I think, an instant product enhancement that is not only easy to set up, but easy to manage and scale. So what are some of the key benefits of leveraging a platform like this to deliver integrations and automations that scale for your customers? First and foremost, speed. Your time to value for these integrations is drastically reduced, and the vast majority of these use cases, your customers can just self-service and build their own if they need to. And second, I think the flexibility of the deployment options allows the platform to easily fit into your desired end user experience. And finally, I think we can deliver a marketplace look and feel to your integration environment. That is something that many of the top SaaS companies out there are trying to offer. So at the end of the day, why choose work auto? A few different reasons. We're expediting sales through reduced friction in the sales cycle. And in fact, we've seen a trend where SaaS buyers prioritize integrations and their buying criteria. So how about your sales teams and use an iPass platform? Yeah, I think they'll thank you for that. Integrations can also help reduce churn. And in fact, I think it also helps in the stickiness factor by I think up to 25% when your product is already integrated with four or more apps to start off with. And integrations can help reduce burden of the development on you and your customers. And you can also add a new recurring revenue stream by passing off the integration costs as a separate revenue stream. So your sales and CS teams are going to love this. This is really, you know, this is something that as a product owner, you will ultimately probably be this decision maker on, but your sales and customer success teams are going to love it when you're able to offer them this ease of use.


How satisfying is it to bounce back with a sweep? We scored 28 runs in end stretch where you had 21 games in 20 days. Yeah, I'm really, really happy with how we were able to come in with a focus this series, you know, especially falling down four runs in that first inning of the first game. And just thought we just had a lot of quality at bats up and down our lineup from a lot of different guys, a lot of people contributing. And and really, you know, I felt like our hunger was good coming in today. No one, you know, we're we're about to leave for the road going into an off day. And I just I was I was really pleased with how the guys came out today. Just from a focus energy, everything standpoint to to kind of finish off this home stand, which was a little up and down and finished on a really good note. What's the latest on Dede? Um, he's got a pretty bad bruise on his heel. So it's something that we'll kind of monitor over the next 24 hours could potentially be a DL thing. So, you know, not great there, but we'll just kind of see where we are tomorrow. And there's nothing broken or anything like that. But he's he's got a pretty good, pretty significant bruise on his heel. And there's some swelling in there. So we'll we'll know a lot more tomorrow, but it's a possible DL situation. And that's the result of the imaging test that he had done? Yeah. Well, he went all that. And I think that all came back clean and fine. But there's pretty good, pretty good swelling in there. Susan, how exactly did the heel get bruised? I'd have to I haven't run run back through it and seen it. But, you know, pretty good spill over there. I don't know if he jammed his heel down into the ground or or where exactly he did it. I haven't run through that with him yet or where I haven't seen the video yet. I was just talking with him in cash and and Stevie just kind of walking through, you know, where he was and what the next 24 hours looks like. What what were your feelings about Jay Hap today? Good, you know, it gives up the Homer in the first air, throws a number of pitches. And then just kind of settled in, you know, you can't really you can't ever really tell, you know, it seemed like, you know, they were they were aggressively up there swinging against them, knowing that he's pounding the strike zone, knowing he's throwing a lot of heaters. Obviously, they know him a little bit. So they were they were aggressive with them in that first inning and made it a little bit difficult on them. But I thought he settled in pretty well and, you know, kept just pounding the strike zone. And then obviously, you know, especially once once we got him that lead in the bottom of the first, he kind of took it from there and and gave us a solid outing. Kevin and Dan, a two part question. What's your plan for shortstop without DD, obviously. And also the just to kind of you've been getting some weird injuries to, you know, injuries happen. But it's a little strange with because, I mean, Maraus was totally out of position there when I'm over on things like that. I mean, we'll see where we are again in 24 hours. Maybe maybe the news gets a lot better and and and we'll go from there. But, you know, Glaber would move over and and get the bulk of the work at shortstop. If DD was down for a significant time, you know, obviously, we have we have toe capable playing there. So we'll just we'll kind of mix and match and figure it out from there.  You know, you hope to avoid them as much as you can, especially the key guys. But it's, you know, whether they're freakish, whether they're, you know, significant, whether they're small, they're they're all things that you have to deal with and and we will. Obviously, Walker would be someone you put at second, but he's in right field. Just the the toll that the injuries have taken to such key guys. So you wonder, you know, how how much more resilient this this team can be if this is something that lands DD on the disabled. Yeah, I mean, look, it's it's another, you know, I don't have to explain to you how important DD is to our club. So so hopefully it's not something that's that's very long. But, you know, we'll we'll we'll work it out and hopefully, you know, hopefully John Carlos in a position to where he's back on the field, you know, like that can slide walk into the end of that infield mix again. And and, you know, we'll make do that way. And yeah, we'll we'll make it work. Brandon to the right two things. What was the what were the results of Romain's test today? Good. Everything everything checked out. You know, we got his heart rate up this this morning. He responded well past all the the scat testing. So, you know, assuming everything's good over here, the next 24 or 48 hours, I would expect him to be back in full full go on Tuesday. Bill to the right, Stanton's usually a pretty low key guy. How do you think he'll handle going back to Miami? Um, you know, I think one, he's looking forward to going back there. You know, it's always weird, you know, just speaking from my own experiences of playing the next team or going back to a city that, you know, in this case, he grew up in in a lot of ways and, you know, came up through their system, became the big leader there for him, became the face of the franchise, obviously, and a huge star. So I'm sure there's all kinds of emotions that go into that to returning to a place. So, you know, it's one of those things that you deal with also as a big lager. It's kind of the inevitably going to happen to you if you play long enough in this game. So I'm sure he'll he'll be experiencing a lot of emotions. And, you know, if if what I've seen of from him over the last four or five months, I would imagine he'll handle it pretty well.


Good afternoon, everyone. Can I have a good afternoon back? I knew you all would be feeling a bit sleepy because we just had lunch. So kindly bear with me on this. So welcome to DrupalCon Vienna. And I'm Jyoti Singh. I'm working in region technologies as a Drupal developer. And I'm really very excited for this DrupalCon because that's my first DrupalCon as a speaker. And I've been in this beautiful city Vienna and with a lot of beautiful people out here. So moving on, I'll just give us a short description of what topics we are going to have in our sessions today. What is big pipe? How does big pipe actually works? How to use big pipes in our current project? Implementation of some big pipe modules in our Drupal8 sites and a demo of big pipes along with some few illustrations. This is a short demo. So who all out here have worked on big pipe? Okay, not so many. And how about Drupal8? A lot of money of people. So the big pipe is being introduced in Drupal8. So it's not a concept of Drupal7. So it's a new introduction in Drupal8 right now. So the topic for today's session is tunneling its way fast with big pipe. So today we'll be talking about big pipe. And I'm Jyoti Singh with a hashtag at the rate jyoti.sing in Twitter. So before starting my session, I would like to give a word of thanks to Wim Lears and Fabian France who have done a fantastic job for giving us big pipes and caching for Drupal8. So it said that Drupal8 is one of the fastest ever Drupal. So that's because of Wim Lears and Fabian France that we have a fantastic caching system in Drupal8 and big pipes. So what do you want when you browse our site? So what type of site does you guys usually browse into? Anyone from the crowd? Can I have answer from you, sir? Facebook? So what happens when it loads really slow? What do you think? Something's broken, right? And it's like you just close the page or you just refresh the page again? Both, yeah. So it takes your time and maybe you get frustrated sometime, yeah. So why should the user be concerned about the page load time? It should be like he should be on the website and it should load fast. That was the user one. He nothing wants to see anything technical into the site. It doesn't want to sleep when he goes to the slide site. So how does a user feel? It's like how does I feel when I do the shopping? It's like sometime it's really slow. The page is really slow and I'm sleepy too. So what's the important of the time? So I went to some of the stats. It's completely the stats that I found on Google. So it says that one person, 40% of users abandon their site if it takes more than three seconds to load it. So it's totally impacting the business, right? So if I say I have a business and my site is running and the user is not satisfied at all, then there's something going wrong in my site. So it's like 79% of the shoppers who are dissatisfied with the website never ever go to the site again. So that's again impacting my business. And there are also many other domains that get affected by the same things. That like say search engine because if your site is slow, sometime Google doesn't get to read the keywords that you have in your pages. So if I ask a question that how fast you think that your site should load, so what answer would you have in your mind? Some answers? One millisecond? 300 millisecond. Okay. So there was a survey done by akamayangomes.com and they found that nearly more than half of the user on the website want their page to load in less than two seconds. And that's gradually decreasing every time because we are becoming more digitalized and we want our pages to get load at fast as possible. So when I say fast, what does fast means? So there are a few measurements that I have here with respect to what fast means when I go or browse a page. It's a great user experience. When I hit the page, I should see the site. Then it's time to first byte. What's time to first byte? It's the response that you get from your web server. So it should be as fast as possible to make your site load fast. Then it's time to asset fetching.  That's also a very key point in your optimization and performance measurement for your site.  So what does time to interact means is the first interaction that the user has with your site. So whenever you load your site, at least you should have some content that the user is to keep the user intact to your site. And lastly, the page load time, of course, should be minimal for the user. There are some other usual optimization that we usually do in our site. That is optimizing our code, making the query as simple as possible and using caching and other things. And if I say from the front end perspective, it is we minify JS, we minify CSS, we try to reduce images, we try to cache images, and we try to make as small and as low connections as possible. So how can we make the page load faster? Even with such optimizations that I already discussed, we still have lag of time in our pages, especially if I talk about Groupal. I see that even after working on my optimization for CSS and JS, I still have the slow page load time or in my site. So what the Drupal 8 said was cache everything. You should have correct invalidation in Drupal 8. So anybody who's worked with caching in Drupal 8, great amount of people. So correct invalidation with your render API, specifically if I say render API, it would be you should know where to put the cache tags, cache keywords, cache contents, cache max age, and cache tags are specifically for your render API to make the page optimize. So when we use cache context, it's cache dependent, cache context dependent. So sometimes you want the page to display user-specific content or you want to display some cache content in your specific URL. So here we use cache context. Secondly, cache max age is used for those content that usually change within some time period, like for some blocks that we are fetching Twitter handles or some feeds from another third party sites. And then cache tags are totally dependent on the data, the data Drupal renders. So even after I say I put up the cache for everything, I have some problem. So further on I'm going to discuss what problem I usually have with my site. We say cache all things. This cache solves everything in Drupal 8. People say yes, caching is the powerful weapon in Drupal 8, but somewhere it fails. It fails in cases where we have dynamic and static content in the same page. So handling static content with caching is very easy. It makes your page really, really very fast. Just in case of Drupal 8, we have anonymous page caching. So it's really powerful in Drupal 8. But when we talk about dynamic content that are really user-specific or that changes really very frequently, like for example, if we talk about some shopping site, that's really user-specific and its content changes now and then with every user choices and the selections. So in that cases, the caching fails. How can you cache something that's really changing every now and then? So the answer is, how can we optimize the page that is very dynamic? What can be done for that? So what Drupal 8 provided with the solution is placeholders. So any idea about the placeholders? Anyone in the crowd? Have you ever heard about placeholders? Okay, so, sir, can you give me any idea about the placeholder? Okay. Okay, that's the rendering. How Facebook renders the page. Like it's render your static part first and then it's render the dynamic page that's user-specific, correct? Okay, so placeholder is something I'm going to go into the technical details. What can we do with the dynamic content? What Drupal 8 actually does? I haven't started with big pipes yet. It's still the Drupal 8 core part that I'm talking about, the placeholders. So for the placeholders, the Drupal 8 core uses a single flush technologies that is used to handle the really very dynamic part of your page. For instance, if I say, if I am in a shopping cart and I am changing my choices and I am deselecting and selecting some of the things, so what should I do then? So what Drupal core does is it creates a dome with static content and then it creates a placeholder for every dynamic content. So you get the static content at the first time to first byte when you load the page and then after it, the page is refreshed and the placeholder are replaced by your dynamic content. So what user get to see is something because what happens is if you see that the page is loading and it's showing me nothing, then it's for no use for me as a user. So if you get to see something, then you are interacting with your site. So what Drupal 8 does is it plays all of your dynamic content in a placeholder and it's a part of the render API. So render API creates a placeholder and that it is replaced by the dynamic part of your page. So this concept is really renowned concept when we talk about big pipes is performance versus perceived performance. Performance something you want to measure in term of efficiency, time to first byte, and something that is quantitative. But when we talk about perceived performance, I cannot quantify it because as a user, you may have some other perspective of your page loading. For me, I want to see some images when I load the page. You want to see some username so that I cannot quantify the perceived performance for me. So as said by Dan's Michono, physical, the psychological time in our brain usually differs from the objective time of the clock. That means what you perceive is really different from what it exactly is. So how long it takes to generate the page is what I can quantify. But how long it takes me to see the content is something that totally depends on each of the perception. So if I show you the stats of the Facebook performance as said by sir that Facebook uses the big pipes. So Facebook uses big pipes and it has drastically reduced the page load time to almost 50% by using it. So what is big pipe? Big pipe was a concept conceived by Facebook and what theory it works on is that whenever the user loads the page, it renders the static content of the page and after that loads the dynamic content in the dome of the page. So this is what big pipe actually works in really lame word. So big pipe made Facebook as twice as fast and it segregates the page into smaller chunks known as pagelets. I'll be discussing about the pagelet in the next slide. And big pipe pipelines pagelet to several execution stage inside web server and browser. So I'll be covering this up and I'll be discussing the pagelets. So what pagelet is? Pagelet is a component of HTML page that contains layout, directives, code, HTML, everything of the page. And what big pipe does it? It divides the page into different pagelets and when you render the page in your browser, it first renders your static content and then slowly renders each every pagelet. So here's a small demonstration between how the standard caching works and how the big pipe caching is used to render the page. So here you can see in the standard way it's loading all the dome together. So the user is not able to see the content, any content, any interactive content whenever he loads the site. But with big pipes, what he sees is a header, something product and some footer and then some dynamic content with social media and some more products to be loaded in next phase. So what this helps the user is with interacting with your site more. So it takes the same time in the end, but the perceived performance is better. If you say big pipe has been a really big achievement and it has made Drupal it really, really very fast. So I would say it has made the perceived performance very fast. If you have a really heavy content page with a really dynamic content, the time to first bite and the time to asset fetching would be really affected, but overall page load would won't be affected that much. So if you'll be using big pipe and you say that my page would be really loaded fast, then I would say it would be incorrect to say. The perceived performance would be really fast but not the actual load time. So here's a small difference between big pipe and lazy load. So many people ask me that why not lazy load? When we are using lazy load so much with JavaScript with everything content in Drupal 8, we have so much to do with those load. Why to introduce big pipe? So there are a few differences between the structure costing and the speed for both. So when we talk about structure, the Ajax request that lazy loading has is different from the one that big pipe has. So for every scroll or for every Ajax hit, for your lazy load, we have different Ajax requests per HTML response. But if I talk about big pipe, what big pipe does is it accumulates all your Ajax request and post it in one HTML response. So that's the difference. So structural reference I will be discussing when I'll be going into the detail as to how big pipe works. And for the processing cost, it's almost the same for the lazy load and big pipes. But for the speed, it's almost one third the speed of lazy load. So big pipe is really three times as faster as lazy load. So if I say if I have to use lazy load in my Drupal site, so what people usually say is there are, there is a tremendous amount of content I want to show in views page, views listing page. And I want to implement a lazy load. So I would rather say that lazy loading is basically for images and not for content, though we still are using it for content management also. And for, if I say about SEO purpose, so if I have a one page application and I use a lazy load, then some of the content may not exist for Google. So that would be affecting the search optimization for your site.  So that we have really, we have many number of end points for lazy loads, but for big pipes we just have a single HTML response for every Ajax. So how big pipe actually works in general, I'm going to show that first. And then we'll be moving on into the details for the big pipes. So for the processing of the page by the big pipes, there is a request parsing that uses the web server parses and sanity check for every HTTP request that you are going to request from your web browser. And then there'll be the data fetching from the web browser and stored in the architecture or the tire that you have for your site. And then there's a markup generation wherein the big pipe would understand what static part and what dynamic part does your page has. And then there will be a network transport. The response is transfer from web server to your browser. Then we have a CSS downloading and the asset downloading by your page. Then there's a DOM tree construction and CSS styling that's associated, wherein we construct the DOM, but we do not add into the dynamic content. Then there is JavaScript downloading, wherein the JavaScript asset of your browser is being downloaded. And then there is JavaScript execution for your site. So this is how big pipe actually works in stages. So this is basically a theoretical thing that I wanted to add to the session. So how does big pipe create placeholder? So we talked about how core create the placeholder, but how is big pipe actually using those placeholder? So if I say, I already have a placeholder in my Drupal 8 core, so what does big pipe does? That's the concept is auto placeholdering. When we say placeholdering, it's creating a dynamic content every time, but you need to specify that which dynamic content are you going to have. But with big pipes, what big pipe does is, it's automatically differentiate between the static and the dynamic content. So you need not explicitly specify for your comments, for the user comment, for user specific block, for your changing content, to be up to be included in the placeholder. It is automatically identified big pipes. So there are the sections that have been replaced by the placeholder for the Drupal core. And in big pipes, they are automatically identified and rendered. So what Drupal actually at the end sends out is a markup along with your static content. And then after loading the dome, it loads your dynamic content as a placeholder. So the condition where for your content, browser content lies for auto placeholdering are high cardinality, where in some content that have lot of variation, as I talked about, like if you are fetching a Twitter feed from a third party, then it's really dynamic. And then the content which have a block that is constantly changing now and then is having a high invalidation rate. And also for those content that has a really small cash max age have high invalidation rate. So that falls into the category of differentiating by the big pipes that what all content of your site are actually dynamic. So we talked about the single flush strategy that Drupal it uses in its core. But what big pipe uses is an end flush strategy for the rendering API. So there's two categories where in the big pipes render API works. First is a default placeholdering strategy, wherein I talked about that there and Ajax responses for the big pipe, but there would be just single HTML response every time, unlike lazy loading. So here's a code from big pipe. So it's a file inside SRC folder. And this class has a create big pipe placeholder function, wherein it creates the placeholder for your dynamic content. So what argument it takes actually is a original placeholder, then placeholder render API that you are going to use for your content. And then what it actually does it, it creates a caching mechanism for those content and it's add up the marker for your static content. So here the placeholder are being created by the big pipes. So that's just, I would just wanted to give a glance of how big pipe module actually works towards it. Another strategy is a no JS big pipe placeholder strategy. Though big pipe doesn't work with the JS when there's no JS and when there is no session, but still there is a technical terminology for no JS big placeholder. So what it does it, it combines all the embedded HTML responses into one HTML response. So how it looks in the code is in the same file that I showed you before, there is another function that is create big pipe no JS placeholder, wherein you are not using the JS. I would rather say it is not part of the big pipe concept, but still it's included in there. So what it does it takes original placeholder render array and some attributes as the concept, as our argument. And then it's create the placeholder with nflush strategy. So earlier we didn't use the JS, earlier we used the JS and now we don't have the JS. So how did big pipe successfully make your page load faster? So where it actually creates the pagelets and everything in its code. So here's another send content function in the same file. And what it actually does it's use three function that's send pre-body, send placeholders and send post-body. I've already marked their three function. I hope it's visible to all. So send pre-body, what it does it takes the HTML from your browser request and then it finds out what is the static and the dynamic content. And then in the send placeholder, it sends all the dynamic content and in the post-body it sports the static content for your browser. So what it usually do is it creates two sections of static and dynamic page before rendering. So placeholdering how Drupal core is different from big pipe placeholdering. So I created a snapshot for the Drupal core. How the render array look for your page. So every request we make, the Drupal core creates a render API with markup, max age, caching tags and big pipe placeholder, I guess. This one is the Drupal core render API wherein uses the lazy builder with, you cannot see any big pipe, big pipe variable or the render array. Here what you see is a lazy builder that is being used by Drupal eight core.  And this is the array that is being used by big pipe, the render API array. And here it creates the markup for the static content that it renders first. And then it has all the cache tags like max age and context. And then it has a big pipe placeholder wherein you can see that there's another lazy builder for the same comment. So this is how big pipe actually distinguish that what is the dynamic content in your page. So how do we use big pipes in Drupal? That's really simple. That's a no configuration module. You need to just enable the module and there is no configuration that is associated with this module. And it actually works with internal dynamic page wherein with the help of internal dynamic page, it uses the static content to be rendered first for before then the dynamic content. And for the internal page cache, it doesn't actually affect the internal page cache because it works only for the sessions of the user. So I'm going to show you a quick demo for the big pipe. So here's a demo site wherein I have a list of many contents with a lot of content and images. And there is a block at left hand side that shows me the Twitter field, the latest Twitter field with the Drupal tag. So it is the dynamic content here and right now I don't have the big pipe module enabled for this site. If I try to check the time needed for time to first byte here, is it visible to everyone? The time to first byte. So it's 1.32 second, the time to first byte. Now I'm going to enable the module. The module is enabled and you can see the drastic change in the time to first byte. It's like 55.75 millisecond. So even with having the long list of my page and with a dynamic block, I'm able to achieve a smaller number of time to first byte here. So this is how big pipe works. I didn't have any configuration. I need not specify that what do I need to have as a placeholder for my big pipes and it automatically identifies. It won't actually affect the page load time. If you see the page load time, it's actually not affecting that much. The thing that we want to see here is the perceived performance by the user. That's all from my end. Any question and answers? Any questions from the crowd? Yes? Sorry? Do I need to come? Oh, sorry. How can you leverage a custom block? For instance, you have a custom block which does an API call. How do you tell the block that it has to use big pipe? Okay, so the one I'm using right now in my case is a dynamic block which fetches all the Twitter feeds that we provide in a configuration. So what I really do is provide a hash placeholder in my render API. So that's the structure of the Drupalate. So for the people who are really new to Drupalate, that's the structure for the Drupalate module. So I have a block here. What I really need to do here, that's a block and I provide a path to the lazy builder and I just need to add a create placeholder true. So that's what distinguished between my dynamic and then for the placeholder. And that was a snapshot that I used for the placeholder wherein you can see that this dynamic block has been identified by the big pipe. This is the answer to your question. Thank you. Any more? Yep. Why wouldn't you turn on big pipe? Why wouldn't I turn on big pipe? Yeah, so if big pipe is great, under what circumstances would you not want it? So there are the cases wherein you just don't feel the need that you have a really dynamic page. Like there can be cases where user can have a page to see the dynamic content after five second. You can have the maximum time page cache as five second rather than enabling the whole big pipe module. But is big pipe not better? Big pipe is better but why to have a whole module and creating the placeholder when we just can quote in the render API as a max age? Because anyhow big pipe is using the same render API, correct? So if we are just want to have the, when we have a low significance of the dynamic content there, we can just have the max cache, a max cache as just five seconds or six seconds rather than having the big pipe to work through all the same render API and create another thing, another render API. A follow up question then. Does it play nicely with engine X and Varnish? I haven't tried it yet through the engine X and Varnish. Thank you. Any more questions?