I am trying to setup rack-offline in Sinatra, but I am having trouble setting it up. In rails it is prettty easy, but have no found any examples in Sinatra...
Basically, in your config.ru, map /application.manifest to Rack::Offline. (If you're not familiar with using config.ru with your Sinatra application, check out this part of Sinatra docs.) Here's an example, which caches all the files under directory public:
require 'your-app'
require 'rack/offline'
map "/application.manifest" do
offline = Rack::Offline.new :cache => true, :root => "public" do
# Cache all files under the directory public
Dir[File.join(settings.public, "**/*")].each do |file|
cache file.sub(File.join(settings.public, ""), "")
end
# All other files should be downloaded
network '/'
end
run offline
end
map "/" do
run Sinatra::Application
end
Remember to set manifest="/application.manifest" in your html tag and you should be good to go. You should take a look at rack-offline's README for more documentation and explanation of how it works.
Related
tl;dr How can I get a single Sinatra app to start up very differently on different servers via customizations to config.ru?
Background
I have a single web application written using Sinatra that's run on different servers. Currently the codebase for these servers is forked because there are some non-trivial differences in the way (discrete) parts of them work. For example:
one server authenticates users via an intranet LDAP server, while another server uses a simpler local database table lookup.
one server uses an external cron job to periodically update some statistics, while another (Windows-based) server uses an internal sleepy Thread.
one server stores certain metadata in a local table, while another server pulls the metadata from an external Wiki via screen scraping (!).
…and so on.
I'd like to get these code bases completely shared (single Git repo). I envision that each server would have one slightly-differing configuration file that causes the app to be started up differently.
Abandoned Solutions
I could change the behavior of the app based on environment variables. As there are a not-tiny number of variations in behavior, I'd rather not hide the settings in environment variables.
I could create my own "server-settings.rb" file that is unique to each machine, require it in my app.rb, and then change the configuration there. However, this seems to possibly be re-inventing the wheel. I already have a file named config.ru for each server. Shouldn't I be using this?
The Current Code
My config.ru for the app currently is simply:
require ::File.join( ::File.dirname(__FILE__), 'app' )
run MyApp.new
And the app.rb that it requires is, in essence:
require 'sinatra'
require_relative 'helpers/login' # customized for LDAP lookup on this server
class MyApp < Sinatra::Application
use Rack::Session::Cookie, key:'foo.bar', path:'/', secret:'ohnoes'
set :protection, except: [:path_traversal, :session_hijacking]
configure :production do
# run various code that depends on server settings, e.g.
Snapshotter.start # there is no cron on this machine, so we do it ourselves
end
configure :development do
# run various code that depends on server settings
end
end
The Question
I'd like to make config.ru live up to its name, and have it look something like this:
require ::File.join( ::File.dirname(__FILE__), 'app' )
run MyApp.new( auth: :ldap, snapshot:false, metadata: :remote_wiki, … )
How can I modify my application to change its configuration behavior based on settings supplied via config.ru? Or is this an abuse of config.ru, trying to use it for totally the wrong thing?
As soon as I started reading the question the first answer to pop into my head was "environment variable" but you scotched that straight away :)
I'll go with a mixture of one of your coulds and the desired outcome code, as it's how I structure things…
Because I want to be able to test my applications more easily, I take most of the Ruby out of the config.ru and into a separate config.rb file and leave config.ru to be a bootstrap file. So my standard skel is:
config.ru
# encoding: UTF-8
require 'rubygems'
require 'bundler'
Bundler.setup
root = File.expand_path File.dirname(__FILE__)
require File.join( root , "./app/config.rb" )
# everything was moved into a separate module/file to make it easier to set up tests
map "/" do
run APP_NAME.app
end
app/config.rb
# encoding: utf-8
require_relative File.expand_path(File.join File.dirname(__FILE__), "../lib/ext/warn.rb")
require_relative "./init.rb" # config
require_relative "./main.rb" # routes and helpers
require 'encrypted_cookie'
# standard cookie settings
COOKIE_SETTINGS = {
:key => 'usr',
:path => "/",
:expire_after => 86400, # In seconds, 1 day
:secret => ENV["LLAVE"],
:httponly => true
}
module APP_NAME # overall name of the app
require 'rack/ssl' # force SSL
require 'rack/csrf'
if ENV["RACK_ENV"] == "development"
require 'pry'
require 'pry-nav'
end
# from http://devcenter.heroku.com/articles/ruby#logging
$stdout.sync = true
ONE_MONTH = 60 * 60 * 24 * 30
def self.app
Rack::Builder.app do
cookie_settings = COOKIE_SETTINGS
# more security if in production
cookie_settings.merge!( :secure => true ) if ENV["RACK_ENV"] == "production"
# AES encryption of cookies
use Rack::Session::EncryptedCookie, cookie_settings
if ENV["RACK_ENV"] == "production"
use Rack::SSL, :hsts => {:expires => ONE_MONTH}
end
# to stop XSS
use Rack::Csrf, :raise => true unless ENV["RACK_ENV"] == "test"
run App # the main Sinatra app
end
end # self.app
end # APP_NAME
The initial reason I did this was making it easy to run the app in specs:
shared_context "All routes" do
include Rack::Test::Methods
let(:app){ APP_NAME.app }
end
but it makes sense to me to keep this code with the rest of the application code, so to speak, as I can bundle things together, run other apps etc. I've used this to conditionally load different examples into the specs in a few projects (it helps cut down on duplicated effort and check the examples really work), so I don't see why you couldn't use it to conditionally load configurations.
This way you get to choose to use a conditional in the config.ru as to which config.rb file you would use, or use an env var in the config.rb as to which definiton of self.app to use , or pass in an options hash to self.app…
With your set up I'd rename the APP_NAME module to MyApp, and the Sinatra class to App (because quite often I'll have an website that runs a front end and an API, so the Sinatra classes get named by their function (App, API etc) and wrapped in a module named after the site) and end up with:
config.ru
map "/" do
run MyApp.app( auth: :ldap, snapshot:false, metadata: :remote_wiki )
end
config.rb
def self.app( opts={} )
opts = DEFAULT_OPTIONS.merge opts
# …
run App
end
It'll be interesting to see how other people tackle this.
I just implemented Compass configuration for my Sinatra app but when I change the environment to :test or :production and modify my files like screen.sass or index.haml my changes are not reflected when I reload the page so I need to run my app again?
Is it normal? Is is just me?
This is how my app.rb file looks like:
require 'sinatra'
require 'haml'
require 'sass'
require 'compass'
require './helpers.rb'
configure do
set :environment, :test
Compass.configuration do |config|
settings.environment == :production ?
config.output_style = :compressed :
config.output_style = :nested
settings.environment == :development ?
config.line_comments = true :
config.line_comments = false
end
set :sass, Compass.sass_engine_options
end
before do
#js = 'javascript:;'
end
get '/scripts/jquery.js' do
# Downloads the latest jQuery 1.x version when needed. Requires to reload the page after done.
`curl "https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" >> public/scripts/jquery.js`
end
get '/styles/:name.css' do
sass :"styles/#{params[:name]}"
end
get '/?' do
haml :index
end
get '/:page/?' do
haml params[:page].to_sym
end
Any idea?
Generally, if you make a change to a running Sinatra application, you have to restart the application, as the program has already been loaded to memory.
There are options for automatically detecting changes and restarting the application on the Sinatra FAQ.
Since Shotgun fix the issue partially (reloading the files for your at production, maybe try with Sinatra::Reloader which, IMHO, works better than Shotgun.
Maybe something like (not tested)
require "sinatra"
configure(:production) do |c|
require "sinatra/reloader"
c.also_reload "*.sass", "*.haml"
end
That being said, are you sure you do need this kind of behavior on a production/test environment for updating? Development env. should be (at least, for what I use it for) for this kind of hot testing.
I used to use sinatra::reloader
but I didn't like the huge dependencies incurred (as should we all be mindful how many gems get activated)
pistol ( at a tender age of ver 0.0.2) and I think does the required job nicely
I use shotgum gem for this.
gem install shotgun
then
shotgun app.rb
from within the app dir
this then reloads the app per request, rather than holding the whole thing in memory. you access the site on localhost:9393
I have one page website only using HTML, CSS and JavaScript. I want to deploy the app to Heroku, but I cannot find a way to do it. I am now trying to make the app working with Sinatra.
.
|-- application.css
|-- application.js
|-- index.html
|-- jquery.js
`-- myapp.rb
And the following is the content of myapp.rb.
require 'rubygems'
require 'sinatra'
get "/" do
# What should I write here to point to the `index.html`
end
You can use the send_file helper to serve files.
require 'sinatra'
get '/' do
send_file File.join(settings.public_folder, 'index.html')
end
This will serve index.html from whatever directory has been configured as having your application's static files.
Without any additional configuration, Sinatra will serve assets in public. For the empty route, you'll want to render the index document.
require 'rubygems'
require 'sinatra'
get '/' do
File.read(File.join('public', 'index.html'))
end
Routes should return a String which become the HTTP response body. File.read opens a file, reads the file, closes the file and returns a String.
You could just host them from the public folder and they do not need routes.
.
-- myapp.rb
`-- public
|-- application.css
|-- application.js
|-- index.html
`-- jquery.js
In the myapp.rb
set :public_folder, 'public'
get "/" do
redirect '/index.html'
end
Link to some sub folder in public
set :public_folder, 'public'
get "/" do
redirect '/subfolder/index.html'
end
Everything in ./public is accessible from '/whatever/bla.html
Example :
./public/stylesheets/screen.css
Will be accessible via '/stylesheets/screen.css' no route required
Keep in mind that in production you can have your web server send out index.html automatically so that the request never gets to Sinatra. This is better for performance as you don't have to go through the Sinatra/Rack stack just to serve static text, which is what Apache/Nginx are awesome at doing.
Sinatra should let you serve static files from the public directory as explained in the docs:
Static Files
Static files are served from the ./public directory. You can specify a different location by setting the :public option:
Note that the public directory name is not included in the URL. A file ./public/css/style.css is made available as example.com/css/style.css.
Add below line in main rb file
set :public_folder, 'public'
ref: http://sinatrarb.com/configuration.html#static---enabledisable-static-file-routes
http://sinatrarb.com/configuration.html#static---enabledisable-static-file-routes
This would be the correct way of doing it.
set :public_folder, 'public'
I used the static setting because it's setting can affect the public_folder usage.
You can always use Rack::Static
https://www.rubydoc.info/gems/rack/Rack/Static
Just add this line before 'run' command into 'config.ru'
use Rack::Static, :urls => [""], :root => 'public', :index => 'index.html'
the sinatra-assetpack gem offers a whole bunch of features. syntax is sweet:
serve '/js', from: '/app/javascripts'
while i am still having issues with rails assets pipeline i feel like i have much more control using sinatra-assetpack - but most of the times it just works with a few lines of code.
UPDATED ANSWER:
I tied all the above with no luck of being ablle to load css, js....etc contents the only thing that was loading is index.html... and the rest were going =>> 404 error
My solution: app folder looks like this .
index.rb ==>> Sinatra code goes .
require 'rubygems'
require 'sinatra'
get '/' do
html :index
end
def html(view)
File.read(File.join('public', "#{view.to_s}.html"))
end
public folder==>> contains everything else ...css , js , blah blah..etc.
user#user-SVE1411EGXB:~/sintra1$ ls
index.rb public
user#user-SVE1411EGXB:~/sintra1$ find public/
public/
public/index.html
public/about_us.html
public/contact.html
public/fonts
public/fonts/fontawesome-webfont.svg
public/fonts/fontawesome-webfont.ttf
public/img
public/img/drink_ZIDO.jpg
public/js
public/js/bootstrap.min.js
public/js/jquery.min.js
public/js/bootstrap.js
public/carsoul2.html
public/css
public/css/font-awesome-ie7.css
public/css/bootstrap.min.css
public/css/font-awesome.min.css
public/css/bootstrap.css
public/css/font-awesome.css
public/css/style.css
user#user-SVE1411EGXB:~/sintra1$
Now start server and you will be able to navigate through static pages with no problem.
user#user-SVE1411EGXB:~/sintra1$ ruby index.rb
== Sinatra/1.4.5 has taken the stage on 4567 for development with backup from Thin
>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on localhost:4567, CTRL+C to stop
require 'rubygems'
require 'sinatra'
set :public_folder, File.dirname(__FILE__) + '/../client'
#client - it's folder with all your file, including myapp.rb
get "/" do
File.read('index.html')
end
You might consider moving the index.html file to views/index.erb, and defining an endpoint like:
get '/' do
erb :index
end
Putting files in public folder has a limitation. Actually, when you are in the root '/' path is works correctly because the browser will set the relative path of your css file for example /css/style.css and sinatra will look for the file in the public directory. However, if your location is for example /user/create, then the web browser will look for your css file in /user/create/css/style.css and will the fail.
As a workaround, I added the following redirection to correctly load css file:
get %r{.*/css/style.css} do
redirect('css/style.css')
end
What about this solution? :
get "/subdirectory/:file" do
file = params[:file] + "index.html"
if File.exists?(params[:file])
return File.open("subdirectory/" + file)
else
return "error"
end
end
so if you now navigate to (for example) /subdirectory/test/ it will load subdirectory/test/index.html
I'm building out a medium-sized application using Sinatra and all was well when I had a single app.rb file and I followed Aslak's guidance up on Github:
https://github.com/cucumber/cucumber/wiki/Sinatra
As the app grew a bit larger and the app.rb file started to bulge, I refactored out a lot of of the bits into "middleware" style modules using Sinatra::Base, mapping things using a rack-up file (config.ru) etc.
The app works nicely - but my specs blew up as there was no more app.rb file for webrat to run against (as defined in the link above).
I've tried to find examples on how to work this - and I think I'm just not used to the internal guts of Cuke just yet as I can't find a single way to have it cover all the apps. I tried just pointing to "config.ru" instead of app.rb - but that doesn't work.
What I ended up doing - which is completely hackish - is to have a separate app.rb file in my support directory, which has all the requires stuff so I can at least test the model stuff. I can also specify routes in there - but that's not at all what I want to do.
So - the question is: how can I get Cucumber to properly work with the modular app approach?
Update to include dealing with multiple Sinatra apps
Require the file where your app comes together and change
def app
Sinatra::Application
end
to
def app
Rack::Builder.new do
map '/a' { run MyAppA }
map '/b' { run MyAppB }
end
end
and just test the app proper.
eg, if you define middleware in your config.ru that you want to test, maybe move loading those into your app's definition.
Thanks to Mr. BaroqueBobcat - the answer now, of course, seems so damn obvious :). Here's the env.rb (/features/support/env.rb):
require 'sinatra'
require 'test/unit'
require 'spec/expectations'
require 'rack/test'
require 'webrat'
require 'app1'
require 'app2'
require 'app3'
Webrat.configure do |config|
config.mode = :rack
end
class MyWorld
require 'test/unit'
set :environment, :test
include Rack::Test::Methods
include Webrat::Methods
include Webrat::Matchers
Webrat::Methods.delegate_to_session :response_code, :response_body, :response
def app
Rack::Builder.new do
map '/' do
run App1 #important - this is the class name
end
map '/app1' do
run App2
end
map '/app2' do
run App3
end
end
end
end
World do
MyWorld.new
end
https://gist.github.com/28d510d9fc25710192bc
def app
eval "Rack::Builder.new {( " + File.read(File.dirname(__FILE__) + '/../config.ru') + "\n )}"
end
I've set up Rack::Reload according to this thread
# config.ru
require 'rubygems'
require 'sinatra'
set :environment, :development
require 'app'
run Sinatra::Application
# app.rb
class Sinatra::Reloader < Rack::Reloader
def safe_load(file, mtime, stderr = $stderr)
if file == Sinatra::Application.app_file
::Sinatra::Application.reset!
stderr.puts "#{self.class}: reseting routes"
end
super
end
end
configure(:development) { use Sinatra::Reloader }
get '/' do
'foo'
end
Running with thin via thin start -R config.ru, but it only reloads newly added routes. When I change already existing route, it still runs the old code.
When I add new route, it correctly reloads it, so it is accessible, but it doesn't reload anything else.
For example, if I changed routes to
get '/' do
'bar'
end
get '/foo' do
'baz'
end
Than / would still serve foo, even though it has changed, but /foo would correctly reload and serve baz.
Is this normal behavior, or am I missing something? I'd expect whole source file to be reloaded. The only way around I can think of right now is restarting whole webserver when filesystem changes.
I'm running on Windows Vista x64, so I can't use shotgun because of fork().
You could try sinatra-reloader, which is known to work well on Windows (also, it's faster than shotgun).
This works:
# config.ru
require 'rubygems'
require 'app'
set :environment, :development
run Sinatra::Application
# app.rb
require 'sinatra'
class Sinatra::Reloader < Rack::Reloader
def safe_load(file, mtime, stderr = $stderr)
if file == File.expand_path(Sinatra::Application.app_file)
::Sinatra::Application.reset!
stderr.puts "#{self.class}: reseting routes"
end
super
end
end
configure(:development) { use Sinatra::Reloader }
get '/' do
'foo'
end
It matters from where you have the require statement. But I find the following solution more elegant and robust:
# config.ru
require 'rubygems'
require 'sinatra'
require 'rack/reloader'
require 'app'
set :environment, :development
use Rack::Reloader, 0 if development?
run Sinatra::Application
# app.rb
Sinatra::Application.reset!
get '/' do
'foo'
end
Does Shotgun not work on Windows?
From the README:
Shotgun
This is an automatic reloading version of the rackup command that's shipped with
Rack. It can be used as an alternative to the complex reloading logic provided
by web frameworks or in environments that don't support application reloading.
The shotgun command starts one of Rack's supported servers (e.g., mongrel, thin,
webrick) and listens for requests but does not load any part of the actual
application. Each time a request is received, it forks, loads the application in
the child process, processes the request, and exits the child process. The
result is clean, application-wide reloading of all source files and templates on
each request.
You can also try using Trinidad a JRuby Rack container based on Tomcat. In my experience it does change reloading by default without having to modify your source files. Bloody fast too. Obviously no good if you are using native libraries, but if you are deploying on Windows you are probably used to adopting a pure-ruby approach.
Its syntax is just as simple as the thin approach:
jruby -S trinidad -r config.ru
There is no Java specific yak shaving (i.e. creating web.xml or WARing up your Ruby app) and the gem is simple to install.