ruby on rails - Share data between ActiveJob and Controller -
every n seconds application requesting remote json file provides live prices securities in trading system. json has block data need (marketdata
) , block current dataversion
(version
, seqnum
).
right use actioncontroller::live
(with eventsource
on client side) push updated data browser. actions done within 1 method:
- opening sse connection;
- forming dynamic url;
- pulling new data remote server;
- comparing/reassigning
seqnum
value; - updating database if needed.
so goal separate pulling & updating database (activejob
) pushing updated values browser (actioncontroller::live
). accomplish need:
- either store somewhere on server side
seqnum
&version
share between controller , background job; - or monitor databases latest changes in
updated_at
fields.
so have 2 questions:
- what more efficient between 2 options above?are there other approaches?
- (in case first 1 has right exist) how implement approach?
considering fact might have, example, multiple rails process running, believe becomes quite hard let activejob talk directly rails controller in way.
defintely store seqnum
, version
, wouldn't rely on updated_at
in case, it's easy updated randomly , end sending stuff client without real reason. in case seem solid fields point out if file has been updated.
with polling
that being said, want "signal" actioncontroller::live
in way , i'm afraid polling here option, unless on client side there specific moment when needs know if file has been updated, in case might want use websockets or similar.
so, like
cached_request = yourcachedrequest.latest # assuming returns single record updated = true loop if updated updated = false response.stream.write cached_request.serialize_in_some_way end current_version = cached_request.version # use seqnum if need cached_request = cached_request.reload updated = true if cached_request.version > current_version sleep 20.0 end
without polling
if want option doesn't involve polling, can go websockets believe. have more efficient option:
create mini application (evenmachine/sinatra/something light) clients poll (you can pass through main application distribute differente nodes of mini application), point of app reroute messages main application polling clients.
now, can create internal api endpoint main application it's used delayed job. delayed job hit endpoint when notices fetched json updated relative 1 stored. if that's case, hit main app api endpoint in turn send message (again, through http api endpoint, time on mini app) mini app instances, in turn send them clients.
in way, don't overload main server these mini-nodes can have localized outages (which big advantage, instead of having big system outage).
Comments
Post a Comment