I would like to be able to make a request to a ruby method on a rails app after calling a long-running request that would run in parallel to the request. I know that using a background processing gem would make this possible, however is there a dev server that handles more than one request?
Related
I need to create an API for my rails project, and the API main purpose is to start actions that will run in background for some time (using ActiveJob).
I need the API client to be able to monitor the background job using long-polling. The client makes the request and if the job is still running, the request waits until some timeout to give the result, or returns earlier in casethe job has terminated in the meantime.
If I ware to design a full-stack application, I'd use ActionCable to notify the client when the job terminates. But here, I don't want to make public any ActionCable websocket API and I want to stick with plain HTTP.
Is it possible to use ActionCable to wait for messages on a channel in a Rails controller (server-side)? Can such controller cause a connection count limit, especially with postgresql connections (which I won't be using while I'm waiting on Redis for ActionCable messages)?
I am building a pool of PhantomJS instances, and I am trying to make it so that each instance is autonomous (it fetches next job to be done).
My concern is to choose between these two:
Right now I have a Rails app that can give to PhantomJS which URL needs to be parsed next. So, I could do an HTTP get call from PhantomJS to my Rails app and Rails would respond with a URL that is pending to be done (most likely Rails would get that from a queue).
I am thinking on building a stand alone Redis server that PhantomJS would access via Webdis, so Rails would push the jobs there, and PhantomJS instances would fetch from it directly.
I am trying to think what would be the correct decision in terms of performance: PhantomJS hitting the Rails server (so Rails needs to get the job from the queue and send it to PhantomJS), or just making PhantomJS to access a Redis server directly.
Maybe I need more info but why isn't the performance answer obvious? Phantom JS hitting the Redis server directly means less stuff to go through.
I'd consider developing whatever is easier to maintain. What's the ballpark req/minute? What sort of company (how funded / resource-strapped are you)?
There's also more OOTB solutions like IronMQ that may ease the pain
The gem named Delayed Job (https://github.com/collectiveidea/delayed_job) can do many things in background. But can it run a Rails controller in background so that it still will respond to HTTP requests and return results?
No, this would require Delayed Job to spin up a server. This does not work because a server is already running with your App.
What exactly are you trying to archive? If you have your Rails app running, it will be able to respond to HTTP requests that might come.
If I run rails server in production environment by rails server -e production, rails runs as a single-threaded application.
So will it respond to one HTTP request at a time or more requests at a time?
It depend on which server you are using to run rails application .
For instance if you are using Webrick server (which is single threaded by default)then you will handle one request at a time but if you use passenger server then it will create instances of your application (which is configurable), then you can handle multiple request at a time
Since it is single-threaded so one request can only enter the action after the previous requests finish. But it can respond to multiple requests at a time.
Consider a Rails app that hits a (Sinatra app) API being developed separately from the Rails app. I want to test an API call from within the Rails tests.
The API code:
post '/foo/create' do
...
I created a mock, but that doesn't make sense because it is just a copy of the API file. That stinks.
It is possible to require the API file in the test. But how to call it from RSpec? There is no route in the Rails app for it.
One option is to start the API and make the HTTP call from the Rails test, but this is smelly because:
You have to start the API server to run the Rails tests
Why should a Rails test make a HTTP request? Rack::Test simulates this.
I don't think this will work because the apps have different test databases, but share the same production database.
EDIT: The point of the test is that the API call creates records that the Rails app is expecting. So the Rails app needs to test the state of the database after the API call is made.
Well. The perfect answer for you is a gem to mock the answer like webmock. It will fake a response when acessing that url, so on the test your app will make the requisition as it was for real, only that before it hits the web, it will hit your mock and respond with the desired answer.