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 need to develop an interactive web app with an admin backend. I have thought about using Ember.js for the frontend and Ruby on Rails (with ActiveAdmin) for the backend.
But i have some questions:
1) Should i put the Ember.js app inside the rails project, or having both separate? Is there any performance difference or something i should know about choosing one of the two strategies? I like to have things as clear as i can.
2) Should i use Ember.js and Rails-API instead? I mean... i think i won't use almost anything about the Ruby on Rails project... But i am confused, as i need the Admin Backend...
I have some experience (a little) on Ruby on Rails, but as i am new to Ember.js, i would really appreciate any help you can give me.
I also worked on a similar kind of project, and believe me having two different projects will benefit you a lot.
I used followings:
Sinatra for backend
Backbone.js for frontend
It makes a lot easier to add the functionality in your code, when you use two separate apps.
I recently had a similar project with an Angular app and a Rails backend. I agree with Arslan. Having a Sinatra, Rack or other API is better than Rails.
Using Ember for some parts, and Rails for other parts (like the Admin section) is a bad idea because:
You are doing the same things 2 different ways: getting data, rendering pages, etc.
You would have 2 separate functionalities in within the Rails app: one Rails app and one API.
It is much simpler to run 2 separate apps than to put a Javascript MVC into a Rails app. You end up with complexity in getting the Asset Pipeline to do what you need.
Here's my take:
If you're fluent in Rails, stick with Rails.
Yes, Sinatra or other frameworks may be lighter, but you'd have to handle lots of things by yourself.
As for Rails-API, it's a good project, but it's a bit of hassle at the beginning to figure out what modules were removed, etc. You can make an API with Rails without Rails-API. You can always use Rails-API at a later point if it turns out you need the performance increase.
Use Ember CLI for your client application.
It's the golden path for developing ember applications and using third party libraries. The gem Ember-rails still works and is still maintained, but you should not start a new project with it.
Keep them separate
It simply makes more sense to have them separate. This way, development and deployments of both apps are not tied to each other.
It uses more repositories though, and if you're using github, it may mean you'd have to switch plans. But there are other options such as bitbucket where the pricing is not tied to the number of private repositories
I hope this helps you.
Related
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 have spent alot of time developing on sinatra, and that has worked fine for me because I have only worked on small projects and scale has not been a problem. Now I have the need to use rails, and the structure is a little confusing to me. I understand that when I type localhost:3000/images rails looks for the route in routes.rb (e.g. get 'images#index'), then goes the the controller images then in images looks for a index function, and finally finds the index view and renders it.
Why are all of these changes necessary? Couldn't it be simpler like sinatra (which seems to just include the controller step in the main file)? In an answer I am looking for why it is better to do it the way rails does it including specific reasons, advantages and disadvantage with examples.
Thanks in advance!
Konstantin Haase is the current maintainer of Sinatra and feels that they both cater for different types of application:
They are both solving a different set of issues, even though they
indeed overlap. While Rails is a framework focused on writing model
driven web applications, Sinatra is a library for dealing with HTTP
from the server side. If you think in terms of HTTP
requests/responses, Sinatra is the ideal tool. If you need full
integration and as much boilerplate as possible, Rails is the way to
go.
David Heinemeier Hansson also believes that there was room for both of them, but feels that is size of your app that should influence which one to use:
Sinatra is great for the micro-style, Rails is not. As long as you
stay micro, Sinatra will beat Rails. If you go beyond micro, Rails
will beat Sinatra.
So, basically, Sinatra and Rails are different and they have different use cases. Rails is an open source full-stack web application framework. It follows the popular MVC framework (Model, View, Controller) model and is known for its "convention over configuration" approach to application development. So, as you can see controller is a part of Rails by design.
You can find many articles describing the differences between Rails and Sinatra and their use cases. Here are couple of interesting blogs:
Rails vs. Sinatra
Rails vs. Sinatra by Example
K M Rakibul Islam's answer is great. You might also check out Rack. Both Rails and Sinatra are built on it. Rack is a web server interface that expects an "app" to be a Ruby object that takes a request hash via a method called call and then to respond with an array that includes the http response code, the http headers and the response body. It's pretty barebones. Looking at Rack might give you a better sense of how the two diverge past that-- if you're interested in "how" rather than "why".
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'm using yard to generate my documentation for Rails apps from an rdoc file. There are AngularJS documentation generators, but how could they be connected to generate one coherent document for an AngularJS + Rails app?
In this case it is probably fine to have them separated, and indeed may make more sense to have them separated. Angular is going to be solely for your client-side stuff, and I'm assuming you're then using Rails as an API or perhaps a different piece of the app's functionality. Either way, they are fundamentally doing different things, so it would make sense to have them in different doc sections.
You could create a "landing page" for your documentation if you'd like: one button links to Angular docs and one to Rails docs, and that would solve the need to have them both "in one place". Actually figuring out a way to make them overlap in the same system is likely not worth the effort though, and may actually be a worse user experience.
As the previous answer stated, it would be good to use two different tools and link them together.
I would start with something like Apipie or just rdoc to document the ruby stuff. Additionally I would search for a good js documentation generator. This article compares a four different generators, while 'Docco' seems to have a ruby port with that is called 'Rocco', that may be even able to generate documentations for both, ruby and js. JSDoc on the other hand enables you to integrate custom pages into your docs (here you could place a link to the apipie generator).
In general I would probably just go for the rails API doc and have some conventions for commenting your angular code, as the angular stuff probably has no API that is accessible by another part of your system and therefore only needs some internal documentation.
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 8 years ago.
Improve this question
I see some old questions here and here
It is now 2014, and I also have a more specific question.
Another company has built a REST API. Now I want to build a web application that only needs controller and view. I was originally planning to build this with just PHP without the bloat of an MVC framework. Then I was thinking maybe doing it with ASP.NET with just simple code behind and .aspx approach (the non-MVC way). I was even considering using only JQuery and HTML. The reason I haven't really considered a full MVC framework is because I'm simply just sending data, getting data and printing data. I don't have to really implement business logic.
Right now I'm considering doing this in just the ruby language because it seems like such a clean and minimalist language. But is there any advantage to including the entire rails framework? If so, what features are worth considering in the rails framework for my purposes?
EDIT
It seems I got a close vote for opinion based. But I'm not looking for opinions. I'm looking for the advantages of rails framework for my purposes. In other words, what problems can the rails framework solve significantly faster than just using ruby+curl+print_line().
As example on how to answer the question objectively, you can state things like:
Scenario 1:
Rails makes CURL calls and displays in views like so.
Pure ruby make calls and outputs views like so.
Result: As can be seen, rails requires X fewer lines of code than pure ruby as it pertains to the OP's original question
Scenario 2:
Rails handles page caching like so.
Pure ruby page caching will need to be handled like so.
Result: As can be seen, rails require X fewer lines of code than pure ruby as it pertains to the OP's original question
By listing the problems the original rails authors hoped to achieve and solutions they hoped for us to utilize in the situation defined in the OP's original question, we can see quantitatively the advantages Rails has over pure ruby.
Rails is pretty big, and in my opinion you don't need the bloat of Rails for something this simple. Even though it's not an MVC framework, I would recommend something like Sinatra, especially since it doesn't force you to use a database at all. Sinatra is a very simple framework, and it's most useful when you just want a way to easily set up HTTP routing with basic view support. However, note that it is possible to create a model that doesn't use ActiveRecord with Rails.
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 8 years ago.
Improve this question
I'm a studying CS and lately I've got myself really enjoying learning about web development..
Now, I have tried to learn AngularJS for a few times but then I wanted to focus more on backend first, since I already know the stuff like html/css/js which makes good part of frontend so wanted to see what backend feels like..
So I started learning Rails.. Now, since with my previous attempts of trying to learn AngularJS I learned that it is all about MVC, sending data from one to another etc.. My problem is, at first glance at least, Rails seems to work in the really similar fashion. The question is, why would anyone want to use both AngularJS and Rails at the same time, when, at least in the newbie's eyes -> Rails seems that it can handle both backend and frontend? Like, views are our frontend, and we can use css/js in those .html.erb files, wouldn't that be considered frontend after all?
Now, I'm almost positive there is a good answer to this since googling "why use angular with rails" usually comes with results of tutorials that explain to you how to integrate them, I just want some reasons so that I wouldn't be as confused as right now..
Thanks!
Rails is a server-side framework that produces HTML, JSON, and JavaScript as well as manages CSS and image assets.
AngularJS is a client-side framework. Generally, without a server component it really can't do much.
By default Rails doesn't have a client-side framework. You can use EmberJS, Angular, or others to make your client-side interface more responsive and flexible. Rails alone can't do this, it can't run in your browser.
Likewise, AngularJS can't run on your server. You need to combine them.
MVC at frontend is a recent development. Earlier days we used to develop everything at backend and use frontend only for animation, UI etc.,
Slowly with Ajax introduction we started doing more at frontend and less at backend.
Now we migrated completely to frontend. We use backend only for logics which should be decided at server side and database management.
Single line answer, we need rails or any backend only to serve few logics which SHOULD happen in the backend, User can change the logic if it is at client side. So we force them to happen in the server side. And ofcourse database should be at the backend.
Other than that , there is absolutely no need to use rails views and others.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I am starting to learn Ruby on Rails. I have an application in mind that I would like to create, but I know I'm going to have to repeat a lot of the things that have already been done a million times (such as user authentication, etc).
I just found out about rails templates. From what I understand, you can use one of these templates to create a new rails application and set up a lot of the basics. Where can I find some of the most popular templates, and should I use one of them?
Andrew, if you are starting to learn RubyOnRails and have an application in mind, I suggest you DO NOT use any templates at all and do it by hand.
Rails templates primarily pull in gems and other external dependencies (plugins) into your app. The primary benefit of templates is for people who build so many Rails apps so often that they'd like to get bootstrapped really quickly.
You would learn more and feel much more confident about the whole process if you consciously chose the plugins/gems you need and progressively added them to your app.
Devise (popular authentication gem) goes so far to say, that if you are starting with Rails app, you should NOT use it.
Here's a more current answer which applies to Rails 3 (the other answers are all from January 2010).
After playing around with editing application templates for a few months, I've found it can be a headache to assemble and maintain a application template. It helps to have a collection of "recipes" that can be maintained individually, then assembled into an application template.
I'm using the
rails3_devise_wizard
which is a version of the RailsWizard gem with custom recipes for a Devise starter app.
I've used it to create two application templates:
Rails 3 + Devise + RSpec + Cucumber Application Template
Rails 3 + Devise + RSpec + Cucumber + Mongoid Application Template
which generate the following example apps
Rails 3 + Devise + RSpec + Cucumber Example App
Rails 3 + Devise + RSpec + Cucumber + Mongoid Example App
and each has detailed tutorials showing how they're built:
Rails 3 + Devise + RSpec + Cucumber Tutorial
Rails 3 + Devise + RSpec + Cucumber + Mongoid Tutorial
Jeremy McAnally maintains a diverse collection here: http://github.com/jm/rails-templates/
I don't think there are any silver bullets, but they display a lot of techniques that templates allow.
Rails Kits may also fit your needs, even though they're not actually Templates:
http://railskits.com/available-kits/
There are several ways to extend a Rails application and/or start one off. You've mentioned just one of the big four. The others are:
Plugins
Engines
Gems
Templates
Templates are generally used to start out an application, but if designed correctly, you can use them to extend one. For example, many stock templates out there help setup a code repository, install a few plugins/gems, and perhaps fix up the layout a little so you don't have to. Of course, you'll usually do most of these when you first start out a project. At our company (3 developers) I created a template that sets up our dev and production environments, repositories, project tracking. Here's my favorite stock template: http://github.com/lhoeg/app_lego/network
(The original hasn't done much work on it in a while, and I believe this is the best fork out there now)
Plugins and Gems are more or less becoming synonymous and there's little reason any more for people to create plugins, as gems are the more Ruby-standard way to package functionality. Generally you'll use plugins to add bits of very specific functionality to your application. This can range from adding user authentication, to calendaring, to adding locations and mapping to your app. Most plugins that I've used extend the ActiveRecord or database part of the application. If the plugin comes with views, controllers, or modifies your database tables it'll usually come with a generator. A good example is the Restful Authentication plugin's generator. A relatively good list of http://agilewebdevelopment.com/
Engines are the kings of modularity. They usually provide a lot more functionality than plugins. Whereas plugins and gems generally extend Rails itself, Engines are intent on extending YOUR application by adding a full set of views, controllers and models. Thus engines are entire Rails applications packaged into a neat little box that you can just plop into your app and instantly add a bunch of functionality. There's also an Engines directory at http://agilewebdevelopment.com/ but as you'll see, there aren't very many.
Hope this helps!
Berns
Try to search on github, there are really a lot of cool stuff. http://github.com/search?langOverride=&q=rails-templates&repo=&start_value=1&type=Repositories
If you search a example of authentication try to search a authlogic-example on github.
Ryan has some Rails templates: http://github.com/ryanb/rails-templates
It seems Jeremy's repository gave me a 404 when I tried it.
We have developed a Rails application template.
https://github.com/agilie/Rails-Application-Template
For now it contains testing, deploy, documentation generation functionalities, sidekiq, redis and much other gems and stuff.
It is fully customizable and you can easily enhance it for your needs. Feel free to fork and make some pull requests.