We want to add the routes defined by an LDAP authorization application (a pure API application) to our core rails application, under the path /ldap-auth.
We have the option to use any technology we want for the LDAP authorization application -- we could write it with rails-api, Sinatra, even pure rack -- though we lean toward rails for codebase consistency. The key point is that it's a self-contained application, with its own tests and release schedule.
What would be the most idiomatic rails technology for this use case? Reading the guides it seems that a rails Engine or a mounted Rails API app are the natural possibilities.
My questions are:
What factors should guide my choice of one over the other?
The Engine guide states that "engines and applications can be thought of as almost the same thing, just with subtle differences, as you'll see throughout this guide." However, even after reading through the guide, it's still unclear to me why one would choose to use an engine, versus mounting an ordinary rails app. I'd appreciate clarification on this point.
Finally, if we do decide to go with a mounted rails API application, we'd like to keep it in the same repo. Where is the most idiomatic place to the code? Under /lib?
Related
In computing terms, an engine is something that is continually producing output based on input. But in Ruby, the term seems a little bit loose. The people who've created Refinery CMS have taken to calling gems that extend the functionality of their system, 'engines'.
Basically, what I want to know is, is Spree, the open source ecommerce cms written in ruby, an engine? Would calling it the 'spree engine' be correct?
As defined by Rails, an Engine is a lot like an application within an application. Spree is one of these, and there are others. Each engine has its own app folder with the same sort of structure you'd see in a top-level application.
You can combine one or more engines together into an application, then add your own functionality on top. That's what makes systems like Spree far more flexible than a fixed-puropose Rails app that you have limited control over.
Things that extend Rails are only truly engines if they are self-contained applications. Many gems add functionality that's much more specific than that, so are better termed "plug-ins" or "modules" depending on the phrasing.
It's actually pretty easy to build your own engine and can be useful for separating and re-using code across several different applications.
I think that there is quite good explanation in guide Getting Started with Engines.
Spree is actually comprised of many engines...
The overcooked version: Engines come kitted with (many of) the guts of a typical rails application, with a few bonuses: namespacing out of the box, generators for easily copying migrations, and the ability to mount it in another rails application.
From http://guides.rubyonrails.org/engines.html
1 What are engines?
Engines can be considered miniature applications that provide functionality to their host applications. A Rails application is actually just a "supercharged" engine, with the Rails::Application class inheriting a lot of its behavior from Rails::Engine.
Try to read this guide: http://guides.rubyonrails.org/engines.html and also this cast: http://railscasts.com/episodes/277-mountable-engines
Just finished watching "Railscast 277" on mountable engines in Rails, what are practical uses of mountable engines?
One of the best examples would be Devise (for authentication) which is an engine (plugin) but its mounted as a shared-engine; you also get namespaced engines and this helps to retain a sense of context.
Another example would be the Active Admin add-on, error notification plugins...and a whole lot more. In terms of 'mounting' from a purely routing point of view, you can see how — with a namespaced engine you can serve a completely isolated rails app from a route from within your app itself.
You should consider reading this as well.
Two major uses:
Reusability. Gems that expose a lot of application functionality are often distributed as engines.
Modularity. Particularly for large applications, there are often parts of the application that don't seem like they want to be mixed in with the main application, yet are too closely related to be extracted to entirely separate applications. Engines can work well for this.
Spree takes this to extremes: the core Spree framework is the main Rails application, and to customize it, you write engines. This means you're never modifying the Spree core directly.
Some ruby gems like jekyll, toto and webby offer out of the box blog-type integration into your ruby app. Another way of developing a rich web blog-type application is to build and model the application yourself using pure ruby and rails practices. (e.g creating an Article and User model). The first offers out of the box features the 2nd option offers more customization and control.
In people's experience on Stack Overflow, which would be the best route and what would people consider when making the decision to use a gem out of the box versus going alone?
All of the gems you mentioned take static, markdown/textile/etc files and turn them into HTML websites. They take different approaches to it, with jekyll spitting out the finished website for hosting, toto doing the converting and routing on request, and webby doing the same as jekyll mostly.
If you're using Rails, it's important to note that none of these will integrate into your application well. They're built to more-or-less operate on their own.
Generally speaking, if a gem has the functionality you need, use it. They are not equivalent to plugins you find for Wordpress and Drupal where they are typically low-quality, buggy, poorly documented, etc. More often than not, gems simply add a couple modules that you can integrate into your application how you like.
On the other hand, a basic blog is pretty quick and simple in Rails, especially considering you've got a handy walkthrough guide straight from the Rails documentation on how to do it.
If you're new to Rails and want tight integration with your app, it's probably best to bake your own blog features.
This will take some time to do, but its worth it to learn how things really work.
If you're more seasoned, just look at the gem's API and documentation and decide if it does what you want it to do and if you're comfortable with how to integrate it. If so, it'll save you time.
One other consideration: who will be using the blog? Is it for internal use, and programmers will be the ones updating it? If that's the case, then you can make it very easy by not worrying about a lot of aesthetic polish in the back-end. Conversely, if you're making an app that includes a blogging component for the general public you might want it to feel more polished. In this case a gem might save you a lot of time.
It depends on your application.
I've been using online tutorials to learn ROR. I've used www.lynda.com video lessons to get a basic idea what Rails is all about, and for practice I used Rails version 2.0.2, during my training period. But now I'm into a development team in a starter company where there are no senior/experienced programmers to assist me and we're working on gitorious source code modification using Rails 2.3.8. I'm facing a lot of difficulties to understand the source code and some of the major differences I could notice is as follows:
Inclusion of XML and HTML to render views in scaffolds, in Rails 2.3.8(I don't understand what this is, as I'd never come across this during my training period using Rails 2.0.2)
In gitorious source directory, in addition to Controllers, Models, Views and Helpers there are two more directories namely, Processors and Metals. I don't understand what their significance is.
Extensive usage of .yml files. What are those for? In rails 2.0.2, all I came across was the database.yml. Now, in gitorious, I see gitorious.yml. How are all these so customized? I mean, how do rails app(controllers, models, etc..) communicate with gitorious.yml?
With respect to all these questions, how do I move a level or two up, to call myself an "intermediate Rails programmer" from "Rails novice programmer"? and how do I stay updated of new api, deprecations, in all upcoming Rails transitions?
Inclusion of XML and HTML to render views in scaffolds, in Rails 2.3.8
Yes, the way scaffolding works has changed - I can't remember exactly when it changed, but I can certainly believe the change happened between 2.0 and 2.3.
When you generated a scaffold the old way, it would just include 'scaffold' commands in the controller, which would render up a default interface for each of the actions until you replaced them with your own HTML templates.
The new way actually generates the HTML templates as files: so, in the views directory, there will be a directory containing ERb (HTML with embedded Ruby). You can then go and edit those directly.
It also renders XML - this is done by default, but you can choose what other formats are produced. Rails lets you produce multiple output formats for each controller action - so that you can easily produce RESTful web services. So, you obviously produce XML by default, but you may want to produce machine other formats too: XML (including RSS/Atom), JSON (and JSON-P etc.), RDF, YAML. I use this to produce CSV and Excel so users of the site can get data exported to their spreadsheet package.
In gitorious source directory, in
addition to Controllers, Models, Views
and Helpers there are two more
directories namely, Processors and
Metals. I don't understand what their
significance is.
processors/ is used by ActiveMessaging - it contains ActiveMessaging processors - basically code that gets called as part of communication with a message queue that ActiveMessaging is hooked up to.
metal/ contains code that can best be characterized as 'middleware' - basically, to deploy a Rails application you use a library called Rack which abstracts away the interface between the server and the app itself. It allows you to use the same web server and other infrastructure and switch between different Ruby frameworks - so, if you are using Rails or Sinatra or Merb, Rack lets them all communicate with the same server.
Now, Rack allows you to write 'Metal' code, which is code that gets run directly on the server without the framework getting in the way. The reason you write Metal code is for performance - when Metal code is running, it is running directly rather than with the weight of the Rails framework getting in the way. This way, you can get better performance. I haven't ever had to write any Metal code, so I can't really explain it beyond that.
Extensive usage of .yml files. What
are those for? In rails 2.0.2, all I
came across was the database.yml. Now,
in gitorious, I see gitorious.yml. How
are all these so customized? I mean,
how do rails app(controllers, models,
etc..) communicate with gitorious.yml?
.yml files are files in the YAML format. In Rails, these are mostly used for configuration. Just as XML files are used by Java applications for configuration, .rc files are used in Unix for configuration and .ini files are (were?) used for various apps on Windows for configuration, you can store data in the YAML file which the Rails app uses for configuration. Because of the simplicity of the format, a lot of Ruby and Rails apps use YAML for configuration files.
Ruby has a built-in YAML module that loads these in using methods in the YAML module including YAML.load, YAML.load_file, YAML.load_documents etc. To see how they are being loaded in, I suggest the easiest thing is to find the string "YAML." in the project - or, indeed, the name of the yml files.
With respect to all these questions,
how do I move a level or two up, to
call myself an "intermediate Rails
programmer" from "Rails novice
programmer"? and how do I stay updated
of new api, deprecations, in all
upcoming Rails transitions?
I would suggest that a fair amount of conservatism is appropriate with Rails updates. I'm still using Rails 2.3.3 on a production site, and that's fine. I should probably upgrade to 2.3.8, but I tend to not run with the bleeding edge on production projects.
As for the best way to learn, I'd suggest that you work through Railscasts - these are excellent short screencasts that describe all sorts of useful techniques and help you learn lots about the Rails framework. When you need to do something, obviously there is the API docs - which are okay. The Rails Guides are pretty good and worth reading.
As for books, there's Agile Web Development with Rails - which is a pretty good tutorial. There's also The Rails Way, which is a massive desk reference and in my experience one of the only good ways to learn about some of the minutiae. You might also want to check the StackOverflow question What’s the best resource for learning Rails for a raw beginner? - because although you obviously aren't a raw beginner, the resources recommended are up-to-date and useful for going from novice to intermediate and on upwards. Good luck!
I've been learning the Ruby web framework Sinatra lately, and I'm finding it great to use. Most of the articles and blogs I have read about it seem to assume that it is good only for small websites, or 'tiny' web-apps. Is this true? Can a complete web application be built in Sinatra, or is Ruby on Rails the way to go?
You could, in theory, build an entire web application using Sinatra, and it would offer you more precision control than Ruby on Rails would.
That said, it also removes all of the nice features ruby on rails gives you, such as the Model-View-Controller architecture.
If you're looking to build a web application with database interaction, I strongly advise you use Ruby on Rails.
If you're looking to build a very simple API or something that just takes some data and throws it up onto Twitter or something, go ahead and use Sinatra.
There is no reason that it couldn't be used to build an enterprise website. It's fast and intuitive. Two key things in building a larger web application. While it does lack many of the features of Rails, I am yet to run into a road block.
I personally like the slim nature of Sinatra. It embraces routing instead of making it a headache.
I usually find myself wrestling with Rails, whereas I configure Sinatra to my liking.
As for database interaction, mongo_mapper + Sinatra works very well.