So, i currently have a pretty big monolithic rails app. I want to split the app up into separate micro-service APIs, with a main app as the gateway. I've been reading a lot about how to do this and think i understand, however there isn't much info on how the communication between the main app and the micro-services. I understand that i can do this in a variety of ways but i want to use HTTP.
Can someone provide an example of how this setup might look and how the communication works (in code) between the main app and the micro-service?
Thanks
For APIs in Rails, see http://edgeguides.rubyonrails.org/api_app.html. I suggest to use a RESTful API, because REST uses the normal HTTP verbs and fits well to the Rails philosophy, see e.g. https://www.airpair.com/ruby-on-rails/posts/building-a-restful-api-in-a-rails-application
Related
I am new on this gurus, as titled, please advise, which solution out there is more popular and/or adopt by the marketplace better?
I would write a small application in Node.js. It's super lightweight and handles JSON natively which has been the norm. Pretty well suited for RESTful development.
There's a library that makes RESTful development a breeze called node-restify. Their documentation is straight forward and will walk you through writing the most basic web service in a few lines of code.
If you've never used Node.js before it's easy to try out. Comes with an installer for OS X, https://nodejs.org/.
We have a Rails app that acts HTTP API only. On the client side, Ember.js is currently used. We are not overly impressed by Ember and really like the approach Meteor.js takes. So we'd like to exchange the client side with Meteor.js and communicate with the Rails server via websockets that speak the Data Distribution Protocol (DDP), so we can keep using the models, mailers and controllers in Rails. Implementing server side of DDP should be easy.
However, we're unsure how to make Rails talk websockets. We found Reel, which seems to make it easy to accept websocket requests in a standalone environment. Reel seems great as we'd like to implement the DDP on top of the Celluloid stack anyway. But what about running Reel in the Rails environment? Would we need "rails runner" for that? And we'd like to keep using the existing controllers to dispatch incoming requests (like, to add/change/remove resources). Is that even possible without having the request coming through Rack?
Any input is appreciated.
It's a bit late, but I've implemented DDP in Ruby, you can check it out here:
https://github.com/d-snp/ruby-ddp-server
It includes an implementation of EJSON as well. It's built on top of celluloid-websocket, and can be ran simply as a rack app.
I've made an integration with RethinkDB that can be used as a reference to build your own collections implementation.
https://github.com/d-snp/ruby-ddp-server-rethinkdb
I've also made a sample chat application that can be found here:
https://github.com/d-snp/celluloid-rethinkdb-chat
It's something that I have been longing to do as well, to integrate old "legacy" Rails code. Here is the best way I have found:
Since you would not be using any of Rails router/controller/views, but just the ability to read data and push it to the client, I recommend you use Rails to create JSON apis to the database, and deploy the code, then in Meteor you can consume the data via the http package, this would happen on the server at a regular interval and populate the MongoDB with the normalized data you need, then it would serve the browser client.
I am working on such an application that will keep a normalized version of the data in Mongo, and a relational version of the data in mySql (through Rails) this way I can preserve the legacy Rails functionality that I dont want to rewrite in JS, and get the benefit of Meteor for the one page that I need it most.
I have a database on a database server. No web service in place to be consumed by a web application.
If I want my iOS app to communicate with a database server (send & receive data), I know I can create a web service and then call that service from my iOS app. But what web service is recommended for this? Should I just write a .asmx web service in .NET or should I go for MVC WEB API or may be go for WCF ?? I have spend hours doing research on this. Please help.
A lot will depend on where you expect the service to be hosted, and what technology stack(s) are supported by the host. If you are self-hosting, then do whatever works in the technologies you know and understand. If you want to use a host that targets its services to small-to-midsize independent development teams, many providers like Heroku support things like Rails services. PHP is always an option as well. Microsoft-based solutions and Java-based solutions tend to be more widely used in larger enterprises and data centers, and if that's where you'll host your service then these would also be good options. And of course I'm speaking in broad generalities here: For any general trends I might list here there are lots of exceptions where other approaches make sense.
If you'd rather let the decision be driven by what makes things easiest for your iOS code, I would recommend you start with server-side technologies that support REST-ful interfaces using JSON to represent your service's resources. REST-ful services are very easy to consume from iOS, and JSON-based representations of resources are very easy to parse and produce in Objective-C.
I am personally used this approach to set a direction for my app. For the service side, I am going with a Rails implementation of REST-ful web services. I'm a Java developer by profession, but for a small independent project the options for hosting Java services were more limiting than with Rails so I've picked up rails on the side to make my project work. So far it's suited my project quite well.
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 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