Hi Keegan I'm working on *exactly this* at the moment with the team at Day8. While we don't have any public code to share at this time, feel free to contact me off-list and I can chat with you more about it.
On Wed, Oct 14, 2015 at 4:06 AM keegan myers <keeganmyers...@gmail.com> wrote: > I have been working on a project to transform an in house rails > application into a distributed SAAS solution. As with many rails apps it > began as a simple crud interface, but inevitably became unsuitably complex > and slow. At this point the application has almost become a feature > complete ERP system (albeit a specialized one). > > One of the primary requirements is that the system can return a constant > stream of relatively complex data based on dynamic user provided queries. > As such I replaced the current long polling implementation with web-sockets > (via Sente). My current database of choice is Rethinkdb, largely because of > its changefeed <https://rethinkdb.com/docs/changefeeds/javascript/> > feature. Change feeds can be used to notify the server when a table > changes. I would like to push the changes client side whenever they occur, > but I've encountered a number of issues attempting to do so. > > - When a user updates their query what is the best way to update the > changefeed? It seems the easiest route is to stop the change feed and start > a new one, but there may be a more efficient route. > - When should a changefeed be closed? > - Changefeeds using the clojure driver > <https://github.com/apa512/clj-rethinkdb> produce a map of core.async > channels what is the best way to store these channels? So far I've been > considering either keeping the resulting map in the user's session, > or serializing the map and placing it into an in memory db like Redis. > - While searching for solutions I also came across this link > <http://lucumr.pocoo.org/2012/8/5/stateless-and-proud/>, it a nutshell > it suggests using a micro-service architecture in which the stateful > components could be completely decoupled from the business logic, and they > would communicate via a messaging queue. But in may ways this feels like > an unnecessary amount of additional complexity. > > At this point in the project I can still change my tool set without a > considerable amount of lost productivity, so if anyone would like to > suggest alternative tools to simplify the issue I'm open to the idea. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Daniel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
