Running R-Shiny without a Server - posit::conf(2023)

Transcript#

This transcript was generated automatically and may contain errors.

Today I'm going to talk about running Shiny without a server, but before I get there, it's come to my attention that some people in our community might not know what a server even is, and that's totally okay.

A server is a computer that's running 24-7, connected to the Internet, and it stands ready at all times to serve up your Shiny app using R or Python. Which makes sense, our apps are written in R or Python. So if you want to share your Shiny app with other people, you need a server. It is a requirement, and it has to be running R or Python.

And that server can take many shapes and sizes, this is a Raspberry Pi, that is a totally cromulent server, and you could have servers like this. Those are actually buildings in Toronto, but they kind of look like servers, so I was like sure.

And Posit and other places in the Shiny community make it pretty easy, actually, to get your app onto a server. You might not even know that there's a server on the other side. And we have stuff for the cloud, we have stuff for on-prem, we have stuff that's free, we have stuff that's enterprise-priced, and they all do a great job at the different things that they do.

But they all have trade-offs, right? They all have different pros and cons, and different trade-offs between cost, scalability, and features.

And this is especially annoying to academics, I think, when there are maybe pretty severe resource constraints on what's available to them, and yet there are things that they want to express with Shiny. And not just academics, but I'm going to pick on them, because I think I hear it a lot from them.

And what they hate is this, that the cost is proportional to the amount of computational complexity in your app, and the number of users. So that might have nothing to do with how much money they have available, but it's something that is a reality for them nonetheless.

So I think for a lot of academics I talk to especially, but also some hobbyists and freelancers, their attitude is like this, wouldn't it be easier if it all just blew away?

WebAssembly and the challenge of running R in the browser

And for a long time, that was a total pipe dream. But a few years ago, I started to hear rumblings about this thing called WebAssembly, or Wasm. And I'm going to give you the shortest description of Wasm that I can.

What is Wasm? Well, before Wasm, there was just JavaScript. The browser only spoke one programming language, and it was JavaScript. And it didn't matter how you felt about JavaScript. If you wanted to target the browser, that was the language you had to write in. And nowadays, browsers speak two languages. There's still JavaScript, and now there's this new thing called Wasm. But they are different because Wasm was designed for humans to write, and Wasm is designed for compilers to emit. So you don't write Wasm as a human being. You write code in something like C or C++. You compile it to Wasm, and that Wasm then runs in the browser.

Now let's talk about why this is exciting. And before we can, I have to come clean and admit to you all that I was wrong about Wasm, that I was a huge skeptic of all this, and I'm going to explain why.

And a lot of people within the company and some people outside of the company would hear about Wasm, however they hear about things, and come to me or come to our team and say, I have this great idea. I have had this breakthrough in reasoning. Shiny is written in R. R is written in C++. C++ can be compiled to Wasm. Therefore, Shiny can be compiled to Wasm QED. Let me know when it ships.

And this is a chain of reasoning that occurred independently to multiple people over multiple years, and each time we would have this discussion, and I would have to disappoint them, and my response eventually was like, well, actually, let me school you on what's happening here.

Compiling C and C++ to Wasm is just the tip of a gigantic iceberg. This is the biggest iceberg I could find on Unsplash, but if I could make the top smaller and the bottom bigger, I would. Because compiling C and C++ to Wasm is very exciting, but if you think about what R does and what Python does, there's all this stuff under the surface beyond just interpreting C and C++ instructions.

There are all these things that are either from the operating system or from libraries that we've built on over the years, and they are not available in Wasm. And it's not just a matter of rebuilding those pieces that are missing, because the environment that Wasm runs in is the browser, and the browser has a number of limitations that your desktop computer is not subject to. In the browser, you cannot launch a process, you can't open a network connection, you can't even perform I.O., like reading from a disk or fetching from the network, synchronously. You can't handle something as simple as Control-C.

And Wasm does not lift any of these restrictions in and of itself, instead, it really just makes it hurt more, because we have this software already written that's expecting to be able to do these things, and we really wanted to just make it run in the browser, and we cannot because these things make it so hard.

And it makes me think of this Haitian proverb, de yin wan, yin wan, and what that means is beyond mountains, more mountains. Whatever hill you have to climb, whatever obstacle you're facing, whatever challenge you overcome, when you get to the other side, it's just more of the same.

And it makes me think of this Haitian proverb, de yin wan, yin wan, and what that means is beyond mountains, more mountains.

The people who made it happen anyway

And lucky for me, lucky for you, lucky for all of us, not everybody thought like I did. Not everybody had the same reaction that I did to these challenges. Because I got to the point where I was getting pretty frustrated. I was like, stop suggesting we port things to Wasm, stop trying to make Wasm happen, it's not going to happen.

And there are some people that are wired very differently than me that did some pretty amazing things. Alon Zakai showed up one day on the internet and said, hi, I built a compiler tool chain and computing platform that runs on Wasm, that's called Emscripten. And this thing is, as far as I'm concerned, it's magic. This is replacing both the GCC tool chain and big parts of Linux and making them available in the browser. And if that doesn't mean anything to you, all the more reason you should be grateful that he's doing this work.

Michael Trotboom, who is a complete legend in the Python space, and just one more reason why he's a legend, just put out a blog post one day saying, oh, you know, I was curious if it was possible. So I patched NumPy, Matplotlib, and Pandas, the whole scientific Python stack now runs in the browser, that's called PyDyed.

And Winston Chang on my team, over a weekend, did a little bit of hacking, literally over a weekend. And apparently what happens when I'm gone is people do things I ask them not to. And Winston showed up one day and said, hey, I made Shiny run on PyDyed and that became shinylive .

And our own George Stagg and Lionel Henry came up with, well, George Stagg, even before he worked for Posit, I think because he was frustrated that a class that he was teaching, like he didn't want to stand up a server, went and instead did this miraculous thing and created WebR.

And it was interesting, in putting together this talk, I actually learned a little bit more about this saying that in Haiti, it has really not just a negative meaning, that it is a meaning that's about, yes, a grim situation, which Haiti, more than almost any other country, finds itself in perpetually, but there is also sort of a resilience to it. This acknowledgment that whatever problems we face, we will always face more problems and that doesn't stop us from getting up and doing what needs to be done.

And in that way, it's the same mountains that they're looking at, that people like George and Winston and all the other people who have contributed to this Wiles and Stagg saw the same mountains, but instead of concluding, well, the challenges will never end, so let's not begin the journey, instead they just decided, well, let's see how far we can go. And it turns out that even though there are more mountains in the distance from where we are today, we have come in an awful long way.

Introducing shinylive for R

So this time last year, we had the pleasure to introduce shinylive for Python, and that was super fun. This basically moves this model that I talked about in the beginning where you have a server that's running Python, and it flips it on its head so that the server is running essentially nothing. The server just serves up HTML and JavaScript, and Python runs inside of the browser for everybody who connects.

And I am very pleased to tell you that our estimate from last year, that it would be a couple of years before we had this for R, did not take into account George Stagg , and today, shinylive for R is available.

It feels incredible to stand up here and take credit for work I had no part in.

It feels incredible to stand up here and take credit for work I had no part in.

How to use shinylive

So how to use shinylive, and this is actually pretty interesting because everything from here on out applies equally to R and Python. There's very little difference between these two. So let's talk about how we use shinylive, and there are actually three different options that are available. You can convert, you can fiddle, and you can include, and I will go through each of those in turn.

The first option is to convert. So you take your app.R, any other code files you have, any data files you want, and you pass them into this simple shinylive export function, and that will take your app directory and turn it into a completely static set of assets. You can then take that and upload it to GitHub Pages, for example. This entire presentation is uploaded to, well, you'll see it in a second.

And this exact same workflow also applies to Python, except instead of installing the R shinylive package, you just pip install shinylive, and it's the same deal. So this is a great option if you want to take your Shiny application and turn it into a standalone website.

Now one just unfortunate wrinkle about this is that due to sort of browser security rules, you cannot simply double-click the HTML file that is sitting in this directory when you're testing on your own machine. The browser will not let certain advanced browser features be used unless it sees that the URL bar has an HTTP in it. Or if you are using Shiny for R, you would run this HTTPUV command. If you're running Shiny for Python , you would run that line three Python HTTP.server command. If you are uploading your static Shiny app to a web server, then none of this matters, none of this applies.

Option number two is Fiddle. So we have a website called ShinyLive.io. How many of you have taken a look at ShinyLive.io for Shiny for Python over the last year? Okay. Great. So quite a few. And this is a way that you can write and share Shiny apps directly in the browser. No need to install R or Python on your local machine. And it looks like this. You have an editor that you can write code in. And when you hit the play button, it generates the view on the right, and you can fully use that. That's a Shiny app. It's crazy to me that this works, but it somehow does work. That is running Python inside of your browser, and you get a full Shiny app.

Shiny for Python and Shiny for R have different links. I will repeat these links at the end. But just so you know, you cannot go to the you cannot currently go to the Python side and find a link to the R side or vice versa. You just have to know the right URL.

ShinyLive.io, you can view and run examples that we have created, and you can also create your own apps from scratch. You can also share apps that you create via URL to your, well, to anyone. And you can save apps to GitHub Gists if you want.

Maybe the most exciting one is option three. Option three, we have a shinylive Quarto extension. So you can take your Quarto documents and insert these shinylive-R flavored chunks and put a full-on Shiny app in there. And it is now just when you render it to HTML, you have a Shiny app that just works inside of your HTML.

So, this is an example. Actually, this came up yesterday. I had lunch next to Erin Howard of Oregon State University. She mentioned this Central Limit Theorem app that she had built that really helped in getting the idea of the Central Limit Theorem across. This is not her app. I'm sure hers was better, but I wrote this in the middle of the night last night. And you can see here that this is fully running. It's a Shiny app. This is a Quarto document. There's no server behind it.

When price drops change what's possible

Which brings me to another point that usually in technology, something gets cheaper, great. We can do that thing for less money. But sometimes when the price drops enough, you're not just doing the same thing that you were doing before for less money. You can do entirely new things. And let me give an example.

This is a mainframe computer. This is the 60s. That cost millions of dollars, and it was used for weather research or military research. In the 70s, we had mini computers. These were hundreds of thousands of dollars, and maybe medium to large-sized businesses would use these to run their accounting software. In the 80s, we had PCs that cost thousands of dollars, and you might write a term paper on this or do your taxes or play a game. Today we have these magical devices that cost hundreds of dollars, and we use them to check our YouTube channel subscriber count while we're having a latte. And recently, we even have these computing devices that cost tens of dollars, and they exist only for the purpose of helping you find your keys.

So as the price drops, the scenarios drastically change. What computers were good for and what computers are good for now are entirely different, and that never would have happened without that drastic decrease in price.

And that's what we found – well, that's what I found maybe most surprising once I got over the initial shock that this stuff works at all, was that this is not just about taking the kinds of apps that we already write with Shiny, the things that Shiny was already good at, and making them cheaper than before. We very quickly were finding new ways to use Shiny that would not have been possible before.

We very quickly were finding new ways to use Shiny that would not have been possible before.

And one is our Shiny for Python tutorial has these embedded Shiny app editors bundled throughout our website, throughout our tutorial. And this lets you, as someone who's learning Shiny for Python, interact with the code, try different things, and then hit the play button and immediately see what happens. And you can do all this without needing to install Python or Shiny on your machine. And this is not something that we had attempted before.

And we extended that concept also to our examples. Our Shiny for Python website uses a Quarto doc package, and that package works very nicely with shinylive for Python. So all of our examples, especially the ones that have anything to do with UI, we can have running examples that will actually instantiate a new Shiny app inside the browser and show you exactly what happens.

This doesn't work yet, but you could certainly imagine that package downsites for R in general could do this sort of thing. This is the GT package. It's an incredibly beautiful package for creating tables, and you could, yeah, I'd be excited about GT's documentation having Shiny apps that help you understand what the different options do.

And there is a group from the R Consortium that's working with the FDA that are trying to take WebR and shinylive and see if they can use that to help accelerate clinical study reporting by bundling Shiny apps with their clinical trial submissions.

What will you build?

And this is where I want to turn it over to you and ask, what possibilities can you find in your work to take advantage of these new possibilities for Shiny? Could your next presentation be more compelling with a little Shiny? Could your lecture notes lead to deeper understanding? Can your blog posts be more powerful? Or maybe you just want to bewilder your students with a random game of Hangman in the middle of their homework.

That comment is inspired by Chelsea Parlette-Pellariti, who wrote one of these. I'm not sure why, but you can click on the link and play Hangman in your browser.

So to recap, there are these three ways to use it, convert, fiddle, and include. Now with my last 30 seconds, there are limitations. I wasn't wrong that this is a challenging computing environment to try to do data science in. Probably the most obvious is that the slower start time and larger download size, because you are downloading your data, Python, any packages you need, or R if it's R, you're downloading all of those to your machine. It's really bad for R right now, but over the next couple of weeks, it'll be better. And some things are just not going to work. So the native Shiny execution model is not going away, but now we also have shinylive.

Running R-Shiny without a Server - posit::conf(2023)

Transcript#

WebAssembly and the challenge of running R in the browser

The people who made it happen anyway

Introducing shinylive for R

How to use shinylive

When price drops change what's possible

What will you build?

Featured software#

Shiny for Python

Shiny

shinylive