Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a couple Shiny apps that I have been developing for several months. I am now ready to roll out my apps to the target audience, but would like to avoid the hassle of installing R on every computer, making sure it's the right version of R for all the dependencies etc.
I was told there may be a way to run a Shiny application in a Virtual environment, that I could give to the user, but I do not know much about these. Ideally, the user would simply double-click an icon and the Shiny app would open in their web browser.
I can't host the Shiny app on a server because it contains credentials to secure data, otherwise I would go that route.
Is there a way to make a Shiny application run in some kind of prepared environment that already has R and Shiny installed, as well as all the app's dependencies?
would like to avoid the hassle of installing R on every computer
Every computer, meaning what? Even if you handed out a VM or a Docker image, the end user still requires software installation.
The alternative is to host your application in the cloud and point people at a single URL, I think Heroku might provide R hosting.
Ideally, the user would simply double-click an icon and the Shiny app would open in their web browser.
Again, if you're going around to "every computer" and installing software, this requires some type of bundling into an application (which depends on external software), or if you can host on a server it's simply configuring a URL shortcut icon to open the default web browser. Are you considering all possible operating systems for that clickable icon, though?
Is there a way to make a Shiny application run in some kind of prepared environment that already has R and Shiny installed, as well as all the app's dependencies?
You've basically asked for a Virtual machine or Docker image.
If you want to use the VirtualBox route, I can suggest using Vagrant to create distributable VM images
I can't host the Shiny app on a server because it contains credentials to secure data,
As long as you don't allow root permissions or post that data somewhere publicly accessible, you can very well host it on a server. Or you can host it at home and figure out how to port forward your router to the server / application
Related
I am building a series of interactive shiny web apps for a project that I am considering turning into a Company. My background is in data science and I don't have a lot of experience on the web app / server side of things, but these are important aspects for me to consider with my project. I currently have an Amazon Linux AMI EC2 instance with ShinyServer (free, open-source) installed, and I am currently hosting early versions of my web apps there. So far everything works fine, but I haven't made the links public yet.
My first question is whether anyone knows if there are certain limitations (scalability limitations, integration with database limitations, security / authentication limitations, etc.) that I will inevitably run into using RShiny apps and ShinyServer? I haven't heard of many successful, super-popular web apps being shiny apps hosted on ShinyServer, but rather my feeling is that ShinyServer is mainly used for hosting RShiny apps that are shared amongst only a small number of people (i.e. shared amongst team members at a company.). Per this thread - Does R-Server or Shiny Server create a new R process/instance for each user? - I am particularly concerned that my app won't be able to handle thousands of users simultaneously since only 1 R process is created for the app regardless of the # of concurrent users of the app. Having 10-20 processes through ShinyServer pro probably doesn't solve the issue either if I ever intend to scale greater than the hundreds or thousands of users. I also noticed that ShinyServer Pro would run me a not-so-negligible $10K per year.
My second question is whether RShiny apps can be deployed using other server technologies, such as Heroku. I came across this github page (https://github.com/virtualstaticvoid/heroku-buildpack-r/tree/heroku-16) but haven't dug too deep into it yet. I've been told that heroku makes it easy to update releases to apps whose code is on github (git push heroku:master), amongst other things.
My third question involves certain specific considerations of mine. In particular, I am currently working on a script that queries data from an API and writes that data to a (not-yet-setup) database of mine. This is the data my apps use, and I'd be interested in having the apps update in real time as the database updates, without requiring the user to refresh the webpage. A buddy of mine suggested AJAX for this type of asynchronous behavior, and it looks like this may be possible in R with something like this (https://github.com/daattali/advanced-shiny/tree/master/api-ajax).
Sorry that this is such a loaded question, but I hope it doesn't get closed down as I think it is fairly educational. Any suggestions / sources / pointing me in the right direction would be greatly appreciated on this.
Canovice,
I'd recommend you take a look at the following RStudio / AWS support articles. To scale a shiny server you'll need to look at using a load balancer:
RStudio
https://shiny.rstudio.com/articles/scaling-and-tuning.html
https://support.rstudio.com/hc/en-us/articles/220546267-Scaling-and-Performance-Tuning-Applications-in-Shiny-Server-Pro
https://support.rstudio.com/hc/en-us/articles/217801438-Can-I-load-balance-across-multiple-nodes-running-Shiny-Server-Pro-
AWS
https://aws.amazon.com/blogs/big-data/running-r-on-aws/
Blog Article:
http://mgritts.github.io/2016/07/08/shiny-aws/
Shiny is a great platform, their support is fabulous. I'd recommend you ring them up - they'll be sure to help answer your questions.
That said if your plan is to create a scalable website that will support thousands or hundreds of thousands of people then my sense would be to recommend you also review and consider using D3.js in conjunction with react.js or Angular.js, not forgetting to mention node.js.
My sense is that you are looking at a backend database connected to a logic engine and visualisation front end. If you are looking for a good overview of usage take a look at the following web page and git repo [A little dated but useful]:
https://anmolkoul.wordpress.com/2015/06/05/interactive-data-visualization-using-d3-js-dc-js-nodejs-and-mongodb/
https://github.com/anmolkoul/node-dc-mongo
I hope the above points you in the right direction.
I'd like to provide some notes related to your second question: Yes, you can use the mentioned buildback to deploy shiny applications on heroku.
I was in a similar situation with you (asking myself about possible ways of serving Shiny applications in a scalable manner) and decided to go the "heroku way".
You may find these hints helpful when deploying your app to heroku using the buildpack mentioned above:
Heroku tries to "guess" how to execute your application. But you can also add a special file, named Procfile, to your application to control the process commands you want to execute for your application. In my case I used web: R -f ~/run.R --gui-none --no-save, where this means that a file named run.R is being passed to the R executable for the web server process
The stack on heroku is based on Ubuntu. If you need additional deb-packages, you can create another special file named Aptfile and add the package names therein, heroku will then automatically install these for you (I needed it for RPostgreSQL)
You can add another special file named init.R and install all R packages as necessary just as you are used to, i.e. with install.packages etc. You can also add initial configuration material within this file.
As a running example, here is an example toy application that I wrote for myself to remember how a "full-stack" shiny app may look like, including compability with heroku.
For a large number of concurrent users, use a load balancer like nginx and enable the autoscaling of your app, e.g. through Kubernetes.
You can deploy your app on Heroku. On the paid tiers it includes NoOps autoscaling of your app. See this tutorial on how to deploy a Shiny app in a Docker container on Heroku: https://medium.com/analytics-vidhya/deploying-an-r-shiny-app-on-heroku-free-tier-b31003858b68
You can query the table last update timestamp in the Shiny server logic with reactivePoll() and rerun your db query if it changed. It is not "real-time" but depending on your application close enough if you set the time interval small.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
It is unclear to me how cloudControl MySQLd addon works.
My understanding of MySQLd is that it is a MySQL server that can/will work with unlimited apps.
But since all addons are only app based, this could also mean that I cannot use the same MySQLd server on multiple apps.
Could anyone please help me understand if one MySQLd instance can be used with multiple apps hosted on cloudControl?
There are two concepts on the cloudControl PaaS. Applications and deployments. An application is basically just grouping developers and deployments together. Each deployment is a distinct running version of the app from a branch matching the deployment name. More details on this can be found in the Apps, Users and Deployments documentation.
All add-ons are always per deployment. We do this because this way we can provide all credentials as part of the runtime environment. This means you don't have to have credentials in version controlled files. Thich is a huge benefit when merging between branches, because you don't risk accidentally talking to e.g. the live database from a dev deployment. Also add-on credentials can change at any time at the add-on providers discretion.
For this reason separation between deployments makes a lot of sense. Usually your dev deployments also don't need the same database power as the production deployment for example. So you can easily use a smaller plan or even a shared database (e.g. MySQLs) for development. You can read more about how to use this feature inside your code in the Add-on documentation.
Also as explained earlier, add-on credentials are always provided as part of the runtime environment. Now credetials can change at any time at the add-on providers discretion. These changes are automatically provided in the environment and the app processes restarted. If you had hard coded the credentials as would be required for the second app, this would mean the app would probably experience downtime.
Last but not least, it's usually very bad practice to connect to the same database from two different code bases in different repositories, which would be the reason to have a second app. This causes all kinds of potential conflicts and dependencies that make code changes and database migrations extremely hard to maintain over time. The recommended way would be to have the data owned by one code base only and provide an API to access that data from the second code base.
All this being said, it is technically possible to connect multiple deployments or even apps to the same add-on (database or anything else) but highly advised against.
If you have a good reason to connect two apps/deployments to the same database I would suggest you manually launch an RDS instance at Amazon (MySQLd is based on RDS) and provide credentials for that through the custom config add-on to both of your apps/deployments.
I hope this answers your question and also explains the reasons.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm making an app with a friend. I have a server which supports PHP and MySQL which my app is based on.
So we need to collaborate when making the app.
We are using Dreamweaver and NetBeans and apps on our phones...
The question is:
Is it secure to put the app we are developing on the web while its under development, and what should we use to protect it from the outside world?
Will Password Protected FTP be a good solution? or HTTP with a password protected folder?
I have seen there is a problem in HTTP protected folders. The login accepts a some other passwords too. Like if the password is helloworld123 and you login with helloworld it would accept and login?
SO I think HTTP will not be a good solution. And if it is then how should i make it more secure?
So what should I use? FTP or HTTP? thanks...
If you are developing an application, you should really be developing it locally.
You will rapidly tire of testing a change by uploading it to a remote server.
Additionally, what happens if your friend makes a change, how do you know that he has made that change? You will very quickly get collisions in code which totally ruin your collaboration.
So first of all, you should both install a LAMP/MAMP/WAMP stack locally. You should be testing everything locally, and you don't need to publish it to a server to test.
Then, you should be using some kind of version control in order to add any changes you make to a remote repository. This means that then you and your friend can work in isolation from each other, and then commit your own changes to a repository, and then you can merge the branches as you go.
When your application is then finished, you can then start to think about putting it into a production ready state by adding it to a server.
Sign up for an account at GitHub.com read as much as you can about how version control works, because if you intend to work together on anything you need to wrap your head around it.
If possible I'd always reccomend using localhost and syncing with Dropbox or any similar app. Otherwise you can try .htaccess to prevent anyone other than you and your friend from accessing your page.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I'm trying to write some javascript functions to integrate with the Facebook stream. However they only seem to work if you are developing them directly on the live server so that Facebook can access the xd_receiver.htm file that they ask me to place at www.mydomain.com/xd_receiver.htm. However you all can probably agree that it's really important not to develop on the live servers.
Here's what I've tried so far:
Placing xd_receiver.htm on the live server and running my scripts on my dev server hoping that the API Key would tell the Facebook server to look for xd_receiver.htm on my live server...no luck
Signing up for two API Keys with Facebook: a dev key pointing to 127.0.0.1 and a live one pointing to my live site. The theory here was that if xd_receiver.htm was only needed locally then it would find it via 127.0.0.1...no luck
Has anyone figured out a way to do this? They can't expect us to develop our Facebook Apps purely live without a dev sandbox.
Some background info for what it's worth: Using ASP.NET with VB but hoping to use purely Javascript.
It's definitely possible to use local xd_receiver.htm files. I'm a Facebook app developer by trade, and I have dozens of them set up.
You're closest to the correct answer with your #2 above. The way to do it is create two versions of your app. If I was making "MyApp", I might have two Canvas Page urls of "myapp" and "myapp-dev", and corresponding Canvas Callback URLs of "www.myapp.com" and "192.168.1.1". Each one is a separate Facebook app, with their own API key, etc.
apps.facebook.com/myapp would go to my live server, and apps.facebook.com/myapp-dev would go to my local development machine. You have to make sure Facebook can get to your development machine of course.
However, things should work just fine from there. You don't even need different versions of the xd_receiver.htm file, as the file contents are always the same for every app. AS long as your FB.XdComm.Server.init("/xd_receiver.htm"); line points to the right file, it should work.
I manage API keys and paths and such in a configuration file, and have one configuration file per application, whether it be a dev or production app. That makes it easy to output correct keys and paths on the app pages.
You can keep your development app in sandbox mode and do all the work on your local machine.
The simplest way is to configure local DNS in such a way that for your production callback url localhost address will be returned. In windows you can easily achieve it with following entry in \windows\system32\drivers\etc\hosts "127.0.0.1 your_production_xd_receiver_callback_url". Of course you need to run your server on port 80. In windows its simple task since there is no security concenrs :) in UNIX system you need to configure it since it is port belowed 1024.
This solution is tested and works for me.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am tasked with moving quite a few web apps including the databases to new servers, they are ASP.NET. I was not the one to create and setup these originally so I must try to figure out what exactly I need to replicate in order to not break anything and so the customers have no idea that anything was moved.
Does anyone have any tips for this, or know any automated ways?
Is there any software that can help with this?
I know the web app sends emails, so I will need to setup SMTP and it connects to a database so that I also will need to move. I suppose I should do this at night and take down the servers so I can move the database at it's latest state...
Any tips or tricks?
This might help: IIS 6.0 Migration Tool
"The Internet Information Services 6.0
Migration Tool is a command line tool
that automates several of the steps
needed to move a Web application from
IIS 4.0, IIS 5.0 or IIS 6.0 to a clean
installation of Internet Information
Services (IIS) 6.0 and Windows Server
2003.
The tool transfers configuration data,
Web site content, and application
settings to a new IIS 6.0 server if
desired, or can move just application
settings using the copy functionality.
"
I don't think it will help with the database migration, though.
Here's a link to more detailed information about using the tool.
May I suggest setting up the new servers in a staging environment. Allow business users to verify the functionality in the staging environment before flipping the switch and going live. Once you are ready, then bring over a fresh copy of the data. As far as the emails go... you should be fine with ASP.NET but some classic ASP programs require COM components in order to send email.
The route I've taken in the past is to do a live/current copy (whatever that entails) of $CURRENT_SERVER to $NEW_SERVER. If the DB is not moving, just make sure $NEW_SERVER can reach $DB_SERVER, and that it will continue to run once copied.
Then update DNS to point to $NEW_SERVER.
After some period of time (2-3x the TTL for the DNS record), remove the old server.
We just went through the same thing--bought a new server and had to transfer ASP.NET sites + Databases to the new server. We experienced problems with the IIS Migration tool, so we followed a "staging environment" approach, as stated in Berkshire's answer and had much success. When all issues are cleared from the staging environment, you can make it "live" with much confidence.
One other thing to watch out for is that you'll have to skim the ASP & VB/C# code for any hard-keyed connection strings to the database. These will have to change to reference the new location of the database.