I have a Clojure back-end that I want to put a Rails front-end to. How should I connect them, and how specifically do I do it?
Off the top of my head, there are two ways:
run Jruby on rails, in the same process as the clojure app
run normal Ruby on Rails, and connect it to the clojure backend through a message queue, web hooks, and through a joint DB.
Both seem to have disadvantages. In the former, it seems that running jruby will limit the gems we can reuse and otherwise cost us productivity when library authors have not made something perfectly compatible. In the latter, I imagine we'll miss out on code reuse - possibly having to implement the same thing twice in some cases - and that the more complicated interfaces (web hooks instead of just function calls for example) will cost us.
Finally, in the case of JRuby, it's unclear how to actually connect the two. Both come with management scripts: rake and leiningen, and specific repository layouts. I don't really how to start joining them together. Advise and war stories welcome.
I think if it were me, I'd definitely use message queues to communicate between those services—though JRuby really is a good choice on the front-end as well (I think most gems are fairly compatible at this point, even those with native extensions.) Ultimately, you can use elements of both approaches.
What you're talking about is a fairly typical SOA set up, and that's one of the great things about SOA—you can leverage different languages and platforms where they do best. Trying to use clojure within a jruby-on-rails setup is likely to lead to much pain and misery, and IIRC it'll taint some of the benefits of using clojure in the first place.
Unfortunately I don't have any war stories that precisely match up to what you're trying to do, but I'm in the middle of such an architecture right now and its working out great, using RabbitMQ to let MRI 1.9 talk to backend workers running JRuby. Not sure how you'd consume messages in clojure, but I imagine there's got to be docs on it somewhere, and you'll be able to maintain clean separation. If you were to run your front end on jruby, you can still share code between the jruby process and clojure backend without having to put them in the same process.
I haven't done anything yet with Clojure + JRuby, but I have tried out JRuby + Scala/Java.
Scala/Java side works as the service layer and JRuby on Rails sits on top of it. Both projects are managed separately: Scala/Java project is compiled via Maven into a JAR which is then added as a dependency to the Rails application.
This seems to work quite nicely and I guess Clojure would work even better, because Clojure collections implement the interfaces that JRuby consumes, in Scala I had to tweak the service layer interfaces.
Disclaimer: I haven't done this with Ruby, but have quite a bit of experience mixing Clojure and Java modules in the same application and it works pretty well.
If you can make it work, I'd strongly recommend going the JRuby route for the following reasons:
Less dependencies for deployment - you just need the JVM and your relevant jars/wars
You'll get better performance by using in-process communication than you will with queues etc.
Architecturally it will be simpler and easier to maintain
You'll get access to all the Java library ecosystem from JRuby - depending on your precise needs, this could easily make up for the gems you lose through compatibility issues
You'll be able to use the same classes and common libraries from both environments
As for project layouts, I expect the simplest approach will be to create two different projects, package one as a jar and include it as a library for the other.
Related
Up to now I've always used PHP with or without a framework but a month ago I decided to start something new: Ruby and Rails, I found them quite easy and similar to PHP and some PHP frameworks in how they works but using a simpler syntax and many other advantages.
Some days ago I started reading about Node.js, Node.js vs Rails, "why node.js is better"...
I'm a bit confused but my objective is to learn something modern that will not become obsolete in a few months so:
What are the main differences between Rails/Ruby and Node.js and a framework based on it like Express.js (except that one is written in JS and the other in Ruby)?
What are the main advantages/disadvantages of using Node.js and framework based on it instead of a Ruby based solution like Rails?
Thanks!
There aren't enough differences between Node.js and Rails for it to practically matter.
A lot of what Node.js can do can be pulled off in Rails with things like EventMachine and Pusher. So unless you are really familiar with Rails' limitations, and know you'll be pushing the boundaries, you'd be hard pressed to make something a seasoned Rails developer couldn't do.
Having built apps in Node and Express I can say that they alone aren't enough to make a sexy application. They can seem just as old and stale if you don't have an outstanding frontend UI to facilitate the backend possibilities. Instead of comparing backend servers, I think the real future of doing amazing things is in front-end JavaScript frameworks like Backbone.js that use Express/Rails/Node.js on the backend.
I have chosen to go in the direction of Backbone.js with Rails as my backend API server. Because it's so easy to rapidly create a very nice RESTful backend server in Rails. Rails also makes working with CoffeeScript and precompiling/organizing Backbone code a breeze. There are already decent Backbone.js gems out there for Rails.
The Rails core is also able to acknowledge and embrace the fact that frontend JS MVCs are logically a good next step, and they have been working to strengthen the bond between the two. For those same reasons they have also worked to make Rails an even better API server so that it can work with frontend JS easier. Node.js and Express aren't putting as much effort to coordinate with frontend JavaScript MVCs as the Rails community is.
Being good with a JavaScript frontend MVC and Rails as a backend makes you also great for both worlds in terms of getting a job. You will easily be able to hop onto a Node.js project and add value to that team with your superior frontend experience, and you can also roll with the punches on a Ruby on Rails team and add value to them as well.
As official Node.js website explains it:
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
On the other hand Ruby on Rails official website says:
Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.
Given this I guess that it is more appropriate to compare Ruby and Node.js, but even this is not quite right given that Ruby is programming language and Node.js is NOT. You could probably compare JavaScript with Ruby but I guess that is not what you meant to ask with this question :)
So, for me, key point in understanding what Node.js truly tries to accomplish is well described on Node.js about page. Key Node.js idea (for me) is described in this sentences:
Node is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library. In other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a blocking call like EventMachine::run(). In Node there is no such start-the-event-loop call. Node simply enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. This behavior is like browser javascript—the event loop is hidden from the user.
What this should enable you, is that you should be able to easily write highly concurrent programs without even thinking about concurrency using JavaScript syntax and callback functions as basic concurrent runnable units.
Your fear that either Rails or Node.js will be gone in a week is unfounded. Rails has a large community and will be around for a very long time even though currently (early 2012) it's getting a bit of hate thrown its way. Node.js is just getting started and has so much attention I don't think it will have any problems getting to the Rails level some day.
That said I've been evaluating Node.js and Rails as options for a project and the reasons I choose Node.js over Rails are:
"The Rails Way" - In my (admittedly limited) experience with Rails it really seems like you either do it the Rails way or you are going to be in for a world of pain. A big part of the Rails way is to use the ActiveRecord model. The advantage of this is that there are a lot of gems that work with your code happily because they know you'll be using ActiveRecord. The disadvantage is you are mixing your data access & model. I am not a fan of this idea so the Rails way for me still seems a bit.. off.
JavaScript is a key part of client side web development and the idea of using it on the client and server is interesting. I'm not super strong at JavaScript and I can't imagine a better way to get better then to have to use it everywhere.
My project has real time communication needs which while I'm sure can be done in Rails there seems to be quite a bit of positive mention on Nodes ability to handle this with socket.io being the front runner option.
At the end of the day no matter which you choose you will have a great time & learn a ton of new stuff that will change how you write code. If you're not on a big time crunch I'd recommend building a small project management tool in both and see which you prefer.
Either way.. Good Luck!
2 things - performance & productivity.
Performance (more details here)
(source: jslang.info)
Productivity (how fast you can build that app)
Ruby on Rails is specialized and highly productive tool for creating so called Web 1.0 and Web 2.0 applications (99% of internet sites are such apps). In my subjective judgement and experience in this area Rails about 2-4 times more productive than node.js or express.js.
For Web 3.0 apps (realtime things, client-side MVC, etc.) this isn't true, RoR doesn't keep its advantage there.
So choice depends on use case and priorities.
I know a lot more about Node.js than I do about Ruby. That being said, Ruby is much more widely adopted. It is currently a very hot skill to have in the work place. Some may argue with me on this but I think that Node.js is still "under development" and will be for a little bit longer. It has a lot of promise but just hasn't been adopted by many companies and projects yet.
I am writing an application where the webapp will be rails and it will allow a user to input rules/ruby-logic and save them to the database. Later on, Java will come along and grab these rules (if/else/elseif) and will execute them via jruby engine. I am wondering of the negatives and possible side-effects of this? And having two languages here?
I want to do rails front-end because the available plugins, and speed of development of webapps. For example, groovy doesnt have as many plugins and i believe that it's much slower in development.
Am I missing anything, or possible logic that may be hurtful in the future if I choose this solution?
In addition I think since ruby is dynamic it will be easier for the user to input rules via a 'ruby' syntax instead of another third-party library like bean shell.
I feel like most complex applications end up needing several languages eventually, usually interfacing through the DB as you're planning. I'm not sure what constraint leads to you Java on backend rather than ruby (guessing legacy or performance), but if that's a requirement then your plan sounds reasonable.
As far as negatives/side-effects, Jruby seems to lag a bit behind the latest ruby, but that's not generally a big deal as long as you match versions for the UI & backend. I can't think of anything that would be harmful in this off the top of my head, but the devil is always in the details ;-)
Background: I have a java library that is accessed by many developers - usually via java. However, a few devs hope to access this via a Ruby API. I am gravitating in the direction of Jruby in order to implement a Java-Ruby API.
Questions:
My main concern is that these developers will not be able to utilize the API in their current, Ruby on Rails development framework; but instead will have to operate within Jruby's rails environment. Is this going to be the case?
Perhaps I'm missing a connection between Jruby and Ruby on Rails. But it seems that you can either work in Rails, or work in Jruby's rails - are these technically two different development environments?
I would really appreciate any light someone could shed on this..
Edit: Forcing developers (actually clients to be more specific) to make large changes to their projects in order to accomodate for this API is not really an option. So, if their Rails apps would have to be converted to Jruby on Rails apps, then perhaps someone could offer yet another alternative for me (other than Jruby)?
First, I should mention that Ruby on Rails is simply Ruby code, and the same code can run in the JRuby environment (on the JVM) or the MRI (written in C) runtime.
However, only JRuby can load Java classes and use a Java API. Asking your clients to switch their deployment environment to JRuby may not be feasible, but if you can set up a service in Java that speaks XML or JSON then they will be able to easily use it from Rails.
You might find the answers to a similar question helpful. Depending on your application it may be possible to seamlessly port your RoR app to run on JRuby subject to the caveats noted in that answer. But you'd want to be sure that the benefits of doing so balanced the effort and potential risks.
Alternatively you might consider making these Java library facilities available to your MRI Rails app as an internal web service (which could be Rails or Sinatra or similar) built on JRuby. That's way you would decouple the elements and de-risk the project. If you subsequently were comfortable with that working you might then consider collapsing them back together, all under JRuby-on-Rails if that made sense.
UPDATE: Adding more detail at questioners request
As I'm not familiar with what your application or Java libraries do this will be somewhat abstract but I trust you can fill in the blanks to suit your needs.
It seems that full porting of your Rails apps to run on Jruby is not feasible. Fine. So one idea would be to expose your Java library as a web service (e.g. RESTful) to your RoR application. Let's call this thing JLS. In this case it would run as a Java or Jruby network service, listening for requests, call into the library and send back responses (general waving of hands here but you get the idea).
Depending on what your developers are more comfortable with you can create JLS in Java running a Servlet container maybe. Or you could develop JLS in Ruby, running on Jruby (binding to your Java library) and use a framework like Rails or Sinatra to implement it.
On the RoR side, assuming you've made JLS RESTful (and I don't know if that's even appropriate in your case), you can use the ActiveResource facility for communicating with JLS.
In summary the RoR app and JLS run in separate memory spaces (maybe even different hosts). Each can be developed somewhat independently (with RESTful interface agreement of course) and your RoR app does not need to be disrupted or put at risk.
This suggested option comes with tons of small print but I hope you get the general idea.
I'd like to know situations in which I should consider using a framework other than Rails.
Two things. First, Ruby is a relatively young language, and you may run into brick walls when trying to do slightly more esoteric things (like connect to non mainstream or older types of datasources). It also has poor GC, and no kernel threads, both of which are very important for a high performance platform. The main codebase (MRI) is quite hacky (lots of clever obfuscating programmer tricks like macros) and there are parts that are poorly written (gc and thread scheduling leap to mind). Again, it is a very young platform that got very popular very fast.
Secondly, while ruby the language and rails the ideas/paradigm are both phenomenal, ruby and rails the platforms are not. There is a hell of alot in both ruby and rails that is downright ugly, and deployment solutions are in the dark ages compared to what is considered normal for other platforms (php/asp/jsp).
Being accused of trolling here, so I will expound a bit. Due to the threading model, Rails cannot process requests concurrently unless you launch multiple full instances of your rails app. To do that you have two options, the relatively young and still under development passenger (mod_rails), or the tried and tested apache load balancer with multiple mongrel instances behind it.
Either way, the lack of the ability to just just spawn workers means you will want 5-10 full instances of your application running, which incurs a very large overhead (can easily be 300-500megs per app depending on your gems and how big your app is). Because of that, the infrastructure needed to serve rails is a hell of alot more complecated then most other things.
Now, that being said, the situation has been continuously getting better (I mean, passenger is usable now, it wasn't the last time I had to deal with deploying a rails app). I would be very surprised if rails doesn't catch up in the next few years.
Also, rubinius/jruby are doing things the right way, and are moving along at a great pace. I wouldn't be suprised if MRI gets dropped in the next few years in favor of one of those implementations for mainstream rails work.
Ruby on Rails isn't trying to be an end-all be-all web development framework. If you're going to build an application that is predominantly built using CRUD operations, you want to use a lot of AJAX, and you have total control over the database, then Ruby on Rails is one of a few excellent options. If you're doing something else, then there is a probably another framework that is a better match for your requirements.
edit: Matt amended his answer tastefully :) I've removed my own comments pointing out the things he's fixed.
Yes, Ruby definitely has some shortcomings. Green threads being a huge one. But as Matt has said, things are moving along in better directions.
The other posts are pretty much on the money. Decently simple CRUD apps are best suited for rails, though there are other frameworks you can try in Ruby that offer more flexibility.
Here's a great (and might I add objective) example of where not to use rails: Does the Rails ORM limit the ability to perform aggregations?
Wow, way to start a flamewar!
I'm going to start it off by saying that Rails will work for most apps. However, if you need to do a lot of async type work (like messaging between systems, such as getting a request, placing it in a queue and processing it in a different thread, or even on another machine), Rails is probably not your best choice. Ruby, at least at the current time, is not really strong on multithreaded code.
Let the insults fly!
I'm wondering if it's possible to distribute a RoR app for production use without source code? I've seen this post on SO, but my situation is a little different. This would be an app administered by people with some clue, so I'm cool with still requiring an Apache/Mongrel/MySQL setup on the customer end. All I really want is for the source to be protected. Encoding seems a popular way to go for distributing PHP apps (eg: Helpspot).
I've found these potential solutions:
Zenobfuscate - not all types of Ruby code is supported however, so that counts that out
Ruby Encoder - may be the best option, as their PHP encoder looks alright (I haven't tried it however) but it's not available yet. I've used IONcube for PHP before and it worked well, but it doesn't seem that IONcube is interested yet.
Slingshot - it was mentioned in the other SO post, but it solves a different problem to mine and the source is still visible.
RubyScript2Exe - from the doco, it's not production ready, so that counts that out.
I've heard that potentially using JRuby and distributing bytecode might be a way to achieve this, but I've never used JRuby so I'm not sure what's involved.
Can anyone offer any ideas and/or known examples? Ideally I'd love to have some kind of automated build scenario as well.
Your best option right now is to use JRuby. A little bit of background: My company (BitRock) works with many proprietary and commercial open source vendors. We help them package their server software, which is typically based on PHP, Java or Ruby together with a web server or application server (Apache, Tomcat), the language runtime and a database (typically Postgres, MySQL) into a self-contained, easy to use installer. We have a large number of PHP-based customers (including HelpSpot, which you mention) but also several Rails-based ones. In the case of the RoR customers the norm is to use JRuby together with Tomcat or Glassfish although in some cases we also bundle a native Ruby interpreter to run specific scripts that rely on libraries not yet ported to JRuby (usually not core to the application). JRuby has matured quickly and in many cases it actually runs their code faster than regular Ruby. You will need to also consider that although porting your code to JRuby is fairly straightforward, you will need to invest some time on that. You may want to check JRuby Stack which is a free installer of everything you need to get started. Good luck!
If you release the source, obfuscated or otherwise, your app will be pirated. See, for example, Mint. It depends on what you're building, but you may find that you're better off releasing the app as a hybrid of sorts: A hosted app with a well-defined API, and a component that runs on the customer's server. As long as the true value of your product lives on the server side, you don't need to obfuscate your code, and you can just release the source code unmodified. Additionally, this may also give you the opportunity to reach clients running, say, PHP rather than Ruby. See, for example, Google Analytics, HopToad, Scout, etc, etc.
You can, but it wouldn't do anything to prevent somebody from reverse-engineering or modifying it. I remember there was an article about similar attempts to obfusticate Perl and how they could be effectively bypassed by a debugger and 5 minutes of effort.
If you can't wait for the delivery of RubyEncoder, then I think ZenObfuscate is the most promising. Though it may require some modifications to your source code, they do say this on their site:
ZenObfuscate costs $2500 for a site license or is individually negotiable for other licensing schemes. Yes, that is expensive. That was on purpose. But don't let that thwart you too much. If your product is really cool and we want to see it succeed, we'll make it work. "Really cool" is not freecell.
Of course, for $2500 (or more), you'd hope to get a few tweaks to the compiler that'd make your codebase fully supported. It might be worth engaging them in the conversation.
You can also take a look at Mingle from ThoughtWorks studios as an example of using JRuby for this.
It's a Ruby on Rails app, they run it using JRuby. They've customized jruby to load encrypted .rb files.
Take a look at JumpBox.
I've had conversations with them on the topic, and they seem to have a solution that will work soon for Rails apps.
I'm wondering if you could just "compile" the ruby code into an executable using something like RubyScript2Exe ?
To be honest I haven't used it but it seems like it could be what you want, even if it just packages up the scripts with the interpreter into a single executable.