I have a WordPress site and a Rails site hosted on separate servers. I need to pull information from some custom post types on the WordPress site and display them on the Rails app. At a minimum, I would like to display all the post titles (hyper-linked) – there's no writing to WordPress needed.
I'm not well-versed in Ruby on Rails or HAML – I'm basically just a WordPress/PHP developer – so I'm at a loss as to how to begin. I'm thinking the best way is to pull data from WordPress using the WP REST API (http://v2.wp-api.org) plugin, but I don't know how to go about rendering data from an API in RoR/HAML. If you could point me in the right direction, that would be awesome!
Yep exposing an API on the WordPress side would be a good option, you're on the right lines.
In this situation you could do is start by creating a controller, route and view (hopefully some tests too) then within the controller you can request the data from the WordPress API. For this you will need a HTTP client, Net::HTTP is part of the Ruby stdlib or alternatively something like faraday which offers a little more flexibility. From here you can pass the response data into an object that you can use in your HAML views as required. You don't want to be assigning the JSON to an instance variable in your controller and accessing it as a Hash in the view, create a class that parses the response and provides some methods to allow you to access the data using method calls.
This would get you going in terms of a basic implementation but once you get the basics working it may be worth doing a little refactoring. For example what you would have now is a small wrapper around the API and this could be a logic extraction from your controller. The advantage being that the controller code becomes easier to understand and also should you wish to use the wrapper somewhere else within your application that becomes much simpler.
Edit: You could also use a REST ORM like her
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.
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 fairly new to web application development and I have a pretty noob question. As I understand, it is possible to write the backend of a web application - models, business logic, etc. using Rails and write the backend - the view - using just HTML, CSS Javascript (without using Rail's form helpers, embedded ruby, etc.) and that the said view would render data exposing a Rails API and making AJAX requests to it. Everytime I googled "rails ajax requests API" I have only found tutorials that explain how to use AJAX w/ embedded ruby instead of tutorials that clearly separate how to make a Rails API and make AJAX requests to render data. So my questions are:
1) If any of the above statements are incorrect, could you let me know?
2) Can someone point me to tutorials that help me understand the theory and implementation of the aforementioned topics?
Thanks!
The REST API generated by Rails can be consume by any client, if you want to use pure HTML and CSS withouth the .erb files (for me brings many advantages when developing) you can access to the Rails API data by AJAX.
I let you the following tutorial:
http://blog.project-sierra.de/archives/1788
Hope it helps
I was reading through the RABL git https://github.com/nesquena/rabl and I quickly came across this line. Can someone quickly explain what he means by "generating APIs"?
When using the ActiveRecord 'to_json' method, I tend to quickly find myself wanting a more expressive and powerful solution for generating APIs.
From my understanding an API is a set of classes / methods that may be used to interact with the content of the API creators material. With that definition, I believe he is saying that he wants to be able to interact easier with the API so he build RABL which allows for the content to be translated from his application to, in this case, Rails eaiser?
In this case, API is applied to the system as a whole. So your entire website might have an API that your customers would use to pull/send data to your system.
Mostly, these are JSON/XML endpoints that accept and return data. Rabl (and other serializers like it), help you craft custom JSON responses.
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.