Consider the following simple Sinatra application:
require 'sinatra'
post '/user/login' do
# login logic...
end
When deploying the application to a production environment, the url /user/login is usually changed to something else, i.e., /nitro/nutcracker/v1/user/login. And of course, the Sinatra app will not serve this url.
To cut the unwanted prefix, I've considered using a filter (i.e., before block), and routes with regex (i.e., get /*/user/login), but surely there are better solutions?
What say you?
You can mount it with rack. On the production server, create a config.ru file, and put this inside:
require_relative 'my_app.rb'
map('/nitro/nutcracker/v1/') { run Sinatra::Application } # Or your class, if it's modular
This will prefix the entire app with /nitro/nutcracker/v1/.
Then you run the server with rackup, or your application server might have a command line argument to pass a rack config file.
Related
Below is how I configured Axios based on the example given on Nuxt.js' website:
.env:
BASE_URL=https://path.to.endpoint
nuxt.config.js:
publicRuntimeConfig: {
axios: {
baseURL: process.env.BASE_URL
}
},
On page load I make this call:
this.$axios.get(`/endpoint`)
Once I deploy my app as a static site it works both on my personal host and on GitHub pages. But on my employer's host, the path to endpoint specified in .env becomes https://localhost:3000 so the API call fails.
Why is the most likely cause of this behaviour?
Alright, from the comments, it looks like you configuration is totally fine from what you've provided and that the team on the other side does have an incorrect setup of the environment variables.
You need to ask where they do host your code and what are the actual values of their env variables. Actually, you will probably need to give it to them since they (usually) cannot guess it by themselves.
Human communication is the next step. ^^
We let the golem package automatically create a Dockerfile for us and can run the docker image and see the app at the root directory: http://localhost:3838/?...
But we would like the app to appear in a subdirectory like http://localhost:3838/myApp/v1/?... so that we can set up the necessary proxying for Apache and have this and other apps all available from a single server.
We can manually edit the Dockerfile to copy a shiny-server.conf file with the following information:
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location /myApp/v1/ {
# Host the directory of Shiny Apps stored in this directory
site_dir /srv/shiny-server;
# Log all Shiny output to files in this directory
log_dir /var/log/shiny-server;
}
}
The above solution feels like a hack and we are hoping there is functionality inside of golem that will allow us to set the subdirectory at which the app will appear.
Unfortunately there is no way to include an nginx configuration inside the Dockerfile programmatically: {golem} tries to help with the creation of the file, but some things still need to be done manually.
Also, note that {golem} doesn't create a Dockerfile with a shiny server in it, it creates a standalone docker image that launches the app, so there is no shiny server running, just an R process. {shiny} being what it is, there is no way to natively run it on a given path, it's always at the root, on a port.
That being said, what you can do is either edit the dockerfile so that it also bundle nginx (or any other load balancer), so that you can serve the app on a path, or serve your application on another port, using the port argument of add_dockerfile(): that might be easier to configure it with you Apache proxy.
Colin
I am porting an ember application to ember-cli, and wanted to use the mock server facility.
What url are the mocks served at (by default, at least)?
I thought I'd look at the generated objects, but their location doesn't seem obvious. localhost:4200 seems to be serving only the client itself. Could it be under a prefix? Also where is the code that sets this up? -- "in the wild" I use oauth tokens, and may want to put auth and cors handling into the mocks to test this.
Ok ... the answer is: even if you are using ember-cli-coffeescript, you can't write server/ (or config/) code in coffee. Inside of generated server/server.js we have
var mocks = globSync('./mocks/**/*.js', { cwd: __dirname }).map(require);
var proxies = globSync('./proxies/**/*.js', { cwd: __dirname }).map(require);
I had converted my mocks to .litcoffee, which works in app/ and tests/, but not here.
I guess if I want to use coffeescript here, I need to compile in the Brocfile (or add to the addon...).
I'm learning Sinatra and trying to wrap my brain around Sinatra::Base. The documentation doesn't readily answer the question:
What is Sinatra::Base responsible for?
Is there an easy way to think about it? (i.e. maybe there's a good diagram or something?)
Or is the answer just a long list of functionality? (For example: "Sinatra::Base is responsible for errors, filters, routes, templates, etc, etc.")
Or is it something simple like: "Sinatra::Base is Sinatra, minus the execution context, Sinatra::Application"?
Sinatra::Base is the Sinatra without delegation. Consider the following code with delegation:
# app.rb
require 'sinatra'
get '/' do
render :template
end
This style gives you option parser for free:
$ ruby app.rb -h
Usage: app [options]
-p port set the port (default is 4567)
-o addr set the host (default is localhost)
-e env set the environment (default is development)
-s server specify rack server/handler (default is thin)
-x turn on the mutex lock (default is off)
It also starts the server using appropriate Rack handler when you run the script with your application, so you don't have to write any related code.
It works only because Object is extended with Sinatra::Delegator in sinatra/main. See http://git.io/zWl7RA and http://git.io/NxgpBg. It delegates all Sinatra DSL methods to pre-configured instance of Sinatra::Base, namely Sinatra::Application.
When you write an application in modular style, nothing is delegated. You just inherit the base:
require 'sinatra/base'
class Application < Sinatra::Base
get '/'
render :template
end
end
Application.run!
So, Sinatra::Base is currently responsible for implementing all Sinatra DSL methods on top of Rack, Tilt and other dependencies.
My sinatra application is contained in a gem. This means that the assets (css/js) live in the gem. This application writes on the fly generated images and serves them; currently writing into and serving from the public dir.
I prefer to not write the generated images in the gem dir but to a "cache" dir of some sorts under the web-application implementing this gem.
Gem is installed at /var/www/TE/shared/gems/ruby/1.8/gems/tubemp-0.6.0, so assets are at e.g. /var/www/TE/shared/gems/ruby/1.8/gems/tubemp-0.6.0/lib/public/css/.
Gem is deployed in a simple rack-app at /var/www/TE/current/, so I would prefer to write and serve the thumbnails from /var/www/TE/current/public.
However, the setting for a custom public-dir allows only one dir to be set:
set :public_folder, File.join(Dir.pwd, "public")
Breaks the serving of assets; Dir.pwd being the directory of the Rack app. Public is now the dir under the Rack-app, but that is not where the assets are found: they live under the "public" in the gem.
set :public_folder, File.join(gemdir, "public")
Breaks serving of the generated thumbnails.
I could rewrite the application so it serves either the assets or the thumbnails trough Sinatra, but that seems quite some overhead.
Is that the only way? Or is there a way to give Sinatra two or more public dirs to serve its static items from?
I think there's probably a few options, but here's how I got a little app to serve static files from two places, an extension and the main app's public folder:
Directory layout
root/
app.rb
public/images/foo.jpg
lib/sinatra/
gemapp.rb
gemapp/public/images/bar.jpg
The extension
# lib/sinatra/gemapp.rb
module Sinatra
module GemApp
def self.registered(app)
app.set :gem_images, File.expand_path( "gemapp/public/images", File.dirname(__FILE__))
app.get "/images/:file" do |file|
send_file File.join( settings.gem_images, file)
end
app.get "/gemapp" do
"running"
end
end
end
register GemApp
end
The main app
require 'sinatra'
require_relative "./lib/sinatra/gemapp.rb"
get "/" do
"home"
end
It served files fine for me.