I'm having an implementation challenge at the moment, it basically consists of two different rails apps.
One rails app (app A) just provides a response in JSON, a record in this case for the nutrition data for one particular food ingredient.
The other app (app B) also Rails provides a front-end for users to view ingredients and match them up with search results provided by app A.
The reason we did this is because we want to eventually make app A into a publicly accessible API for nutrition data, so we figured to take the load off the web App B we could make it stand alone.
I guess I wanted to get the thoughts of you guys on generally how you would handle two systems that need to be tightly integrated in this way.
I would create a new Rails 3 application because Rails 3 is tightly integrated with Rack. Rack allows us to insert various adapters in the request processing chain. Those can help us to differentiate between requests of various kinds (standard requests, API requests).
For the application A I would use something lightweight, like Sinatra (or even my own Rack adapter built from scratch). This is due to the fact that API generally will not use any extra super features of Rails and its magic.
So, strictly speaking, I will create only one application (the application B) on Rails 3 that will have a kind of submodule for the API processing. Thus, they will be binded with each other.
Whether App B is an internal application or external, it's the responsibility of App A to expose the nutrition data. That's something you don't want to duplicate.
The internal App B should use the same mechanism as external applications to access this exposed function. Think of App B as the first client that uses the API.
Related
I really like Ruby on Rails but I have also developed in node js. Currently I'm making a web app which has chat functionality that could have 30 people in it. For that I want to use node js.
I have never done this, I'm confused on how's traffic divided between app. How is the state shared between apps for example how would I share the user session will I have to hit the database for every request.
My first recommendation is to not split a web app between two separate server platforms. It overly complicates the project and isn't necessary at all.
That being said, if it must be done, you could use one of the platforms as the 'main' one and the other one for API endpoints stationed at localhost:some-port-number. This way, if you were in the main platform (Rails let's say), you could request data via the node.js API by redirecting it to whatever IP address (make it a local IP) that node is running on.
Again, I recommend against this. But that's one solution if it must be done.
I'm building an API that's intended to be consumed by an iOS app as well as a browser-based Web Application (using React / AngularJS). The API is being developed in Laravel.
What is the best way to structure this? Should the API and the Web Application be apart of the same Laravel Application, or should the API be an entirely separate entity that just returns JSON to whatever client requests it? In that case, I suppose my Web Application would interact with the API as though it were a 3rd party API
We we've had a grown monolithic application and decided to split the code up, into repositories called "core", "frontend" and, new to our family, added "api".
That is, we are using the Microservice pattern and it works well for "us".
Our core/frontend repositories are CakePHP but the API is written in Laravel 5 using the jsonapi 1.0 spec.
We're quite, if not to say, very happy with this approach. The only canonical thing it the representation in the database. Business logic and code is redundant. But an interesting lesson learned is that we uncovered quite some bugs due this in the existing code base.
The clean separation is important to not be bound too much to one technology. We may want to replace the "frontend" stack with a node application talking to the API. We may want to replace the API with something else later.
Of course this comes with huge amount of work, resources, etc. but not being able to act due a monolith is worse in our view.
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 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.
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.