I have a Rails application that right now is pretty standard: Heroku/PostgreSQL backend, users go directly to my site to update data, there's no mobile app or anything. We're going to start licensing out the tech to other companies, so that different versions of the interface live on company1.mywebsite.com, company2.mywebsite.com, etc, where all of these interfaces share the same database.
I want some advice on how to go about building this. Do I create a separate Rails app for company1, company2, etc (with a lot of redundant code) and then set up each of them with API keys to query my master app, using its RESTful routes?
Any tutorials to point me to would be great as well.
I recommend you the book Service Oriented Design with Ruby and Rails, by Paul Dix. It has a lot of info about the kind of system that you want to build.
To answer your question:
Build an API server. It serves a JSON – for example – RESTful interface.
api.mydomain/client1/users.json
Build a frontend server. It consume the API service – using typhoeus for example – and serves the final pages. It uses a subdomain or domain name for identification of different clients.
client1.mydomain/users
We have a similar "platform".
What we did:
build a master API app (REST + Push)
build a core plugin for rails which has all the shared code
build a separate rails app for each client which has all the client specific code
We are using this setup for 3 years now and I'm pretty happy with it.
Related
In the process of building a SPA, we opted for a combination of Rails API and Ember-cli.
From what we understand, the architecture of the app will be the following:
Rails API will run the back-end of the app, as an API
Ember-cli will run the front-end of the app, as a front-end MV* framework
Data will be served by Rails API to Ember-cli with JSON
What does not seem really clear though, is what should be the development workflow?
In other words, should we:
Build the back-end (rails models, etc), then build the front-end and finally connect both?
Build everything at the same time, but one feature at a time?
Go with another option?
I would recommend building both at the same time, in separate apps (that way you can test your API as an actual API rather than just a backend), but in close proximity to one another. This way you can make sure both play nicely with each other and you're getting the results you actually need, plus if something that you do on one causes an error on the other the bug will become immediately apparent.
Let me know if this answers your question enough, I can clarify/ give additional examples from here if you'd like.
I am currently have a running site. However, I need to do some task to sync some data to my friend's site.
So that, I need another app for fetching data from my running app's DB and submit data to another site using a gem call mechanize.
My problem will be:
Do I need a whole Rails app to do the job? If not, what would be the best practice in my case?
Is there any easy way for accessing my running app's DB? For now, the only thing I know is AR.
Thanks
API
What you're looking for is an API -- a way to connect to a source of data & use that data in some other application:
In computer programming, an application programming interface (API)
specifies how some software components should interact with each other
APIs are actually very simple -- you have a series of endpoints which an application can connect to, pulling data, typically as JSON objects. As noted by Rajarshi Das, these endpoints will likely be based on the RESTful resource structure
Rails
Rails, by design, is very good at providing API's:
This Railscast shows how to use the rails-api gem to create a RESTful API that your other app can connect to
I have built two rails apps that need to communicate and send files between each other. For example one rails app would send a request to view a table in the other apps' database. The other app would then render json of that table and send it back. I would also like one app to send a text file stored in its public directory to the other app's public directory.
I have never done anything like this so I don't even know where to begin. Any help would be appreciated. Thanks!
You requirement is common for almost all the web apps irrespective of rails, Communicating with each other is required by most modern web apps. But there is a small understanding that you need to get hold on,
Web sites should not directly access each others internal data (such as tables), (even if they are build by the same language (in this case Rails) by the same developer),
That is where the web-services comes in to play, So you should expose your data through web services so that not only rails application can consume that, but also any app that knows how to consume a web service will get benefit.
Coming back to your question with Rails, rails supports REST web services out of the box, So do some googling about web services, REST web services with rails
HTH
As a starting point, look at ActiveResource.
Railscast
docs
Message queuing systems such as RabbitMQ may be used to communicate things internally between different apps such as a "mailer" app and a main "hub" application.
Alternatively, you can use a shared connection to something like redis stick things onto a "queue" in one app and read them for processing from the other.
In recent Rails versions, it is rather easy to develop API only applications. In the Rails core master, there was even a special application type for these apps briefly (until it got yanked again). But it is still available as a plugin and probably one day becomes actually part of Rails core again. See http://blog.wyeworks.com/2012/4/20/rails-for-api-applications-rails-api-released for more information.
To actually develop and maintain the API of the backend service and make sure both backend and frontend have the same understanding of the resources, you can use ROAR which is great way to build great APIs.
Generally, you should fully define your backend application with an API. Trying to be clever and to skip some of the design steps will only bring you headaches in the long run...
Check out Morpheus. It lets you create RESTful services and use familiar ActiveRecord syntax in the client.
I think there is a wide consent that is a good practice to separate your REST API from your main website. The main reason is that you can scale your API and website independently of each other.
Additionally, Rails has a lot of middleware that is not required for stateless services (e.g. sessions, cookies, view rendering, etc...). Jeff Dean has a good write up on how to remove all of this middleware (http://pivotallabs.com/users/jdean/blog/articles/1419-building-a-fast-lightweight-rest-service-with-rails-3-).
At the moment, I am simply using the new Rails 3 responder (respond_with) in one single application, both for the website and the API. The website is used mainly for administration purposes.
How would you separate the API from the website?
I think an option would be to pack all models in a gem, then have two different applications, one lightweight REST service, and the administration website. They would be hosted on different Heroku instances, but access the same MongoHQ database.
You have 2 choice
extract your Model ans use it in all of your 2 application
made you API and your application on same application. But you deploy 2 server. One using only your application par and other with your API part. So if you need more API. add more on your API server.
You don't really need extract API. You just need separate it.
I am going to write a Ruby application that implements a video conversion workflow consisting of multiple audio and video encoding/processing steps.
The application interface has two core features:
queueing new videos
monitoring the progress for each video
The user can access these features using a website written in Ruby on Rails.
The challenge is this: I want make the workflow app a self-sufficient application, not dependent on the existence of the web view.
To enable this separation I think that adding a network API to the workflow application is a good solution because this allows the workflow app to reside on a different server than the web server.
My question is: Which solution do you suggest for such a network API?
A few options are:
implement a simple TCP server and invent my own string based API
use some sort of REST api (I don't know if this is appropriate for this situation)
some sort of web-services solution (SOAP, XML-RPC)
another existing framework
Feel free to share your thoughts on this.
I would suggest two things:
First, use REST as your API. This allows you to write one core application with both a user interface and an API for outside applications to use.
Second, take a look at PandaStream. It's a Merb application that encodes videos from multiple formats into flash. It has a REST API, and there's even a Rails plugin so you can integrate it with your application. It might be a good example codebase, or even a replacement for the one you're trying to build.
Hope my answer helped,
Mike