I'm looking at Rails development as a backend to a Flex application and am trying to figure out the communication layer between the Rails app and the Flash Player. All of the things I am finding suggest using SOAP web services to communicate.
However, Flash supports AMF which is nice and fast (and native). Is there any way of communicating over AMF from a Rails app, whilst supporting all the "nice" things about AMF (automatic type conversion, data push etc).
There is WebORB or RubyAMF which you can use to respond in AMF from Rails, the approaches are a bit different for each one so it depends on your needs. RubyAMF is discussed in the closing chapters of the Flexible Rails eBook which is a good resource on using Rails with Flex.
I'm in the middle of writing a rails/flex application and we're moving to using a JSON communication within the REST framework. Simple HTTP requests from the Flex side handling JSON responses seemed like the best way to decouple the client and server. XML is just as easy.
For what it's worth, we're using the PureMVC framework on the flex side as well, keeping the responses in a client-side model.
You wouldn't use SOAP web services but rather 'native' REST web services, which are native in Rails. The book quoted by DEFusion above is actually about that: how to use a FLEX client as the front-end of a Rails application using REST (meaning XML).
The AMF protocol has primarily been built by Adobe as a binary protocol to allow FLEX front-ends to talk to CodeFusion and of course Java server applications. It's not free, apart from using Adobe's BlazeDS for which you actually won't have much support. And then of course, you'll have to choose a plugin capable of talking to BlazeDS using the AMF protocol (again, see DEfusion's posts) and rely on it.
You'd be surprised how well direct Flex to Rails via REST works, plus you don't have to rely on third-parties. I'd recommend you try it.
Hope this helps
Go with RubyAMF if you want an MVC style interaction with contollers that can respond to/generate AMF.
Use WebOrb for any other style, including direct access to model objects.
I've built apps using all three methods (WebOrb, RubyAMF, REST)...
WebOrb for Rails is pretty much dead, it hasn't been updated in quite sometime. That said I was able to create a bit of Flex/Ruby magic that makes Flex access to Rails' model objects transparent... if you're interested I'll dig it up and send it to you.
RubyAMF is nice, but not as Flexible (ha!) as WebOrb.
REST returning JSON is a snap, and if I have to build another one of these (I hope not) that's what I'll continue to use.
YMMV.
There's a Rails plugin called WebORB for Ruby on Rails which uses remoting with AMF.
You can use WebORB or RubyAMF, or just plain XML - Rails is pretty smart when it comes to XML, with a few gotchas here and there.
We use XML to speak between our Rails apps and our Flex web application, almost exclusively. It's pretty simple.
For retrieving data from your Rails app, just create an HTTPService with result_type of e4x, and call your url. In your rails controller, do something like:
def people
render :xml => Person.all.to_xml
end
Sometimes, Rails will add the tag to the end. If this happens, change your controller to:
def people
render :xml => Person.all.to_xml.target!
end
If you want to send data to your Rails app, it's just as easy..
<mx:HTTPService id="theservice" url="http://localhost:3000/svc/add_person" method="POST">
<mx:request>
<person>
<first>Firstname</first>
<last>Lastname</last>
</person>
</request>
</HTTPService>
and in your controller:
def add_person
p=Person.create(params[:person])
render :xml => {:result => "Success"}.to_xml.target!
end
Kevin
Related
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 want to try to make a simple real-time chat Rails web app, but I thought I would need some kind of let's call it "event listener" to be able to keep track of sent messages so the receiver user's feed get updated with the new message. Also, for the Typing... notice box.
I hope I explained myself.
I guess I could do it in a very troglodyte way to achieve this like follows:
main.js:
while(true) {
$.get('/user-you-are-talking-to/are-there-new-messages', function(data) {
if (data['are_there_new_messages'] === true) {
$('#conversation').append(data['new_message']);
}
});
}
conversation_controller.rb:
# routed by /user-you-are-talking-to/are-there-new-messages'
def new_messages?
unless #new_messages.blank?
#json = []
#json[:are_there_new_messages] = #new_messages.count > 0
#json[:new_message]= #new_messages.shift
render json: #json
end
end
But well aside than the fact that I didn't test that code, a while loop and constant requests to the server seem like a really really bad idea, obviously.
I would like to know if Rails has a built-in feature like this, but as far as I know it doesn't, unlike frameworks I've worked with like Laravel. If there's not a built-in tool for this, how can I do this app?
Real time apps are usually done with websockets.
https://github.com/eventmachine/eventmachine
https://github.com/igrigorik/em-websocket
Or if on a hosted service you can use a publish/subscribe service such as Pusher or PubNub.
Otherwise, you would do polling which is what you have in your example.
Rails 5 will come with Action Cable:
Action Cable seamlessly integrates websockets with the rest of your Rails application. It allows for real-time features to be written in Ruby in the same style and form as the rest of your Rails application, while still being performant and scalable. It's a full-stack offering that provides both a client-side JavaScript framework and a server-side Ruby framework. You have access to your full domain model written with ActiveRecord or your ORM of choice.
But while you're waiting for it, you can use a number of existing solutions, some of which #dinomix listed.
Another option is Faye (never used, but heard good things).
In the process of learning Rails, I read about how we could combine it with some front-end MV* JavaScript frameworks — such as Backbone.js, Angular.js, or Ember.js — to improve the UX.
This introduced (to me) the concept of using Rails as an API, instead of a web app.
So, now, I am pretty confused: what is the difference between a regular Rails app and a Rails API?
According to the official rails website, there are three main differences between a rails web application and a rails api:
1 - The api app is configured to start with a more limited set of middlewares than normal. Specifically, it will not include any middleware primarily useful for browser applications (like cookies support) by default
2 - In the api app, ApplicationController inherits from ActionController::API instead of ActionController::Base. As with middlewares, this will leave out any Action Controller modules that provide functionalities primarily used by browser applications.
3 - The api app is configures the generators to skip generating views, helpers and assets when you generate a new resource.
You can always convert your rails app from either one of these to the other one. To do so, follow the steps in the reference I mentioned above.
A regular Rails app will use the rails views (erb or haml) to render pages directly. That is to say, it will process the data AND render this data in views, answering directly the client request with a HTML page.
A Rails API will just process your action, and assume someone else is doing the job of rendering the view for the client. Therefore, a Rails API is expected to return data in an appropriate format, like JSON, XML, or just a JS piece of code to execute. It is then the job of frontend frameworks like AngularJS to receive, parse, and do something with the data (like update some HTML, etc.)
In a nutshell,
Classic Rails application are all-in-one applications, where the processing and rendering are both handled by Rails. The apps may lack or responsiveness however, as full pages are rendered, but it's usually much faster to code this way.
Rails API are just serving intermediate results. It will focus on just delivering the data. This can be better if you have strong requirements for the design/responsiveness, as you are more flexible with the frontend libraries you can use. Usually only the data is transferred, so in addition it can be faster. There are some problems with APIs. For example with one-page apps + full AJAX, it may be harder to set up a forward/back behavior on the user browser. Also, using APIs will require more work, but if you have many devs, you can agree on the interfaces, and parallelize the work server/frontend.
Now, it's not a black or white answer I'm giving. You can totally have a Rails app mainly built as a Web app, but with some API actions that give more responsiveness to some pages. An exemple of this, is to have an autocomplete form, that is pulling the data via AJAX calls.
I found a pretty clear answer in Yoni Weisbrod's Rails API Mini Guide:
The fundamental difference between an API and a regular Rails app is
that an API returns data for further processing, rather than data that
is meant to be viewed directly. Therefore, rather than producing an
HTML document (with CSS and/or Javascript) that looks pretty, APIs
produce simple information structures that can be further processed by
whatever will be consuming our API.
I am a rails developer working on a cakephp site. The more work they send me, the more php code I write and thus the more dependence on php we introduce. What I want is to stop writing new features in php and start writing them in rails. Our resources are limited and the existing php site is huge so a full port from cake to rails is not possible.
Is there some way to write new features in a rails app while maintaining and allowing access to all the functionality of the old php (and vice-versa)?
It seems I would need a route aware app to traffic requests to either php or rails, but then we run into the issue of, for example, existing user functionality written in php not being available to the rails app and vice-versa.
What about something to translate ruby into php? That way I could start writing my model stuff in ruby/rails rather than php.
I feel like my question is muddled by the fact I do not know how to ask the questions I want to answer, so hopefully this is understood.
As always, thanks in advance!
One approach that you may find useful is to leverage the power of your web-server to properly re-write and delegate requests to two different systems. If you can design your new Rails application to use the same database records as the old one, with models mapping to the old tables directly, and ensuring that sessions established by one are valid in the other, you have a lot of latitude in how you go about doing this.
Apache has a very full-featured URL rewriting and proxying system that can be configured to direct "legacy" parts of your site to an existing set of PHP scripts while directing all other traffic to the new Rails application. You will need to be careful to ensure the design of both applications are nearly identical or it may seem strange to users.
Another approach that helps ensure a consistent appearance is to strip out a lot of the theme from your PHP application. By creating very bare-bones pages that only expose the required functionality on each page, Rails can fetch these by passing through any relevant session authentication information and re-frame them in the right layout.
This way you can preserve existing functionality and have it embedded inside your new application. You can use something as simple as open-uri or the curb gem to handle this HTTP-level delegation.
You would end up with controllers that look like this:
class PaymentController < ApplicationController
def index
#content = fetch_legacy_url('/payments/index.php'))
end
end
The fetch_legacy_url method would create an HTTP fetch request that includes the required headers, cookies, and so forth, and return the response body. Your view then ends up looking something like this:
<%= #content =>
From there you can shunt parts of the PHP layout over to the Rails app piece by piece. For instance, ripping out large chunks of static HTML and putting them in the Rails template would reduce the amount of actual PHP code you have to port.
It's a bit messy to maintain two applications in parallel, but as you point out the alternative is to keep accumulating technical debt and making the inevitable re-write that much more significant an undertaking.
The first step would be to experiment and see if you can create a Rails environment that uses your existing data, or at least the data relevant to the new functionality you intend to build out.
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.