Kamil Żyła, Kuba Nowicki: Introducing Rhinoverse

Kamil Żyła, Kuba Nowicki: Introducing Rhinoverse

Show Video

Hello and welcome. Last year, Appsilon unveiled Rhino in an opinionated framework for enterprise Shiny applications with a focus on software engineering practices and development tools. Today, we'll get a deeper dove into the rhinoverse with fellow Appsilonians package authors Kamil Żyła and Kuba Nowicki. Kamil is a full stack engineer at Appsilon and core developer of Rhino. Kuba is our staff, engineer and open source lead. They have contributed and developed numerous training apps in R packages, including many within the rhinoverse, and are both paving the way for apps on open source, lab discovery and contributions to the Shiny ecosystem.

Fasten your seatbelts and enter the rhinoverse as Kuba and Kamil show you how to use Rhino to create Shiny apps. The Appsilon way like a full stack software engineer. Kuba, Kamil welcome to the stage. Thank you, Micah for the introduction. So today, as the title suggests, we'll be talking about rhinoverse.

However, what is rhino in the first place? Let's start with a bit of history. So that was started with Shiny. We discovered this technology and we found that it's great for creating value with great speed. It's allow us to focus results of the client really fast, create something interactive and impressive, sometimes within hours. However soon when we started was slow. Start using Shiny for our projects.

But soon we discovered that many of them kept growing. Their complexity would increase more and more. We kept adding features and with time, good engineering practices would become essential or the project would stall.

So we had to take time to think about project structure, configure things like beam tests, unit tests and so on. And this kept happening to us time and time again. Basically, in each project that kept going, we needed to configure all those tools. So we started thinking to ourselves, we shouldn't repeat this work time and time again. We should direct this effort towards building something reusable. So the high level goal was clear for us.

We wanted to have a reusable tool to set up R project and all the development tools. However, it was not obvious how to achieve that goal. Throughout the years, we tested various approaches. At the very beginning we had a complete development environment.

Docker and the bash tool to manage it. This till later evolved into a Python tool and the concept changed. We started having code snippets on branches and the tool would be used to combine them into project structure for your Shiny application.

Then we found that it's complex and kind of difficult to use. We went through a phase of simplification where we had just a simple git repository, a template that you could clone and use the foundation for your Shiny application and after all this experimentation, we started feeling that we have something that we are satisfied with and that we want to share it with the world. And that's right. Rhino was born. So what is Rhino? Well, it's an R package.

Contrary to its predecessors, we thought it is the most natural way to share our work. And it's important to know that it's open sourced and free. So Rhino allows you to set up a complete project structure for your Shiny application with just simple commands. And this includes all the configuration places to keep your sources and all the development tools that you'll need, like unique tests end to end tests, leading tasks and so on.

So Rhino was announced almost a year ago. We introduced its ads ops, then Shiny conference at the end of April last year. Since then we started using it in all our commercial projects. We also migrated in capital one to the Rhino, and this taught us a lot.

We had discovered packs. We discovered places where it wasn't quite meeting our needs. And this led us to various improvements.

And we also received a ton of feedback from the community. And with great pleasure, we can say that to a large extent. It was a very positive.

Of course, we also received bug reports and feature requests and it's been very grateful for all of them because it allows us to improve the package even further. So I want to give a quick recap what's happened with Rhino over the past year. So we focused on key three areas. First of all, usability and fixes.

We really wanted to make sure that using Rhino is free of frustrations. And to give one concrete example. We made sure that Node.js, which is used to power state of the R tools for JavaScript and SaaS development, is easy to use, in particular on Windows, for it causes the most issues.

Then we added incremental improvements to various parts of the package. For example, we expanded the API by adding useful additional arguments to our functions or improved our automation and continuous integration by including more text. Lastly, we really wanted to make sure that all the metrics that you would expect from vanillaShiny work with Rhino as well. And sometimes this meant fixing compatibility issues and adding support for giving features to Rhino itself. Good examples are Shinytest2 and Shiny bookmarking, which had issues but now should work fine. Sometimes adjustment.

Expanding our documentation as the majority of packages actually are compatible with Rhino without any changes. Sometimes you just need to know how right in the works because it's slightly different from vanillaShiny. So this is Rhino from its very beginnings up to this point. To summarize, we can think of Rhino as a complete development toolbox for your Shiny applications.

So what comes after Rhino? What's the next step? It's rhinoberse, a complete workshop for building web applications in Shiny. So Rhino is an R package file, right? Rhinoverse is a family of R packages. We're going to try not to be a foundation for building your Shiny application. And with the packages and rhinoverse, we want to address the wider web development needs that you might have as the project continues. So it's not something completely new that we're announcing right now, but rather we want to share with you a vision that we have to move forward with our open source, because the power of R, to a large extent comes from its packages.

And you need to do something. Typically, you will find the package that will do the job. Of course, that's not always the case. And we found ourselves, ourselves in such situation on multiple occasions and that we created packages of our own.

However, so far they were created in kind of isolation. And what we'd like to do now is to really ensure that they work together very well, that they form a family that you can use to address all your web development needs that you will have. So what kind of needs do we have in mind? So probably the most obvious part is the visual design of the application. Everything that you will see when you launch your application. So the UI components, that you are using, the theming, and certainly while it allows you to build an interface, an interactive one really fast, it's somewhat limited when it comes to that choice of its appearance.

Of course, it can be expanded using the various packages, but still you're kind of limited. And we really want to make sure that you have a wide array of choices when it comes to how your application looks like. And we also want to make sure that the most popular toolkits out there are available for society as well. Then there is the whole set of features and needs that are relevant to the user, but not strictly visual in nature. Let's call this usability and browser features. I mean, things like being able to copy URL of a specific view of your application or being able to translate it to different languages and switch the language easily in the application.

Lastly, your web development. There are a lot of needs that are not strictly related to users, that's all, but which are important for developers. Developers.

So being able to test the performance of R application and comparing between different versions, being able to validate your data and everything related to app internals, the architecture and so on. So with rhinoverse, we want to have you covered in all these different areas and the packages we already have addressed this needs. But we have more plans for the future. And now I would like to pass the mic to Kuba Nowicki, who is our open source lead, who will tell you about the packages in front of us and what we have in mind for the future. Thank you, Kamil.

Let me now take you on a tour and show you what currently we have in front of us. And I will start with the first you mentioned, which is the visual design. So insanely general, you can get your UI very, very fast, but it's not going to be the most beautiful one. Of course it supports you with creating a custom styling by providing you a set up for size, by attaching your stylesheet, your application in an automated way. But this customization takes time, and often this is a case that you want to just focus on building new features, not on the UI, and still want to achieve this great looking application. So the solution is to use library with predefined components that will give you this consistent great look.

And in rhinoverse we have three such packages are for shiny.semantic, shiny.fluent and shiny.blueprint. And let me now say a few words about each of them. And I will start with shiny.semantic, which is our most known bucket

as as far as it comes to to counting the GitHub stars. It gives you components coming from semantic UI. It's probably the easiest place to start since it's API is quite similar to the base Shiny.

And moreover, if you want to achieve this layout coming from Shiny Dashboard, but with a twist of having semantic components, you can do that using Semantic Dashboard, which will give you this set up which now bar, sidebar and body with taps. Okay. Next bucket is shiny.fluent. It implements beautiful components coming from Microsoft fluent UI. So if, for example, the organization uses Microsoft tools, it might be an easy way to build an application that is consistent in style. Okay.

And the first bucket you already heard about it yesterday, our youngest child. It's called shiny.blueprint and it implements live images from volunteer. And again, it includes a number of great looking components. It gives you a beautiful professional look. It's yesterday landed on CRAN. So we are eager to to to hear your feedback on that.

Well, those packages work without any problem with right now. But soon we plan to make it even easier by giving you a set of templates, a pre-built round applications that will use UI coming from semantic, fluent, blueprint. And with that, you will be able to start your projects even faster just by feeling the existing structure with your content. And there is one more package I want to talk about in this part, because both shiny.fluent and shiny.blueprint use are based on react libraries. And to be able to port them to to Shiny.

We created another package showing you react and you also can use it to port any react library that you want and use it in Shiny. But this comes of course, with an overhead of building a whole R package. And because of that that's another feature that is coming to right now in the future is the ability to add or to define a single react component inside the ring up. So soon you will be able to write small parts of your right application in React.

Now let us move to the next area usability and browser feature and here I want to talk about two packages that will help you building a complete web application using signing. And the first one gives you the ability to add an illusion of multiple pages to your Shiny application, which is by default, a single page app, and then you can assign specific views to specific URLs. This gives you the ability to use browser navigation, go back and forward to base to link with a specific view. It also gives you features like your URL parameters are for a full page so you can display a custom message if user enters, not a valid link. Okay. Another topic is internationalization.

And in general, this can be achieved thanks to shiny.i18n And this gives you the ability to reach a broader audience with your application simply by wrapping text in your application in a translator. That will change the text according to the language that has been chosen by the user. Moreover, if you wants to use Shiny internationalization in other setups, it's also doable.

You can use it in R markdown documents. You can use it for translating quotes of documents. Okay, the last area here, development and testing. And here again, I want to talk about two packages. The first one fulfills the need to display a little bit more to the not user, but a user to the tester, because you want to get as much information as you can about any problems that they have.

And this can be achieved. Using shiny.info it can display small messages around the application like application version, like comet, like the value of some objects inside our session. But we also plan to integrate it tomorrow for us. So

so you should be able to see some messages coming from, from your application. And this should make the process of creating and debugging application much easier and much smoother. Finally, the last topic is about testing and in rhinocamps. We've set up four unique tests thanks to test that set up for front end tests thanks to either cyprus or shinytest2. And now in rhinoverse, you can also get a package that will give you a tool for performance tests and this is shiny.benchmark.

So with that you can compare different versions of applications and like maybe they are faster and you have something to that that can show to your boss, Hey, this application is now twice as fast as this, boss. Or maybe there's a problem and you want to spot it early and act on that. By the way, if you want to know more details tomorrow, there is a great talk from Douglas Mesquita, the creator of shiny.benchmark. He will show you a lot of about this package.

I know that there will be also a demo. So you see this in action. Okay. That was a very short introduction to most of our packages available in rhinoverse, not all of them.

So I encourage you to check out them. I hope they will help you build great on your applications. And the best place to start digging into rhinoverse is our website, right? In the https://rhinoverse.dev you can find the links to the communication, links to the applications, to their repository. And also if you find something that is missing, maybe something needs to be fixed. Don't hesitate to give us an... to send us an issue and get help.

That will be very helpful. And if you want to help more, if you wants to contribute, you're more than welcome. We'll be super happy if you send us a post request with some improvement.

Okay. Thank you. That's thank you for listening to us. Now I believe we have some time for questions. You can also reach us on R conference Slack. We have a dedicated Slack channel open-source-appsilon and you can also find me on Twitter and Fosstodon.

Thank you. Great. Thank you so much, Kamil, and thank you Kuba for the presentation. We do have a few questions here. And of course, as Kuba mentions, as a reminder, feel free to chat on the Shiny conf of Slack if you have any questions related to the packages individual or the rhino package itself. So the first question from from Olga, does shiny.router work well with modules? I guess it's good to talk about. Yes.

So yeah, it was working with modules from the beginning. Now it's even simpler because as you probably know, Rhino is based on modules and now to use it, we have this set up. This is seamless.

There is also a tutorial on how to work with rhino applications and we've sent your editor and this this applies also to to any site application with modules. Great. We have another question here. How does Rhino make it easier for me to share applications with public and such that it's easy for anyone to get started on developing the application? So I would say that the power comes with the fact that you just want command to set up full project structure for your Shiny application and you don't need to use everything that you will gather from the beginning like you probably want right tests when you are just doing a simple demo, but it might be useful for the future and you get everything from the start. So there is never a situation that: Oh, I won't be adding tests because it takes too much time to set them up.

You already have that ready. So that's how much it helps with sharing your application. I mean, I guess in general helps you have a quality application and it will easier it will be easier for you to get traction and it will be more exciting for people to see. So I say that's how right now cannot resist that in general. Great.

The next question it’s similar along the lines which package has a gentle learning curve that I can quickly implement in my existing Shiny apps? Huh. Tough question. We tried to make all of them as easy to start as it's possible, and so we try to to make the documentation better and better. So just go for that for the for R packages. Check what are your needs and I'm sure that you will find a tutorial that will help you to start if you want routing there is shiny.router or if you want to

change some change in the language there is shiny.internationalization. So yeah, great. What do you need. That and this next question I guess could be for for for both of you, what is your favorite superpower that is offered by the rhinoverse? Thinking, I can see. So maybe I will start. I think for me it would be not sure if it's a superpower, but if you consider it's used in many applications and organizations like Appsilon, then I would say it's a superpower to have a fixed structure for your applications.

When you see another application for the first time, you are not wondering where the files are placed. You are not wondering how things work because you know that it works how it does in the right now. So I would say that this is something really powerful as actually when when it's when it is scaled, when you have many applications in an organization developed this way. Yeah, I agree with that.

And I would add on top of that that I really loved the explicitly of everything that is going on in Rhino, starting from with explicit impulse with that set up for our end where you need to define exactly which packages are used, you can install whatever you want, and as long as you don't added to it to dependencies that are, you can have your mess. It will not affect your applications, will not affect our end block. At some point we we used to react our and we departed from it as we saw. Like once we understood how things work, we wanted to do things our own way and so we didn't need it anymore. So this feature of being able to use React components directly in Rhino will be based on Shiny object. And the idea is that what's happening React currently does for you.

It allows you to create a package that will be able to wrap some React library. So for example, there is blueprint.js, react library that provides you with many components and you can create an hour package with and we call this shiny.blueprint which is a wrapper for that library and with to react it makes it possible to use that react library inside. And so far this was like the only workflow that was support as well. So if you wanted to create just for your application a single react component and use it for some feature that would be difficult to implement, otherwise you would still kind of have to create a separate package for that components.

And of course you can do that. But what we'd like to to make possible and easy is that you can directly in right now as you already have places for data sources, you should be able to define the React components and just seamlessly start using it environment without trapping everything in. And you are package so that's the idea. Great. And additionally, what, if anything surprised you from from this past year? Any specific bugs, operating system issues or package compatibility? Okay. I have my favorite one. And this is related to what you said about what I said about Node.js support. So I

rhiowas mostly developed from the beginning on Linux and to support some of the features there, we used so called symbolic links. So basically you can create a pointer to another place on your filesystem. And this was very clean and worked great on, on our system like on Linux. But when we tested this on Windows, we, we found that there are many issues and basically to summarize it, symbolic links are a new thing for Windows. So it was released just recently and you need to enable developer mode on Windows for it to actually work. And it still didn't work quite, quite as well.

We had issues like, you know, for example as builds allows you to watch files for changes and automatically red builds the CSS when it detects changes. And it just didn't work with symbolic links on windows. It kept rebuilding it all the time and all the time. And like once we got rid of symbolic links, just like real identity in a different way, we were able to close like several boxes for all related to this. So great that I was going to say exactly the same.

It was kind of a funny when we started to to a little bit freak out because we both work on Linux and we had no idea how to quickly get the Windows machine done at up in setting up while in AWC. So now we're good. Great. So I have a hard hitting question here is there's some love for the the Shiny package icons. And so is there any sort of process for deciding what animals are used for the package icons.

Are usually we ask the creator, what is their favorite animal? Are we we we think about what can be the best representative for for a feature. For example, shiny.benchmark is measuring the speed of your application. That's why the falcon on it because it is fast. I like it. And rhino I think with right now we are just looking for a name that would work well. I mean, it would be catchy and would have good visuals.

I would say that for Blueprint, for example, we have a bluebirds on on the logo. So it really depends if we have a good idea, it's it's used sometimes it's just a matter of brainstorming and finding something that's yeah. Mm hmm. And to finish off, we have a question from for Marlene here. What's next for the rhinoverse? If you can share anything that's not secret, I guess.

Like we shift right now to the full compatibility, because as Kamil said, we said most of R packages were built in kind of as isolation. And the next step is to think about the features that will be become a great synergies between Rhino and our other packages. So I don't want to give any spoilers, but the general idea is to show you that using two packages in rhinoverse will give you more than just a sum of those two. Great. Well, Kamil, Kuba,

Thank you so much for for joining us today and for sharing about the rhinoverse and for creating the rhinoverse. We really appreciate it. And I know we at Appsilon use it a lot.

So thank you. Thank you. Thank you.

2023-05-25 16:21

Show Video

Other news