{shinylive}: Serverless Shiny applications workshop

a few sparrows. You bet. Yeah, thank you so much, Harvey. And welcome everybody. Yeah, it's an exciting day. Our first full day of our pharma workshops. It's always such a jam-packed lineup.

And you may have heard this before if you've returned from previous years, but we get a lot of feedback that the workshops are extremely high quality and they are often referenced time and time again well after the fact. So you are in for a treat today.

And it is certainly my pleasure to introduce our instructor for today. He is a very influential member of the Shiny team over at Posit. I've had the pleasure of knowing Barrett for quite a few years now. He has also been one of the guests on my humble little Shiny developer series. And we've shared a lot of great technical bits back and forth. And we also share a love for lifting as well, which is fun. Without further ado, let me bring Barrett onto the stage. Thank you so much Barrett, it's all yours.

Thank you so much, Eric. I appreciate it. Such a warm welcome.

I'm going to put in the chat here cause I know Zoom doesn't like to do historical chat, but this is a link to the workshop slides which will have most of the stuff going on. Let's see how screen sharing is gonna work.

Desktop. I am going to open up, here we go. Now I got Zoom chat. I'll have Zoom chat up on the side, but later when we get near the end of the day, I'll try to do Slido for Q&A. So if it's questions that can wait or something, we'll go to Slido.

Given the website or you go to slido.com, here's the session number for Q&A. And we'll actually do some things at the beginning just so I get an idea of the group here. And then it also will have links to the slides.

Agenda and introductions

Okay, agenda. We'll do a quick little introduction of me and Eric, and then we're gonna do some learning. I know it's more of a workshop and so I just wanna like lay out the architecture and how things work. So not as active, but we'll go through some really interesting details, I believe.

And then we'll have a little bit of break because that'll be about an hour in. And then we're gonna work on deploying our app to GitHub. And I'm really excited about this because normally when you do this in a classroom, Git says you're DDoSing everything. So doing this in a distributed environment is going to be kind of unique in that we won't hit that limit real quickly. So exciting.

As Eric said, my name is Brett Schlerke. I am the instructor. I am at Posit on the Shiny team. And I've been there for over six years coming up on seven. I've had at least 15 years in our ecosystem. All the way back to undergrad and just been fun. It's so awesome to find a hobby that you can get paid for.

So as Eric said, I'm a developer for Shiny. I have to put in plugs for ShinyTest2 and Plumber because they're more packages that I was lead developer on, including React Log. And ShinyTest2 and React Log really help your Shiny apps. I really encourage you to look into them. I'm biased, but I don't believe that they're talked about enough. And then today is all about shinylive.

Eric Nance, he'll be here as well. He's director and statistician at Eli Lilly. His LinkedIn is there if you. And then I've also added in links to his R Weekly blog posts and highlights and his Shiny Developer Series, which is just awesome. And we need more coverage.

So hopefully I want to try to answer this question for you before we get too deep and possibly spend too much time. But is this workshop for me? In this workshop, I am not going to teach you really about Shiny. I'm assuming you are familiar with Shiny and I am assuming you know about reactivity and all that. I'm not going to touch it.

What I am going to do is try to show a different way that we can deploy something. So it doesn't have to be Connect or Shiny Apps IO or I'm just working locally. It's a completely new deployment system. And I think that's really, really exciting.

Oh, all right. So let's try this on Slido so I can ask some questions. I'm kind of excited about this. I have no idea if it's going to work. This is new for me. So there we go. Where are you currently located? I just find this really exciting because you're not all in my little office. I'm in DC currently. And it's kind of weird when your local news is national news within the US.

Seattle, Utah, Philly, Kansas. In training. Yeah, quite a diverse group coming from all around the world here. That's awesome. Austin, Portugal, Spain. Ooh, Spain. I'm gonna go visit your neighbor in the spring, I believe.

Awesome. Thank you so much. Appreciate it. And then just a couple other ones. What is your familiarity with Shiny? I applaud you. Awesome. We got a good group here. And then last one. Before this workshop, have you ever used shinylive before?

I believe I'm still in this I can't believe it zone of Shiny what? shinylive should not be possible ever. Like it doesn't make sense to me at all. But I'm so excited it's here. That's a good reminder, Barrett. That was the last year at PositCom, Joe Chen gave a talk about shinylive coming for R. And I remember he was very skeptical if it would be possible. So it is a monumental achievement.

What is shinylive?

Absolutely. Yeah, I'll get more into that a little bit. All right, so let's learn. We got about 50 more minutes for the hour. Perfect.

All right, so let's have some cake right at the beginning, right? So what is shinylive? Normally when we run Shiny, you have your traditional server, centralized server. And in this case, we would have three users come in and they would want to look at the Shiny application. In this case, R is actually running in the centralized server. There's gonna be like one instance of R and the users just have a website. There's nothing on their machines. It's just like going to a different website, like normal.

It works well because everything is hidden in the server. The users only get the minimal amount of information. And then this allows your server to be, you can have it be really beefy and it can do all the heavy lifting for your users.

Where in shinylive, what we do is we actually take that centralized server and instead we send it to each of the user's browsers. And that in itself is just kind of crazy. We'll go into that more later, but what we do is it's now distributed to the user. And so the user has both the server, like the backend and the front end on their machine. Disadvantages, they're not communicating with each other. There's no centralized server, but advantages, it scales really well. I mean, you can have as many users as you want because they just download the whole thing.

Now there's no centralized server and this can be done through something like a static hosting website, like GitHub Pages.

Now there's no centralized server and this can be done through something like a static hosting website, like GitHub Pages.

So I clicked on the link and I promise you my personal website, I do not have a server. I am an open source. I don't like to pay for things. So when I go to it and I refresh it, things are cached and the app is fully loaded. And like R is already in the browser, R already is here. And the UI obviously is here as well, but everything is there in that browser tab and it's all self-contained.

And it kind of feels like a anticlimactic reveal because you're like, it's just a Shiny app. What's the big deal? But it's, I promise it's all there and it's delivered statically and nothing is going on. And that's just the power of shinylive.

How shinylive works: WebAssembly and WebR

So how is shinylive even possible? And I think this is the most sincere slide. It's just legit magic. If you were to ask me at any time point before maybe two years ago and say, can R be put on the internet? I would have laughed and bet you a dollar immediately. And today I am very happy to be wrong and lose that dollar bet.

Even as Joe said, as Eric said, Joe said in his keynote, like I'm skeptical, but like, if it can happen, let's give it a go. And it all hinges on having R in the browser.

So who did this? George Stagg. He's the gentleman we all have to thank because as the web started shifting towards let's put everything into the browser, he was ready to take on that challenge. And, you know, shinylive would not exist without him. I highly recommend you to look at his blog and his website, gws.phd. And he's also the maintainer of WebR where the true magic of shinylive comes in.

WebR, excuse me, WebR is where a lot of the heavy lifting is done. And then shinylive is just kind of like the icing on top. So while I'm doing this workshop and presenting as I'm the developer, really the hats off need to go to George Stagg. I get to just present the cherry on top of the cake. Like he's done the heavy lifting and I want to be, we're all thankful for him.

Also there's rwasm actions. So if you're doing anything for your company that is behind private GitHub or other things of the sort, but you do have access to GitHub, rwasm actions will be your friend and you can help set up your own private grand instances, things like that to help enable shinylive to work better.

So if George Stagg is a magician, what is it? You know, it's always kind of fun to see how the magic works. So what is shinylive built upon? And there's a little bit of rabbit hole, a little bit of a nerdy rabbit hole, but I do feel like we should go down it because it kind of feels like, oh, I should just have R, I install R through the installer on the server and then we're done. Like that's kind of how it normally works, but it's all in your browser and the browser is just looking for a website. So it's kind of neat to see how that sauce is made.

So shinylive, shinylive runs Shiny entirely in the browser without any need for a hosted server using WebAssembly via the WebR project. Link to that. And then shinylive uses WebR according to the description. So what is WebR? WebR is a version of statistical language R compiled for the browser and Node.js using WebAssembly via Emscripten.

There is some fun rumblings right now about talking about Node.js. So right now we're doing things with the browser, but it would be kind of neat if we could have Node.js running in our instance just for portability and reproducibility purposes.

WebR talked about Emscripten. So what is Emscripten? These are all terms, things that I had to learn over the past couple of years. Emscripten is complete compiler tool chain to WebAssembly using LLVM with a special focus on speed, size, and the web platform. This is where I start to get a little fuzzy. I'm more of a front-end R. This isn't my area, but George gets very, very excited when he gets to hang out in this land a little bit more.

And then finally, what is WebAssembly? WebAssembly, abbreviated WASM, is a binary instruction format for a stack-based virtual machine. WASM is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications, and it's supported by all major browsers.

This is a really, really interesting concept because it feels like... Like the comparison I like to think of is it's like Docker for your web browser. You can, instead of having Docker on your desktop or your container and Kubernetes or whatever, instead you could have your information bundled up and then you just open it in your web browser versus saying Docker run. And WebAssembly just allows for that now and it's supported within all those browsers.

Like the comparison I like to think of is it's like Docker for your web browser.

I talked about how it's kind of bundled and this really helps drive reproducibility and that's always a big plus in the R community. How R Markdown and now Quarto are doing these reproducible documents. You can do all your research in there and then you can recompile it and it'll all show up again.

With WASM, you really want to have something to say, I want to save this app in a bundle and I want to have it saved and I want it to work forever. How can I do this? And it's really important that you can have something that is platform neutral and you can also have... It's just a binary that you can just kind of ship around almost like a zip folder and it'll be really big because you're gonna have WASM, you're gonna have the compiled R system, you're gonna have extra libraries. So if your app is a little bit on the larger size and including your data, you might have a 500 meg bundle, but that's okay because anyone can open that up and if they had local hosting applied, they could kind of open it up with their Wi-Fi turned off and Shiny will work and shinylive will work and run.

And it's very, very exciting with that because the place where it's being hosted does not need to have their own version of R and they can have their own version of R installed, can have conflicting versions of R in different bundles because it doesn't matter, they're just in different bundles.

I do want to point out that the WASM is not completely 100% reproducible. There is some non-determinism places that they are aware of and are saying is allowed and the website that they have, I'll still go into that a little bit more.

So I do want to point out some interesting ones that I had George ask me about and it's like, why not Docker? Why not do any of like, you know, Docker has been solved, has big team, like why not use them? And one of the examples that he was able to show me is that you can have the same software in the same Docker instances, containers, and then if they're running on different hardware, you'll actually get different runtime values. So if we solve the matrix on the left with ARM or the middle with x86 or on the right with RASC, you can see the number at the bottom is different. And as a R user, that's a little terrifying because I would think, oh, it's just maybe a small rounding error or something, but these small rounding errors are magnified in certain instances. And it's quite spooky, I think.

When we do this in WebAssembly, because it's fully contained and it has the virtual operating system, this will produce a consistent answer every single time.

Creating a shinylive app

So done a bunch of explaining. Let's look a little bit on how we can create a shinylive app. There's really just one main function that I like to look at, which is shinylive export. And you provide a Shiny app from location and you provide an output directory to location.

This will, the phrasing I kind of like to use is that we'll say I have a from Shiny application and I will export it to a shinylive folder. It's not really an app because the app.r just got swallowed into the code. And so it is a little bit different. You won't see your Shiny app anymore.

But as I've been saying throughout the day, the folder must be hosted just because of some web restrictions. And this can be done with GitHub pages or you can even do it with local host via HTTP UV.

Okay, demo. All right, demo shinylive export. All right, let's play the app. We are all familiar. It's the hello world, old faithful, been updated with bslib. We can change the bins. This is running locally. No tricks, promise. It's just standard old Shiny application. This is just a regular app.r and then the rest is more just GitHub repo extra files.

Okay, so now we can call shinylive export and I'm going to export it, the current directory dot, and I'm going to save it to outbearit just because I like to name all the folders after my name. It's very fun. So I'm doing this. It went quite quickly, copying more folders and then ta-da, done. Outbearit exists. It's got an index.html and that index.html will load all the other files. Every file must be transported if you were to move it. It's not like a self-contained R Markdown file where you can just have like a 50 megabyte HTML file. Instead, we need all of them in separate files and yeah.

Okay, so there are instructions at the bottom where we can say htpv run static server. Because I'm in the IDE, I can click it. It'll paste in the code for me. And if I run it, we get the loading bar and ta-da. Again, it's just an httpv run static server. There's no Shiny connection. This would be, it's just, yeah, it's hard to like tell you, but it's just a static server. And now there isn't a centralized server.

Other ways to create shinylive apps

Cool, all right, let's go back to the slides. Ooh, some other ways. How can we create shinylive apps? I really like to get started using shinylive.io. This was first created for Python. So the default links are towards Python, but we can go to examples or the editor in R. It's free, it's online. You can build your own app. You can link to it. You can send links and we're gonna try our best to make sure that those links will always work. And you or the user who gets the link at the end doesn't need to set up anything.

So if we look here, just go through a couple of the examples here. Yeah, so we have the Old Faithful, Shiny Text, and Reactivity, oops, and Cylinders, Transmission, and let's see, Sliders. I always gotta do the play button. One, two, three, shinylive I.O., great. And Timer.

Okay, so this is a good one to kind of show just because it's quick. You can load and save to disk, which is neat, but I like to instead to share the link and you can actually share in the top right corner and you can get the editor URL, which is similar to what you have here or just the application. I'll copy both just so we can see it. So here's an editor URL where you have both the file on the left, terminal on the bottom left, and then you have your app on the right. Or we have application, copy URL, go to it, shiny for R in the top with an edit, just kind of tell you it's shinylive or we'll even allow you to hide that header, copy URL. And now it's just an app.

And this is where it gets very powerful because you can have iframes if you are making your own website, you can embed these apps. And I hope one day Packagedown will allow for us to automatically put our Shiny apps into the code because it would be really, really neat to have Shiny apps in your documentation. And none of our examples will ever have to say, if interactive, then do the app. We can remove all of it.

You can put shinylive into Quarto. There's a Quarto extension that needs to be installed. It's nice. It's useful. It's not fully what I want, but it's very helpful to embed an application, self-contained application.

Yes. So it's good for like little small apps, but I wouldn't write a 10-page multi-thousand line app for shinylive inside a Quarto document unless it's in a package, because then it's no big deal. But writing it right there is a little difficult.

Also, the shinylive application is embedded inside an iframe. So the app code values and normal things that you would find with a runtime Shiny or server Shiny application or file, where you can retrieve values down in a lower chunk or a higher chunk, it's not possible here because shinylive is put inside an iframe and that isolates the app. And so values are not able to be shared as of right now.

So how do we do it? You switch your little R chunk engine from R to shinylive R. And standalone true. Don't know about that one, but it's nice to have components of editor and viewer, and then your app code just goes below like normal.

For your front matter, for Quarto, add in Quarto extension shinylive in your filters. That way, this code chunk over here is processed and upgraded into that shinylive application.

All right, so let's take a look at that and what it would possibly look like. Okay, all right. So in my Quarto document, I have a filter of Quarto extension shinylive, and I have a chunk here called shinylive R. I want my editor and viewer component, and I just have a very small app of what is n times two. If I were to render this, hmm, hmm, hmm, hmm, waiting, waiting. It opens up. Quarto is hosting it locally. It's not doing, there's no server Shiny or anything like that. It's just a static HTML format.

And yeah. N times two is 140. Perfect. App works. If you, it's kind of interesting. It's not reproducible, but if you are wanting to and you do have your editor, you can change the code and put in new information. So if I hit play, then, oh, new title. But if you do refresh the page, then your local edits are forgotten and you go back to the original document.

Oh, Gandalf, what do you have to say? Keep it secret. Keep it safe. Unfortunately, Gandalf would be very sad about shinylive. Yeah, it is good for education process. It's very, very handy for that because education tends to be a lot more

about the content and the content itself. Education, typically there are no secrets. You want the students to have everything. A little difficult for grading, so I don't recommend that.

But for Shiny Live applications, there are no secrets. The whole app is in the browser. The user can inspect everything within the app. If I were to go up and find an app, I can go through the codes and I can find any password, any thing that you thought was safe is normally safe with a Shiny Live app because the Shiny app would be behind the server.

So it'd be in the central server. But now with Shiny Live, the server is on the browser. So the user can find it and that's where it gets a little interesting.

Yes. Does that include the data that is embedded in the app? Yes. Everything is in the browser.

There is no PositCloud for the session today.

But yeah, so everything is in the browser. So if you have a CSV, I'll be able to find that data. It can be found. It's a little spooky, a little different. But we need to kind of draw the line as to where there's some advantages and disadvantages. And this is one of the big ones. And if you are trying to connect or read from a secret API that you don't want users to know about, it's not secret.

And if you are trying to connect or read from a secret API that you don't want users to know about, it's not secret.

They will find it or can find it.

Limitations of shinylive

Some other limitations. If your packages have a hard dependency on the curl package, then the parent package is not going to work with wasm. There's a known technical difficulty with curl in wasm and doesn't work. So if you change it to like a suggests, you might get away with it. But that's something to be aware of, including curl, because it's kind of like a system dependency in what it does. Not all system dependencies are currently working with wasm within WebR. There are room for improvement, and George is excited to continue working on those.

But not everything is automatically there for everything. So I think he got a lot of the packages that you see to work. And that was great. So I think he's at like 70 or 80% of cram, which is really impressive, given all the different behaviors and requirements of each package. But it's not 100%. So just want to put that out there that you may have difficulties if you're doing something with expert requirement. And similar to curl, external databases do not work.

That streaming connection is going to be another big difficulty to get over. But then I would even I would even like go again to say that there are no secrets. So if you are connecting to a database, you are notifying your users where they can run their attacks if they want. So again, no secrets.

Eric says, regarding databases, I'm intrigued by the process progress DuckDB is making with WebAssembly. Oh, it's super impressive. There are things that George has demoed that are not purely shinylive, but what he's able to do with WebR, which just are mind blowing. And they're so fast. And then having DuckDB be your database, and then having WebR run things in the browser. It's just absolutely amazing. So when as we start to iron things out, that will become much more user friendly. Right now we're just trying to see what's what's even possible.

David says, well, if the app is, if the app is stored in a public repo, then it should not be any worries regarding the secrets. Bingo. Exactly. So if everything is public, and you don't care that it's public, then GitHub Pages is a perfect place to host it. And that's what we will do in the second half of this workshop is we're going to actually everyone I hopefully will be deploying their own app to their own GitHub Pages.

Howard asks, how do you get the GitHub page to run? Well, there's a couple of ways to do it. Howard asks, how do you find all the information? Do you inspect using Google Chrome? What do you do? You can just go to app.json. And that'll give you most of the stuff. So if you have my website, and then it ends in a slash, you can just add an app.json. And that'll give you most, most likely all the files. I had it here. Yeah, this app.json. So if it was pretty formatted, you can see like my app.r code. And then there's nothing else in this app. Oh, they even added in the readme. And also the our project file got bundled up as well. So you can find it there.

Most of the other things are fixed. But this app.json will get upgraded for everyone's exported app. And now I will hand the floor to Eric to talk about FDA submissions, because we've kind of gone through some of these limitations. But there's some exciting opportunities here.

FDA submissions with shinylive

Yeah, thank you, Barrett. So yeah, I'll take a few minutes to share some of my probably most exciting collaboration I've had externally with respect to this possibility, where this is rooted in a working group that I'm a part of under the R Consortium, called the Submissions Working Group, where a few of us in life sciences have gone together in partnership with regulatory authorities from the FDA, to look at the possibility of using open source software more in clinical submissions. And this has been going on in terms of, you know, fully sanctioned pilot projects for a few years now. And it was about two years ago that we were able to successfully submit a traditional Shiny application using R, completely open source files stored on GitHub, to the FDA through their transfer protocol. And it worked great.

Now, of course, we have a traditional Shiny app, A. Yes, you can run it locally on your machine. But then, when you want to host it, you have to obviously have a hosting provider for that. And plus, the setup procedure that we had for that particular submission was a bit involved of using RM to bootstrap the package dependencies, making sure that the version of R was installed accordingly. It was just a lot of setup effort. And then, you know, as we finish that pilot, then we start to see the advancements that Barrett mentioned earlier with WebR, George Steg's influential work, and then shinylive came shortly thereafter. And so, I had the idea of, well, what if we try a different method of submitting the Shiny application? One of those methods being WebAssembly.

And this is, when we started this, this is very early in the process. We didn't have nearly the coverage of packages that are supported in the WebAssembly framework as we do now. But as time went on, as we started looking at this feasibility in conjunction with a containerized approach, we thought the regulators would be more excited about the containerized approach, because that's, you know, Docker has been around for a while, and container technology to most of the IT sector is very well understood, whereas WebAssembly is a pretty new thing, especially in data science. It was about halfway through this pilot, it kind of, we flipped the script a little bit. They were actually more excited to get the WebAssembly portion, because it meant less setup for them, as long as they have a compliant web browser that's, you know, say Microsoft Edge, Google Chrome, or whatnot. Any modern web browser can run these WebAssembly powered applications.

Any modern web browser can run these WebAssembly powered applications.

And so, then the work, we started to do the work, as we say, we figured out, okay, on their environment, how can we successfully bootstrap a shinylive powered application? And the links that Bear is showing here, especially the GitHub repo on the right there, that has a complete scaffolding of what we did to assemble this Shiny application. And you're going to learn a lot about this today in the second half of the workshop, but we use shinylive to take a Shiny application, and then put a little bit on top of it to inject the publicly available data sets are part of the application submission. And then we give them a little shim to run the application powered by shinylive to an HTTP UV to run it in their local RStudio session. But technically speaking, the only packages they needed to do that to run the application that was already pre-bundled was HTTP UV. Once they have that, they can run it in a web browser process. And lo and behold, once we assembled the right bundle to meet the transfer requirements, it is now currently in review. We are hoping to get positive feedback in the coming months. But they have been very excited about this approach, and we think it can open the door for perhaps even more domain-specific applications that may not replace a clinical submission entirely, but it can serve as a great companion piece to showing dynamic web-based results, where a traditional, say, R Markdown HTML output may not be able to get you all the way there. But a Shiny web assembly application powered by shinylive can take advantage of the Shiny ecosystem. But now, in a way where they don't have to run this on an instance of, say, Posit Connect or some other hosting provider, they can all run this locally on their respective machines. So again, we're very excited about it. You can see the links in the GitHub repo there if you want to look in more details, as well as the setup that we had them complete to get it onto their system. We hope that as the ecosystem advances, this will be even easier in the coming years. But overall, they are very excited. We are very excited.

And as a whole, Shiny's already had a lot of inroads in life sciences, but I think it's going to take a huge leap as we go forward with this. So more to come in this space. Definitely stay tuned. But without shinylive and WebR, of course, this future would not be possible at all. So I am indebted to George and Barrett and the Shiny team for making this a reality because we are extremely excited about it. And you'll be hearing more about this certainly in the coming year once we get hopefully a successful review in store with the FDA. And we may try new approaches next year. So yeah, that's just a little bit of a nutshell, but I invite you to check out the links if you want to learn more. And I'll be around throughout the conference and the workshop here if you have more questions on that. Speaking of questions, I'll take one from Jared real quick. It's a good one. He's asking, would this setup be a concern for blinding or patient identification? Well, as Barrett said, any shinylive app, if you have data embedded into it, one way or another, that user, if they're willing to take the work and inspecting that application JSON file, could get their hands on that data. So for my perspective, I probably wouldn't use this in a confidential situation of patient unblinding perhaps. But what we did in this pilot submission is we used this on aggregated data that, again, was already publicly available.

But the other approach to keep in mind is that when you share this with a regulator, it is shared through their direct transfer protocol. And they're not sharing it publicly from their side. They're going to review it on their respective infrastructure. So at least they wouldn't be sharing it externally, so to speak. But certainly, yeah, if you have concerns about patient information, just like of anything in this industry, you do have to be careful on which products you're sharing or which, I should say, interfaces you're sharing to review those results. So those will be one of the issues I'm sure we'll be sorting out in the coming year.

But yeah, that's my summary of it. I can turn it back over to Barrett unless you have any other questions.

Shared with a big thank you. And yes, thank you, Eric. Thanks for all the hard work and pushing the envelope on this on the FDA side. I know everyone will appreciate hopefully a much easier submission process.

Yes, we will. And it's a team effort as well. So I want to make sure to make that clear. I could never have done this alone. But with the great advancements in open source, it just is so exciting to take advantage of that. So yeah, thank you.

Shiny Assistant demo

Jared asks, have you worked with Shiny Assistant to integrate into this?

Yes. I believe we have. What Jared is asking about, if we, Assistant, you can now go to gallery.shinyappsioassistant. And put that into Zoom here. And you can say, you can say, if, sorry, let me introduce this. So Shiny Assistant is a newer thing that Winston Chang has been working on. And Shiny team has been trying to integrate with into these large language models more and more. Because a lot of what they're good at is to remove busy work. And really, the hard part of coming up or building a Shiny application is knowing what you want to do. Executing that is, I think, and one angle of looking at it is busy work. Something that is solvable, but describing what you want, things like that, is quite difficult. So what we've done is trained the large language model to, that's more code based, not necessarily chat GPT, which doesn't quite do as well with code directly. But instead, we're using Anthropic, which does a lot better with code. And you can say, I'll try to recreate the old faithful application.

And so, have we used Shiny assistant to integrate this? Oh, no, that's Python. I want R. Go. That's why the geyser doesn't exist. I'll just resubmit that. Refresh. R paste. Done.

R paste. Done. So this whole right side is actually done with shinylive.io, which is done with, oh, that's really cool. It's fun when the demos work out. So I just described it in a short paragraph, and it wrote this whole application for me. It had the liberty of adding in this teal color. But it, you know, also did the main title in the X lab on what it's doing. Great job. Good bot. Nice job. Do it again. Yes. Very pretty liberty. Yeah. Looks good. And then what we can do is we can then share it, copy the editor, and, you know, you're back to shinylive.

So it's not a fully exported app, but it's using shinylive.io, which if you can use it in shinylive.io, you can definitely export it to be statically hosted.

Q&A and community questions

Oh, Kenneth Taylor, you've done stuff in the QA spot in Zoom. How do I look at this? Q&A. Oh, there we are. Right. Shiny app that works.

Kenneth is asking that he gets his app to work when exporting, and it works locally, but when push to GitHub fails, it just gets a blank page. Maybe we will debug later, because that seems like a very specific question. I hope, excuse me, we can go through the steps to make sure that you're in a good spot. And says, also, I found that importing custom Google font to use in the app gets successfully applied to everything except for ggplot2 objects.

Oh, yes. I couldn't find any fix for this. That is unrelated to shinylive, but I am excited about the package and how to fix it. It is thematic. So, thematic is a package that Carson Sievert is the lead developer on. Yeah, I'm in there, but, like, Carson did the work. And what's really, really cool is you just have your app, and it's doing its stuff, and then you add in thematic, and if you can look, the titles of this plot is now in the fun font that the rest of the app had. Also, the theme of the background colors, the shading, it all is kind of taking after your primary and secondary color scheme. So, I would suggest to look into the thematic package.

Oh, Nate asks, can it take non-cran packages? Yes, I would suggest you use the R universe, and I forgot to add it into the slides about R universe, but it is building. It doesn't state it here directly, but it is building these for Wasm. So, if you set your cran location to point to R universe, you can get extra packages that way.

And let's see. Would shinylive make easier deploying apps as desktop app? It depends what your version of easier is. I think it scales much better, because it's infinite scaling for free, like, virtually free. And he has asked about that. So, it all depends as to what you're trying to go for. If your goal is distribution as easy as possible, I really like shinylive. If you want security and secrets, don't use shinylive.

It does remind me, Barrett, we've seen in the community some attempts at putting Shiny apps in an Electron setup. Do you think those things are still worth pursuing for developers, or you think WebAssembly or shinylive is the better way to go?

I think Electron will do the really nice applications. I know there are ways that we can get it to be a progressive web app. I think that's something that possibly shinylive should do. shinylive.io should perform so that you could just write it in shinylive.io and then it's available. But you could also have Electron just wrap your small static folder and have Electron host it. And that's a really nice combination, because Electron's good at the app part of it, but you can just have it essentially just be an iframe. And that's the end of your app. Application. Your computer application.

Yes. Libby's asking about if you just set your CRAN repo with the options that way. I believe so. I believe that's how it works. And if you have GitHub packages, using r-universe makes it so that you don't have to have your package published to CRAN, and it will collect it, like, roughly every hour for all of the packages that you organize.

Slido's funny. I hope I haven't missed anyone's questions there. I've checked the Slido. There hasn't been any that show up on my end. Gotcha. Perfect. All right. Let's it's been an hour. Let's take a quick break. I am so excited about this. Let's see here. All right. So, I got a five minute break here. These hex stickers will slowly disappear. But let's come back in a minute. But let's come back in five minutes. So, let's say five minutes after the hour. We'll be good. All right. Thank you, Barrett. Yep. Let's all take a quick break here. See you soon. Yep.

Private GitHub repos and reusable workflows

Hey, Barrett. I believe there was one earlier, and I'm not sure if you had already discussed this about being able to utilize shinylive with a private GitHub repo.

Private GitHub repo. Yes. I will not cover that today, but it is possible.

Let me think of nice links to give you. So, within we'll come back to this, because there's still time. There is releases and tags. This part, reusable workflows. So, in your private repo, I would do one of the two things. Build a CRAN link. So, this one is deploy a CRAN repo. So, that is like within your private org, you would have a private CRAN repo that you would deploy to. And then this one here is release file system image. I think this one might be a little bit better, where you can it basically adds in an asset file to your GitHub release. And if you install from GitHub, given the GitHub release, or like that tag, then when we go to export your application, we will see like, oh, Barrett's secret package was installed from GitHub, and it was on this page. And then secret package was installed from GitHub, and it was on this tag. And I can see there is an asset file, which happens to be a WebAssembly like image. And we'll download that and use that for your package, rather than using the one that comes from the WebR CRAN repo. Or the WebR CRAN instance.

So, it's a lot more handholding than what our universe does. Our universe just kind of does all of that for you, where our universe is a CRAN instance for you. And then it will, you know, bundle it up for you. But if you want to do it manually, here's where we go. I will put this in the link. Love the expert question.

So, if I remember you saying correctly, Barrett, you said that even for an organization that's got a private GitHub organization, but it's hosted on GitHub.com, we could do this as well within our organization? Yes, you would need to do this reusable workflow stuff within your org. Much more handholding. And if our universe has private repos, but I don't believe they do. I don't believe so either. But I will be pursuing this for sure, especially in the coming year. Awesome. But the nice part is what we've tried to do is make them reusable workflows. Just more in the idea of a contract of, like, hey, when you release something, like, where is it? Deploy. So, you can just with this line, you can download that action. And then what will it do? It will try to say, yeah, we have an example somewhere else. But we hide away all of the difficult work.

And, like, one of the things that I thought of was, like, when you're doing R command check on GitHub for a package, usually RLib actions likes you to copy their workflow and to execute it. And this is cool for, like, one or two packages. But when you're working with, like, 50 packages, like the Shiny team, that's not fun when you decide to, like, update how things are executed or your R versions or anything else. And so, instead, the Shiny team is utilized using reusable workflows where we have one central file of truth. And in this case, it will be stored inside our WASM actions. And we just say, hey, please call that action of, like, reusing it. And then, like, the logic will be maintained in one place. Because as a user, you're not wanting to maintain it. You're just wanting to keep that intent. And, you know, it's kind of nice having it be someone else's responsibility. It's just like the ethos of an R package itself. Someone else is maintaining it. You just want to use it, right? Yeah, this is huge for us. So, we're looking forward to playing with that. Perfect. Please do give us feedback if you are using it. We originally made it in, like, aspirations. Hopes and aspirations. We don't know if anyone's using it. Because it's only really going to be done with private. So, please do give us feedback. And we'll try to improve where we can.

Oh, thank you. On the break slide, I was very excited about, oh, we can just make really slow animations. This is perfect. I'll have to figure out how to replicate that in Quarto. Because you got me intrigued. I did the

timer thing for our break stuff next week. I'm honestly jealous of the timer. Because I couldn't embed it. Get back to Quarto, Barrett. No, I'm kidding. Yeah.

All right. It has been a couple minutes afterwards. So, let's get going again. Eric, if you don't mind sending in the slides again to the chat. All right. Deploying. So, over the break, we are talking about some advanced deployment. And the goal of today is to have you hopefully not have to answer those harder questions yourself. And instead, it'll just kind of be a set it and forget it. And it's just going to work. And that's the kind of packages and executions that I enjoy. Automations. And you don't need to worry about it.

So, all right. What are we going to do? We're going to deploy. And this is going to feel a little slow. Possibly. But I want to kind of make sure that we can herd 120 of you at some point through. And so, we're going to, you know, pad it just a little bit. But you could, if you wanted to, stream through this in like under five minutes. So, that's also the exciting part. That you can rapidly do this if you have multiple GitHub repos.

Forking the repository

So, uh, now I'm hoping that, uh, all a hundred of you have done it. Let's see if the number goes up. Does it? Ooh, 14. I'll take it. All right. So assuming you have this, uh, what do we have here? Uh, we need to enable the publishing of the website through GitHub actions. So that is a lot of words for, we need to just check this setting deep inside the settings.

So let's, uh, open this up into two tabs. All right. So what we need to do is, uh, let's see. We'll go to the settings that I have in my personal top right corner. It's not under my, my, uh, picture, but in that top row. Um, so I hit settings. I go down to pages, which is the bottom of the second chunk on the left. And then under the build and deployment, the source is going to be put to GitHub actions.

Um, and what this does is it will enable us to upload a kind of like uploading a zip file and say, hey, do your GitHub. This is the website. This is what we're doing for the website. Or normally if you're a package developer and you've done it with, um, uh, your, your special branch of like GH pages. So whatever is in the GH pages, uh, branch, that would be your website. And then there's a get history and everything. But really in most of our situations, we don't care about the historical value. We care about the now value for the website because the, the now value of the website is determined by whatever the code is. Um, it's just like an extension or reformatting of that code. So instead we've had it, uh, do this build GitHub actions approach, uh, which will just deploy from a static file. And then your repo will not balloon into an infinite size, which is not fun to deal with, uh, when you have some non-trivial data.

Setting up auto-exporting with shinylive

So now that we've set the GitHub actions, um, we'll go back to the code, see what the readme has. Readme says, um, enable done. Let's set up auto-exporting of the app. Um, cool. All right. So enable, we'll set up auto-exporting of the app. I don't believe I have this on my machine. So let's give this a try.

So what I would like for you to do is if you don't have pack, oops, if you don't have pack installed already, please do install dot packages of pack. Uh, I think it is a wonderful way to install, um, packages, uh, even just for the fact of, uh, it will parallelize your install. So if you have something kind of from a fresh start, um, and you have to install a hundred packages, it will try to find the best way to parallelize that over your machine. And it goes really quickly, um, compared to just the linear installation that are, or other packages will do by default.

Um, so we'll go pack, pack of shinylive, which will install shinylive from grant. And then right afterwards, we'll want to call shinylive assets ensure.

So shinylive assets ensure. Yeah, no, it won't, it won't freeze your machine. Like peril, paralyze it. It'll parallelize the downloads. Yeah. It sometimes does paralyze the machine in while installing.

Um, right. So I'm going to make this a little bit bigger. So I'm just typing this out. Assuming we have shinylive installed, um, assets info. Um, what this will do is, um, shinylive assets info will, will inspect your machine to figure out where the assets are installed on your computer or server, wherever you're at. In our case, or in my case, it's, you know, user Barrett it's on under library caches. Um, so this means that it's not in your, our package. It's not in your local folder. It's, it's stored away within your machine because we use this folder to like copy out or extract our assets as, as we need. Um, it'll be like 250 megs, 300 megs. It's, you know, slowly ballooning, but, um, yeah.

Let's try assets info. I'm just going to clean this up just so we can see, um, assets remove 0.0, 8.0. Great. So I've removed it. Uh, if I look at my info, it should be empty and, you know, great. Uh, so I had asked for assets ensure and, you know, progress bars. Thank you community. Uh, that wasn't originally there. Um, but now thanks to each, uh, hit her too. Um, you have this downloading and a progress bar and it's just awesome. Uh, I'm using the dev version, which has the slightly higher, uh, shinylive version of 0.8. Um, but you should be getting 0.7 or 5, but that, I mean, it works.

Um, hopefully if you get the latest shinylive on crayon, um, you'll get the, uh, yeah. shinylive on crayon. Then you'll get a newer one. Have we not released it? Wow. It's 0.5.

Um, yeah, it wasn't HTTR too, uh, for the hitter to package. Um, yeah, I think the same tongue twister applies to HTTP UV. Um, you can't say it quickly. Um, and you really want to, um, but I can't find a nice way to pronounce it either.

So, uh, now that I have assets insured, uh, I can look at my info and I will see that I have something downloaded. That's the important part. Um, if, um, okay. So now that we have this locally, I just kind of want to go through like what, you know, bring up those docs that we were talking about earlier. Uh, so exporting an app means that we're going to take the app that's at this current location and, or some location and export it to a different location. And, um, that must be hosted. So I demoed that earlier. I'm just going to do it again. Um, just because I think it's important with it.

So shinylive export this local folder and export it to out, um, demo. And it goes through it, downloads it. And if you did not have your assets already downloaded, then, um, uh, if you do not have it already downloaded, then it will download them for you. Um, oops. It looks like it's picking up that outbear. It is already there. So maybe don't export it into the same folder, local folder. Um, we'll try that again. I'll, I'll go ahead and delete. Yeah. Delete. Yes. Try this again. Cause it got a little mad. Um, yes. Sorry. I'm running a dev version, um, bleeding edge of the bleeding edge. Uh, uh, but we'll get a release out on cran to get that updated for y'all.

All right. So HPV run static server and I can do it with demo and it shows up. That's all right. So it does work, but like this cadence of like doing this, it like you have to download the assets you like once, but you do have to have them on your machine. And then you do have to run the server. Like, and then if I were to shut my machine off, then the server dies, you know, that's why we do deploy things. Um, so that's why it'd be really nice instead. If we had GitHub actions, do this for us.

GitHub pages and GitHub actions

So GitHub actions have been talking about this looting about it, but I haven't actually like introduced it. Um, GitHub pages is a, um, uh, thing that, uh, GitHub allows for on every public repo or private if you do that. But, um, today we're talking about public repos and it, they basically just say, given your repo location, we will either use that single file or we will use a branch and we will host that for you for free. Um, so as an open source developer, this is awesome. You get a free website, free content to be hosted. And, um, you know, it's all tracked through a version, version tracking, which is just great.

So GitHub pages hosts the website, but, and, uh, GitHub actions is the thing that's also free for public repos. And this is a big one, uh, because you get free executions for every commit. If you want or pull a request, commit, or, you know, whatever you'd like to do. And you can actually do a lot of work, uh, done by GitHub for free. Um, I've talked about this in a different presentation, but I, I like did napkin math on what the Shiny team does. And I think it's like $80,000 in fees that GitHub would have happily charged us if we were a private repo. Um, this is, I'm testing 150 applications every work night on three different operating systems on five different R versions. So it's like 2000 apps every night. Like, um, it's not something trivial and, uh, GitHub actions is free because the repo that we're doing it on is, uh, public. And I think just like a wonderful little, uh, perk of being a public repo.

Um, I've talked about this in a different presentation, but I, I like did napkin math on what the Shiny team does. And I think it's like $80,000 in fees that GitHub would have happily charged us if we were a private repo.

Um, so using the combination of GitHub pages and GitHub actions, we can then host our app as a website because we will, uh, have the action, download our repo, inspect the app, uh, quickly. And then we will, uh, tell the action to post to the pages. All right. Uh, so we've already updated our website settings. Sorry, I jumped the gun there. I was just excited about enabling that, that setting. So we've already done this part and then, all right, let's demo integrating GitHub actions.

Integrating GitHub actions with usethis

So if you don't already have it, I, I recommend that you install use this package because it will download the, um, uh, action for you and, and do all the things there. So what is this one linking to? This is a link, uh, to, uh, the use this command, which is quite long.

Um, which will say, let's clear it up here and I'm in the final. So if I run this, it's the use this action where you say, all right, use this, use GitHub action. And the URL is from the rshinylive website under the actions one V1, uh, tag, and we're going to deploy an app. And I love use this for this because they, you know, okay. Set the, set the project. It'll create the GitHub folder for you for that GitHub actions uses. It'll ignore the GitHub folder. If you have a package, it's very useful. Um, does some more get ignores, creates the workflow folder, and then it finally copies in your YAML file, lots of stuff. And it's so nice that it's there to be used with any repo that you do.

Um, all right. So let's walk through, uh, the code. Cause you know, I, I do recommend that, you know, if you're ever downloading and running something on your behalf, take a peek, uh, just want to make sure there's nothing funny in there. All right. So some comments, great name. Good. This will run when I manually trigger it. So that's a workflow dispatch. Uh, so, uh, after the first run, you can then come up to it and hit the play button and it will just redeploy again. Um, then it'll also run whenever we deploy to the main branch. So that's good. And then we'll also run it on polar, every single pull request, uh, commit, but, um, it will not deploy the GitHub pages, uh, underneath the hood. Uh, we have a check for that, but, um, on push or on workflow dispatch, it will push to your GitHub pages.

Um, in the jobs, uh, we have, um, shinylive, a single job. And what it does is it's a reusable workflow. And so all the logic is hidden in here and I don't need to go through it, uh, uh, for now, or you can walk through it later. Um, but that file is where we will do all the deploying of the, the download are set up your package, find all the dependencies, uh, export it and, and then upload it to your pages. Um, because we are uploading to your GitHub pages, we do need to, uh, grant some permissions. Uh, and this is where I say like, you know, peak at what the code is doing. Um, because I could be like, Oh, give me permissions to delete your user repos, like that'd be really bad. Uh, instead it's just saying, Hey, some pages, we need to write to it. And then I need an ID, uh, token so that, you know, we can verify the deployment originates from the appropriate source. This is recommended by a GitHub and what we need to do. Um, and so we just have a very minimal set of permissions to deploy your, your application.

Watching the GitHub action run

Um, so let's actually commit it and see what, all right. And then commit. And we say message, um, shop tasks. I don't know. That looks good to me. Commit done and push. Don't forget to push. All right. So this is the GitHub. Our informant app. Great. All right. So now we're here. Uh, I have this little pending thing, uh, orange flag right here, but what we can now do is we can go to the actions tab and we can now see that there's a first, uh, task being run and we'll go ahead. And here's that play button for the manual deployment. Um, but we can click into the workshop. We can see shinylive is building. Uh, we'll click into that as well.

Um, so I'll put this into the chat for everyone here. Um, so you can follow along with it. Um, some days I stare on these styles of pages, you know, it's a little bit slower turnaround when you're having errors happen every five minutes. That like four minute mark is the worst because you can't go do something and you can't start another task, but it's four minutes. Oh, it's a long eternity. You know, Barrett, I could have a whole podcast episode about debugging GitHub actions. That's just waiting to happen. When things go wrong, they go wrong. Yes. Hit random keys on the keyboard. Try again.

Um, so, okay. So let's see what this is doing. We have a couple of tasks being run. So they're setting up the job. That's not us. That's GitHub. This is us checking out the repo. We then are setting up, um, using some more reasonable, uh, actions done by the shiny team where we're setting up the R package. In this case, the package is not there, but it sets up R and a couple other dependencies. Um, so that'll take a couple of minutes.

And then what we'll do is use our end to inspect the app dot R. It's not using a, um, yes. Thank you, Libby. See you. Um, it's not using our, our end to restore. Uh, it's not set up for that. Um, if there's interest, we can set up that, uh, reasonable workflow, but in this case, it's just inspecting the app dot R to find, um, dependencies that way. Oh, why it's not using our end of restore is because, um, packages, uh, being done that way are not easy to reproduce, uh, within GitHub pages. Instead, I would highly recommend that you manually export your app how you want it. If you have custom, uh, packages being installed and it does work locally, but I would instead try to set up how that's being done. And I think we might've done it through the extra packages. I don't know for sure. Uh, hook, uh, for the reasonable workflow. Something to look into.

Still installing R? Yep. It's moving. So fast. So fast.

One technical question, Barrett. Does the, all those Linux packages that are being installed at the top, do those get cached in subsequent runs? Uh, yes, we do have that. Okay, cool. Thank you. Yeah. So that'll be faster if we were to hit play again, now that it succeeded. Um, Oh, uh, finished. Awesome. So it's not, it's not there yet. There's a couple, you know, it's not fully magic. Um, so we built, we found the dependencies using RN and then, uh, two packages were installed. Um, and then there we go. And then we, uh, built the site by exporting it. That took nine seconds. Awesome. And then we uploaded that site as an artifact really fast. And then, you know, just some cleanup steps for GitHub actions themselves. Uh, that upload site artifact is then transferred over. If we were to look at here, this GitHub pages right here is transferred over. It's sites, 44 megs. That's not bad. Um, and then that's put on deploy and that's where we then deploy that to the GitHub pages.

This will actually spawn a second job. Um, I believe. Um, Oh no, it won't. Uh, can't remember. We'll check. Um, so the one trick that I like to do to get to the website is I say website, use your GitHub pages. Um, and then it'll populate things. Uh, I just have a custom domain for my personal one and just kind of propagates to every repo underneath, but yours would most likely say, uh, GitHub.io slash or like user.github.io slash, you know, uh, workshop, aren't from a shinylive app.

Uh, and then if we click to it, let's see, Hey, workshop aren't from a shinylive app. So this has never been done. Websites up. Hello. Shiny. Woo. Like live demo works. I'm very excited about this. Um, Oh yeah. Let's prove that it's working. Shiny is, is up and running. Hey, another success. All right. You can sleep easy tonight.

Websites up. Hello. Shiny. Woo. Like live demo works. I'm very excited about this.

Updating the app and redeploying

Um, all right. So let's see where we are in slides. Um, so we did deploy to get pages. Let's update the app. Um, so let's go into the app. And we're going to edit the file. And I'm just doing this to show that when a new commit occurs, we will redeploy. And hopefully as Eric said, the packages will install faster. So our pharma 2024. So the title will say that let's commit, say, change title directly to the main

And then we can go back to the actions. We'll see the change titles, but ready to run. And the last one took seven minutes. So this will take, uh, hopefully five, four. Um, and we'll see that it runs.

Um, so, uh, sheen is asking, can you connect to a live database and publish GitHub? So one thing that I would, you can do some work arounds that I've done is if you're doing a database that has a, uh, rest API and the rest API, you can have a get request. So you're not doing posts or post puts, but, um, uh, just as a standard get, then I found that the read lines function works. So you can read lines from a get API, a get rest API, and that allows you to retrieve data easily. Um, and then that makes it so, you know, obviously I would know where you're downloading your data from, but, uh, you can dynamically download that data. You know, once the app is up and running.

That's an interesting point, Barrett. Maybe I want to restate that because you can give me ideas. So a database that we know we don't want to give like full access to the, to the given reviewer or whoever's using the app, but yeah, putting let's, let's plug a plumber API in front of it that has a get request to a certain set of operations that only that app needs. That seems like the approach then to get around, you know, giving full database access if I'm understanding correctly.

Yes. Um, but it, by putting your stuff in an external database, uh, it then will break the reproducibility aspect, but it'll make it so you have dynamic data. So, uh, you know, pros and cons to each approach. Um, uh, you can have, as you said, you have your security done within, uh, your plumber server or the, the API. Um, but yeah, read lines is, is, has I've had success with it.

Deployment and browser cache

Website deployed, refresh and no, no, it'll think about it. It'll come back. Um, this is where usually it's like, try one more time. Or could you open it as a private tab? Ah, there we go. Got to bust that, that browser cache.

Great suggestion, Eric. Yes. Browser cache is so funny. It's the same website. This one's loaded later, but this is the most recent. So, uh, yes, but it does work. Um, it got updated. I didn't do anything. I just committed it like normal and it automatically finished it. Uh, I don't necessarily know the details of how the GitHub action is working. I just know that it's on every commit or I can even come in. And if there's just a funny reason, but I, uh, difficult to come up with one. Uh, you can come in and hit the play button and say, please, uh, run, run this workflow, uh, manually and just run it and it will redeploy for fun.

So I think that's just so neat and so powerful and it's automatically done. You know, I love the aspect of like sources to find an app dot R let, let all the magic happen like behind the scenes. Cause it's not, um, it's tedious to maintain.

We had a successful deployment done five minutes early. This is a good day. Other people have succeeded as well. Very good day.

Q&A: logging, load times, and security

Um, uh, I know it says Slido, but I'm happy to do, um, Q and a and zoom. That was pretty successful last time. Uh, and then if, yeah. Uh, anything, if you guys are going to take off early, which I completely understand on Friday afternoon, here's some quick links and docs on places to look. And yeah, thank you for for hanging out today.

Okay, we got some questions coming in the chat. I may just read them to you if you want, if you don't mind. Aida asks, how can I track my apps logs? Do they act the same way as any other server?

Logging is done like if you're thinking in the instance of like Shiny, shinyapps.io or within connect. Logging works because there's that centralized server. And so every user is doing their heavy lifting in one location, and we can track those logs. In the case of shinylive, it's pretty impossible to track the logs unless you're like reporting them yourself. And you know, then we're getting into databases or, you know, streaming or posting information. So it's difficult to do, if not impossible. So it is easy when we have that centralized server with regular our shiny with shinylive and have and it's distributed by nature, there is no like centralized logging system. So sad face on that.

In the case of shinylive, it's pretty impossible to track the logs unless you're like reporting them yourself. So it's difficult to do, if not impossible. So sad face on that.

Okay, we got another one here from Howard. It's more of a confirmation. It looks like he's asking, does your shinylive deployment show a white screen for a few seconds, then show a hexagon thing for a few seconds before loading? Maybe it's just my internet, and he gives a link to his version of the app. But I'll take a stab at this bear because I've been intimately aware of this with the pilot submission. Depending on your bandwidth, your respective computer or laptop, this can take longer than other times, right?

Absolutely. Yeah, there's a lot of files being downloaded. I did click on Howard's link, I did get a white screen for a little bit longer than what I was doing, his hex logo is longer. But now that it's been cached, well, I've disabled cache here, so I need to close this. But if I hit refresh, demo fail, it is not as fast as the ones I was doing. So I don't know why, Howard, yours is a little bit slower. Maybe your GitHub instance is across the sea, and the ping slows it down.

Yeah, we've had this similar issue even when we've been getting back to the pilot submission when we were kind of testing things out with our FDA reviewers. We have one that could load it after about a minute or so, certainly we're using more packages than what your demo app does here. And another reviewer couldn't even access it at all because of proxy issues with their VPN. So there are always like these network issues that can come in play no matter where you're hosting these apps.

Yes, and package loading has turned around to be much faster now. And that we're really trying to bundle it and so that when your app is being loaded, and maybe it's in the GitHub version only right now, as I'm stating this. But the package is being loaded. It took 30 seconds before and now it takes like, ah, so that might be why.

All right, let's back up a second. Why is it taking Howard longer? I have the same internet on my machine. Why is Howard's app slower than my app? This is the difference between the bundling system that we've done in the last couple updates. So it's a weird thing to say, hey, we fixed the internals and made it better, but there's no difference in the app. You know, it's really exciting when there's like one main function, but this is the difference. Howard's app was done with 0.5.0 that he put in the chat earlier. And mine was done with the shinylive assets of shinylive assets. The one that the WebR is using is 0.8.0 and there's been a lot of updates. And so the package start time, you know, it's still struggling here and it's taking a bit. But now in the newer stuff, when I refresh one, two, three, four, four seconds until the app shows up in another second for the image. So five seconds rounding up where in Howard's situation, it's 30 seconds. So we'll get a CRAN release for shinylive out because that is a drastic difference.

I was poking around the GitHub repo for shinylive and I didn't see the 0.8.0. Is that a custom branch on the repo? It is not the package version, but it is actually the version R. It is the shinylive assets version. And the assets is the big bundle, the thing that I was trying to ensure was downloaded. And that is different than the R package version, which is going to be 0.2.0 or in our next case will be 0.3.0. But yes, good catch, Howard. Fun to do a live debug here.

Private repos, SSO, and hosting alternatives

All right, Curtis, sorry to realize you discussed this earlier, but if this is deployed to a private repo, it would be okay to share the link to a website. Can you implement with SSO? Apologize if it's beyond scope. So private repos in GitHub do allow for websites. They do allow for websites and what I want to say here, the websites though are public in that you can inspect all the content of your website if you know the file name. In our case, we know the app.r and other stuff. So it is not necessarily private as you would like. The app, I would be able to inspect it even if it originated from a private repo. Your other half of your question, can you implement SSO? GitHub pages does not support that. If you did something within your app, that's within your app. But we would also be able to inspect your app code on the outside because you would only be doing authentication within the app. So I think it's just a no-win situation for security.

It is an interesting point and kind of dovetails on a question I was going to ask again. As much as, yeah, for open source work and public facing apps, GitHub pages is by far the easiest on-ramp to get these applications shared online, again, through the magic of shinylive here. For those of us that maybe need to look at an alternative even to GitHub pages for organizations, I've been looking at different hosting mechanisms, one of which that I was surprised actually kind of works, is at my day job we have a Linux cluster, we call it an HPC cluster, and we do have kind of a web space component. Those familiar with Linux, you may be familiar with, we have a public underscore HTML directory. You can expose that as like a makeshift web page, like it's served by Apache or whatever. And I did get a shinylive app to render with that, it did take a while, but it was kind of shocking to me that it would render when I copied those exported assets over to like my public HTML space. Barrett, I guess my question for you is, do you recommend other types of hosting for an organization that could work in the absence of the requirements that a hosting provider needs to have to install, to run these assets?

It's not so much too big, I think it's more of, do we just want a place where maybe it still stays within our firewall of our organization, but it's something that we could give a client or a colleague an easy link to, and then within our company's intranet, they could browse through it pretty easily. One thing to note is that in my organization we use a lot of SharePoint, but obviously you can't put shinylive apps in SharePoint, right? So are there other options available to us that might work there in your experience?

You can, so talking about security with that, I mean, I work at Posit, so I will state it, even though I'm an open source developer, Connect does a really good job with authentication, maintaining authentication on who can see what, but I would also argue that if you're going to be doing something that needs authentication completely locked down, then I would not use a shinylive application at that point, I would just use Shiny, because then your database can be secret and you don't have to think hard about that, and it'll all just be hidden naturally, the way that we're all used to.

But I think where shinylive will excel is having a public content, public information, and you're not trying to log it or do any form of authentication, you just want to share your work, shinylive and GitHub Pages is a wonderful combination.

But I think where shinylive will excel is having a public content, public information, and you're not trying to log it or do any form of authentication, you just want to share your work, shinylive and GitHub Pages is a wonderful combination.

And I would imagine in the coming months, as now more people are getting lined up with shinylive, we're probably going to see more questions related to this, because it just opened up another realm of possibilities where we can share Shiny apps, where before, like I said, in the traditional sense, it was either a Posit Connect server, a shinyapps.io server, or things like that. Now we've got different options available, so it's going to take a bit of trial and error, I think, for each organization to figure out what best fits for them.

If you also have things that are like, oh, I make viral Shiny applications that would just burn through your shinyapps.io hours, you can then port it over to shinylive and with the GitHub Pages. And it's free, you don't get logging, there's not much other stuff. If your app is tweetable, then it's something that would work really well with shinylive.

Wrapping up and final questions

Howard does have a comment here more than a question. Is shinylive feels like a free open source version of PositConnect or shinyapps.io? Now, I can see where he's coming from there. Yes, absolutely. I love this virtuous cycle because it also does feel like shinylive is a connect killer, you know, like, oh, we just gave away all of our money. But there is some infrastructure that we had to do and there are no secrets. There are no centralized logins. Databases aren't possible right now or probably won't be possible. So if you can get stuff done, maybe like in the education space for free, like this is awesome. That is perfect. But once you start getting into sensitive data, you want to keep information away from your users, then having it in a normal Shiny application is better. And then I, you know, highly recommend Connect with all of its authentication.

Ironically, for the pilot submission, Barrett, I had done a custom GitHub action to deploy the application, like a what I call a preview version of it for our reviewers, online via Netlify. But now that I know this, I can probably change that to just a straight up GitHub page. That was that was my little hack around them before I knew about these actions.

One, one, one question that again came coming from me just because I'm such a geek with shinylive and WebR right now. Have you tried using a Shiny application that was constructed as an R package deployed via shinylive? I personally haven't done it. But what would happen is your your app.r would just be like my awesome package, colon, colon make app, like execute. And as long as it just returns the Shiny application doesn't run it, but just returns it. And then that will be the last thing returned in the file, which is what Shiny then, you know, prints and then runs for runtime. Yeah, it just makes your app.r really small, which is awesome.

This is where things like the play button would work really well for deploying your website. So if you update the package in another repo, you can then come over to your app.r, hit the play button, and then that will automatically or it won't automatically, it'll manually deploy your application using the new posted thing. But it's not super fast. So it either have to be done through your, you know, our universe or your crayon. And, you know, that's not it's delayed a little bit, but you can at least hit the play button rather than committing a fake commit to your repo.

Interesting, yeah, because for the pilot submission application, the original one we created with the Golem package as an R package, which worked really well for us, but then at the time we were making the pilot for app, Golem was not supported in WebR. So then we had to pivot to Rhino in that case. But I'm tempted to go back to the Golem framework, because I think Golem is supported now from what I saw in George's updates. So I may give that a runes and report back if that if that workflow works as advertised.

Awesome, yeah, I hope we can keep it to dealer's choice and developer's choice and just whatever is best for you. If it's possible, then let's see if we can get it to work.

Well, with the few minutes we have left, I'll keep an eye on the chat here. But for for those in the audience who want to keep up with what's happening with shinylive, what would be the recommended ways that they should keep in touch or at least keep an eye on what's happening in the in this ecosystem? The R shinylive repo is a great place to to go. It's pretty light. If you're more into the weeds on things, the R shinylive repo does link to the shinylive assets. And that is where a lot of the magic happens. And or you can follow WebR or George and whatever he can do. But yes, we'll update R shinylive here and then get that out to CRAN because that demo demoable difference that of Howard's app and my app is shocking. So everyone should have the fast one.

And for those that want to follow your your efforts in your dev journeys, where should they get a hold of you? Or at least see where you're up to online. Find me on LinkedIn slash Shlurky. See if you can type it on one go. And it's always a bonus point. And yeah, otherwise, I'm on I'm online on a lot of GitHub repos. And just find me there. I know it's not a direct one, but my personal site, I don't really maintain. So GitHub or a GitHub or LinkedIn will be the best.

And for those that are asking, yeah, thank you. We will have the recording up in months ish. Full disclosure, you're talking to one of the editors right here. So I'll definitely do my best to get it out as soon as as soon as possible. And myself and Jared on the chat here will be mostly in charge of that front. But certainly, Baron, on behalf of a huge turnout we had here for this workshop, we thank you immensely for your time and your generosity to put these materials together. You have definitely inspired many, many people here to try out shinylive. So, yeah, mission accomplished.

Very, very influential work here. And again, on behalf of the R Consortium group I'm a part of, we are so appreciative of shinylive and WebR and WebAssembly. It's going to be a game changer for us. Awesome. Thank you so much for having me. This was great.