I have a rails app that has pretty standard things, except for two pages that require a lot of JS.
I was wondering if it's a good choice to use ember just for those two pages while keeping Rails standard for everything else? Or should I rewrite everything in emberjs + rails as API backend?
This is really a case-by-case situation. Why do those two pages require a lot of JS? The answer is probably "because of an implementation decision you made." Adding Ember to the mix is probably going to prompt you to revisit a lot of implementation decisions to reconsider which tools are appropriate to use in which places.
Related
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 need to build a web service, for a mobile game, to manage the states of multiplayer games. I need a database and an RESTful API to access it. I'm very familiar with Ruby On Rails and was thinking of using that since I can throw together the DB and API pretty quickly. However, since RoR is a framework for building web pages and I'm not actually building any web pages, it naturally seems like the wrong technology to use even though it would work. As such, I'm considering using Ruby on Sinatra, but I've never used it before and I'll have to kill some time learning it. For you Ruby gurus, is there an advantage to using Sinatra or a disadvantage to using RoR for what I'm trying to accomplish?
Thanks so much in advance for your wisdom!
You know Rails, you don't know Sinatra. Personally I prefer the latter for things like building APIs, but there's nothing stopping you from doing it in Rails, and there's nothing intrinsically wrong with it either. Unless you want to see this as a learning opportunity for getting into Sinatra, I'd say stick with Rails. Here's some links that might be useful btw:
Building APIs With Rails
Building a Platform API on Rails
It probably depends on your API. If you need more than just a bunch of routes then you will have to come up with your own solutions (authentication, ...).
If all you need is some RESTfulness without the added weight, Sinatra is great. All you need to know is what happens in what route and you're fine. See the Sinatra Readme which has all the information to get started.
Most of the time, whenever I hit a website that looks "bubbly" in nature, and all prettified in those pastel-like colors, I think to myself, "This was probably done with Rails." And, lo and behold, after some digging into the site's information pages I discover this is actually true. So, I pose the question, not knowing much about Rails but enough about Django to understand how the database stuff works:
Does RoR have any display-specific qualities that affect how a web page looks? Or do all RoR devs naturally use the same Adobe tools to make everything look so ubiquitous?
Ruby on Rails is a server side technology, so it doesn't lend any specific quality to the user visible design. That said, it is a "trendy" technology so people who are likely to write their back-end code with RoR are likely to choose a particular "Web 2.0" style for their views.
As a Ruby on Rails developer, I can tell you that most Ruby on Rails developers are passionate about their work and we pay a lot of attention to details when building websites as much backend as front end. Its not just a trend, its a way of thinking and working.
No, it hasn't any display-specific qualities.
The theory is that RoR makes that backend stuff easier, so more time can, and apparently is, spent on the front end stuff.
Its all done with Mirrors. And CSS. :)
Rails is a very popular Web framework, it's just be coincidence that all the ones you've looked at have been rails apps.
What kind of sites have you been looking at to draw this hypothesis?
that's a funny question with a funny description :) ... bubbly!
As a madman, I develop with RoR, it's kind of rule in our area. We learn madness from the beginning, as a result of http://railsforzombies.org...
May wise men follow a wise path!
Short Answer: NO
However...
As a Rails developer I can say that due to the Agile nature of Rails and the speed in which you can develop web applications with Rails I do find myself having more time freed up on a project to spend polishing the user interface. I believe this may be a reason you often see more polished looking Rails sites.
So in my mind I believe your choice of framework can have a direct correlation to the end product that is produced!
Rails does add some stuff to the front end. Like to every html form, it will add a hidden input element authenticity_token.
You can also tell because rails URLs and form actions will never end with suffixes like .aspx or .php or .html or .jsp, and they won't usually append ?query=book&encoding=utf8 like you see on google. And they won't usually have superlong crufties like you see on amazon (eg http://www.amazon.com/Agile-Web-Development-Rails-Ruby/dp/1934356549/ref=sr_1_1?ie=UTF8&qid=1297922135&sr=8-1). Instead Rails prefers simple routing URLs. If amazon were written in rails, you might instead expect amazon.com/books/Agile-Web-Development-Rails-Ruby
So there are ways to spot a Rails app. I expect other web frameworks, especially the ones that emulate rails, would duplicate some or all of these features, so this isn't a sure-fire method, but it helps.
I have a project going on, and I am in charge of the front-end design, whereas my developers will work on the back-end with Ruby on Rails.
I do not know Ruby on Rails, and am designing front-end using XHTML, CSS, jQuery, 960.gs CSS Framework. My developer is supposed to take my design and connect the elements of back-end to it, with Ajax too.
What are the things that I should know while designing the template/view so that I won't kick my developers' asses with my design? How to help the connecting of elements painless? I understand I must avoid . Some Ruby on Rails developers also prefer Blueprint CSS Framework over 960.gs.
Any guidance? Thanks.
Generally the Rails templating system is quite flexible and will enable developers to create even complex designs. The CSS framework should not make such a difference. However if they are using Rails 2.x it is markedly easier to use Prototype instead of jQuery. However Rails 3.x is also agnostic to javascript library.
A relatively good overview is the official guide. You might also try out this tool for cutting up your views and layouts.
I can speak from the developer point of view.
The things that piss me off are too complicated css structures, keep it simple and abstract as you can.
The other things is naming classes and ids, in general try to find out what models the developer is using and name your classes and ids accordingly. E.g. for a blog with posts:
#posts .post for a post in the index view and #post for a post in the show view.
I never care what css framework the designer uses, as long as it works.
And lastely, if you design different html pages, be aware that we often have only one or two layouts, that's eg. /views/layouts/application.html.erb and we usually try to keep that number low as possible.
jQuery is find, ever been my preferred choice over rails' own prototype.
This is a bit of a weird meta-programming question, but I've realized that my new project doesn't need a full MVC framework, and being a rails guy, I'm not sure what to use now.
To give you a gist of the necessary functionality; this website will display static pages, but users will be able to log in and 'edit their current plans'. All purchasing and credit card editing is being handled by a recurring payment subscriber, I just need a page to edit their current plan. All of that will be done through (dynamic) XML API calls, so no database is necessary.
Should I stick with my typical rails/nginx stack, or is there something I could use that would lighten the load, since I don't need the Rails heft. I'm familiar with python and PHP but would prefer not to go that route. Is Sinatra a good choice here?
tl;dr: What's a good way to quickly serve mostly static pages, preferably in Ruby, with some pages requiring dynamic XML rendering?
If you want to stick with Ruby, Sinatra would be fine, as would Rails Metal.
If you're feeling a bit adventurous and want to get some useful experience with the technology that rails uses you could try building a Rack application. It's a pretty simple API to be able to respond to generic HTTP queries, and from there you can quickly build static file handling and XML processing. It's also considerably faster to start up and serve pages than rails.
http://github.com/cloudhead/toto is an example of a decent Rack based application.
If you know Rails, then why not just stick with it? That way you can use all authentication features, etc. that you're used to without having to learn another platform and incur the implementation risks that that includes. If the application ever grows beyond what's expected you're already on a solid base.