Most of the resources/example about rails and angular on the internet just put them together. AngularJS goes inside of rails under app/assets. This feels reeeaaaly dirty to me. Is it a good idea? What if we decide at some time we won't be using rails and we move to, I don't know, sinatra? How hard would it be to port?
What would be pros/cons of everthing in a single rails app and what would be pros/cons for two seperated apps?
Thank you!
Even when placing Angular (or any other client-side MV* framework) inside your Rails app, you are pretty much keeping the separation of concerns intact. That is, you have a Rails API serving JSON (or similar) data, and a separate Javascript framework using that data to render appropriate views. If you ever wanted to use a different server-side API, you can do so, and still utilize your entire Javascript directory as is.
Placing the client side framework in Rails is simply a matter of convenience. It comes with an organized directory structure and the ability to serve your HTML, which is essentially all you're using it for when it comes to your views. But again, these views aren't really tied to Rails, as they're just HTML and Javascript, so you can easily move them to a different platform when necessary.
Related
I am using rails-api gem for an api project....
I have two or three webpages how do I do it SO that html will make an ajax call and consume JSONS
Where can I keep the html pages and render it..
Rails::API is a subset of a normal Rails application, created for
applications that don't require all functionality that a complete
Rails application provides. It is a bit more lightweight, and
consequently a bit faster than a normal Rails application. The main
example for its usage is in API applications only, where you usually
don't need the entire Rails middleware stack nor template generation.
You can start adding middleware and subframeworks back to Rails-api - but then your turning your lean and mean racecar into a minivan.
A better solution may be to create a separate rails app which serves the HTML pages and has the full rails package.
If they're static pages (with static urls), you can put them in /public. It's generally considered bad practice, but it will work.
I'm about to start a new project and I am unsure if using AngularJS for my front end would be a good idea not. I've read about people saying this isn't the smartest way of doing a project. And even if I did, Is there a way to get AngularJS to interact with the controllers? This question may be redundant but I am actually curious of how to effectively do this without it being a waste of time.
I've never completely done it, but I believe the way to go is to build a Rails api and then have a separate Angular project use said api. The api could also be used to build a mobile app. I think the Angular project would still need to be served from a Node.js server in production, but I don't think that would be a big deal.
This is what I used to learn how to build a Rails api: http://apionrails.icalialabs.com/book/chapter_one
You can do it within an existing project and share the models from it.
There are several different approaches to accomplish that. I tried about 5 different guides out there, the best I found (and I finally sticked to) was https://thinkster.io/angular-rails - This guide should help you build a basic CRUD app with angular connected to rails.
You use Rails as an JSON RESTful API which responds to Ajax-Requests (Get, Post, Put, Delete). Angular will handle the frontend stuff - sending those Ajax requests to the routes/methods defined in your rails controllers. So yes, of course your AngularJS app can interact with your rails controllers.
This also helped me to understand the setup in the beginning: Instead of the Rails View, you will be using AngularJS as your view:
I really love using angular with rails, because setting up the JSON responses (especially with Active Model Serializer Gem) is very easy and quickly done. i deffinitely can recommend it, and I have not encountered any unsolvable problems - so far.
Just go trough this guide I linked and you will see if this setup fits your needs.
The short answer is that your Rails application will have to present some kind of a public API for your AngularJS application to consume. Angular (and it's brethren, like React and Ember) runs client-side, on the browser, and it needs "something" to make AJAX calls against. That "something", i.e. your backend, can be Firebase, Parse, AWS Lambdas, Rails API, etc. Since you already have a Rails application, it probably makes the most sense to add some RESTful API endpoints that use the existing models (and possibly controllers) to consume/produce JSON payloads from/for the client.
I've been using Ruby on Rails since a little more than one year now and I've always do it in a casual way, I mean, everything in one place (front & back), using the standard .html.erb file populated by the associated controller method.
Otherwise, today in our project, I have the need to separate the front and the back end for multiples reasons (code maintainability / clarity, better architecture, more reactivity, etc...).
I've done plenty of researches, watch some conferences (1, 2, 3), but didn't find my solution yet. It looks like to be a question that comes often, but what is the best practice/tools to separate the backend and the frontend of a Ruby on Rails app?
I don't feel we need (yet) a huge JS framework like React/EmberJS/Angular/etc...
First I was thinking about something like Middleman/Jekyll and make the communication via JSON and API calls, but it seems like that it's not a good solution for dynamic website.
So is there a frontend framework that works well with a Rails API and which is easily maintainable and upgradable (add feature/extension to it like gems)?
Thanks for your insights.
A friend of mine wrote this great article/tutorial on Rails as a backend API.
http://blog.launchacademy.com/the-basics-of-building-an-api-in-ruby-on-rails/
As well as this tutorial on Rails/Ember.js
https://github.com/diegodesouza/Project-Planner-EmberJS
You can get an idea of how it's done and implement your preferred front end framework.
Hope it sheds some light on this question.
I have a similar setup as one of the commenters on the question.
I'm using Rails mainly for just the project structure, to define some page layouts, and for ActiveRecord.
I then have my JSON APIs defined using the Grape API framework.
I have a SPA, written on AngularJS that lives in the public/ folder. It doubles as my mobile app, made possible by phonegap. If my Angular app didn't double as my mobile app, I could've possibly just used the asset pipeline to serve up the SPA. To compensate for that, I have a separate build task written in Grunt to minify/uglify my JS/CSS assets before I deploy them out to production.
I also use Comfortable Mexican Sofa for my static content pages.
It took some trial and error to get things right, but overall I find that this setup serves me pretty well.
I have a existing project in Ruby on Rails.
What is the best way to use AngularJS in Ruby on Rails app?
I want to use AngularJs for only specified modules, not for create SPA. This is good way?
What I have seen colleagues do in order to achieve this sort of integration with an existing rails app is:
Include angular.js and relevant dependencies in the specific app pages that are to be 'angularized'
Interpolate whatever data is needed to bootstrap the angular controller into the html template which contains the angular app. This might include data about the resource being operated on. I've seen this done by rendering a RABL template inside of a haml/erb template.
Using that interpolated data, call whatever API methods you need to get additional data on the fly. This is usually just a matter of implementing json handlers for routes you've already created.
I can't say whether this is best practice, but its an easy way to get started fast.
Best of luck, angular is a very enjoyable tool to work with once you get used to it.
Hypothetical question (at the moment!)
Suppose I have a great idea for an application. It acts on data which can be well-represented by tables in a relational database, using interlinked objects which represent those tables. It supports a well-defined API for interacting with (Creating, Reading, Updating, Deleting) those objects, and viewing information about them.
In short, it's a perfect fit for Rails... except it doesn't want to be a web-app. Perhaps it wants a Command Line interface; or an OS-native dialog-based interface; or perhaps it wants to present itself as a resource to other apps. Whatever - it just isn't designed to present itself over HTTP.
These questions suggest it's certainly possible, but both approach the problem from the point of view of adapting an existing web-app to have an additional, non-web, interface.
I'm interested in knowing what the best way to create such an app would be. Would you be best to rails new non_web_app, in order to get the skeleton built "for free", then write some "normal" Ruby code that requires config/environment - but then you have a lot of web-centric cruft that you don't need? Or would it be better to roll up your sleeves and build it from whole cloth, taking just the libraries you need and manually writing any required configuration?
If the latter, what exactly is needed to make a Rails app, but without the web bits?
If you want to access the Rails ORM to develop a CRUD non-web application, just include ActiveRecord in your own Ruby script; you will avoid using a lot of Rails modules you probably don't need (routing, template generator, ...) Here is an example of how to do it.
If you prefer to have the full Rails stack, do not run your Rails web app in an application server (WEBrick, Passenger, Mongrel, ...) to avoid any HTTP exposure, and interact with your application using tasks or the rails console.
I would avoid taking Rails too far off the rails. If I were doing this and felt that the gains of rails w/o the web stuff I'd do the following:
rails new non_web_app
and ignore the webbish cruft and use rails to generate models. In this way you get the tight, comfortable database behavior and can tie various gems in as you want to augment those models. I'd not bother implementing views, of course, and I'd consider implementing controllers in which the various render bits are removed and to use you instantiate an instance of the controller and call the action directly. This means the controller represents your API into your business logic still but the "views" it now "renders" are simply the return of the data output.
Then you could simply strip out the bits you do not need...the public directory, the view structure under app, config/routes.rb, etc. You'll need to test those changes incrementally and make sure that removing some now extraneous bit doesn't throw the Rails world into chaos.
Rails is for Web apps. That means HTTP. Now, you could package a Web app so that it runs on the desktop instead, or you could use ActiveRecord with a desktop application framework like Monkeybars.