Now we have a LEMRS stack. How about adding email? Amazon’s Simple Email Service seems anything but simple when you confront its voluminous documentation, so here’s a tl;dr version for a relatively simple set-up with R. One of the big attractions here is that if you’re already running an Amazon instance, you can send thousands of emails every month at no additional cost. Otherwise, it’s 10 cents per thousand emails. You may find it worthwhile to sign up for Amazon Web Services just for the ability to send email.
My last post included an Amazon Lightsail launch script to set up an instance with a LEMRS (Linux / EngineX (nginx) / MySQL / R / Shiny-Server) stack. This time we’re going transfer files into the instance, including new configuration files for nginx and shiny-server, start both of them up, and see how they work.
In my last post I talked about the strategy I used to figure out what should go into a LEMRS launch script. A major theme of this post is that I now know more about Linux than I ever have before and ever will again, so I’m trying to document what I’ve done and otherwise take care of future me when I have to get back in and update all this stuff. [NOTE: There is now an updated version of this script.]
In my last post, I bumped into Amazon Lightsail and discovered the joys of virtual servers. In this post I’m going to talk about how a Linux noob like me figured out what to put in Lightsail’s Create Instance launch script to build a LEMRS stack. In my next post, I’ll show you the actual Lightsail script I’m using.
In the world of web servers, a stack describes the critical software used on the server. The most well-known stack is LAMP – Linux (operating system), Apache (web server), MySQL (database), and PHP (programming language). For example, WordPress and other content-management systems typically rely on a LAMP stack.
Today I’m releasing v0.1 of om_skeleton. It begins where uiStub left off, but now includes user authentication – that is, logging in and logging off.
In other words, om_skeleton is R code for Shiny-server-based web sites that allows multiple pages (the code for each of these pages is in a separate file) and multiple users. The users can:
As I mentioned in the final post of my read-me-first Shiny tutorial, the need for a ui variable makes Shiny look like it requires a separate app for every distinct web page. But if you reduce the ui to a stub that has only what you want to be the same on every page of your web site, you can move the rest of each page into the server function.
Even the simplest Shiny program has two parts, a ui variable and a server function. When you’re just getting started, it appears these parts are of equal importance. But eventually you realize that it’s all about the server function. The ui is such a nothing that in this tutorial we’ll nearly get rid of it.
Staying organized is a bitch. Using a separate RStudio project for each distinct task you’re working on is a core organizational principle that works on its own for statistical projects related to classwork or publications. Things get harder, however, when your RStudio project also has a GitHub repository and is a Shiny app hosted on a server like shinyapps.io.
Inexpensive shared servers, like the one Open-Meta.org is using, include MySQL database software that you might be able to access from other servers or computers. But when you try to look up how to do this, you are likely to get instructions that are out-of-date and that appear more complicated than the process actually is.