Quick question concerning shared code/logic in back and front ends of a web application.

I have a web application (Rails + heavy JS) that parses metadata from HTML pages fetched via a user supplied URL (think Pinterest or Instapaper). Currently this processing takes place exclusively on the client-side. The code that fetches the URL and parses the DOM is in a fairly large set of JS scripts in our Rails app.

Occasionally want to do this processing on the server-side of the app. For example, what if a user supplied a URL but they have JS disabled or have a non-standard compliant browser, etc. Ideally I'd like to be able to process these URLS in Ruby on the back-end (in asynchronous background jobs perhaps) using the same logic that our JS parsers use WITHOUT porting the JS to Ruby.

I've looked at systems that allow you to execute JS scripts in the backend like execjs as well as Ruby-to-Javascript compilers like OpalRB that would hopefully allow "write-once, execute many", but I'm not sure that either is the right decision.

Whats the best way to avoid business logic duplication for apps that need to do both client-side and server-side processing of similar data?

  • 2
    Worth mentioning, this is one of the bigger selling points of nodejs. I've really enjoyed sharing code between the client and the server. You might want to run a nodejs process and calling it from rails - that'd be pretty simple, you'd always have updated and fast JavaScript (V8) and it'd work pretty easily. Jun 24, 2013 at 15:45

3 Answers 3


Trying to interpret one language into another is going to add too much complexity for not enough benefit.

If the amount of logic is small, just duplicate it on the client side using Javascript.

If the logic is extensive, and your architecture allows it, create a layer of REST services in Ruby that you can call using AJAX.


In general, I'd say either using Node, ExecJS or the like would be the way to accomplish this - I'm wary of any cross-compilers like that.

That being said, I wonder why the client-side parsing is important in this particular case. You're going to need some API to do cross-domain requests anyway (ahem jsonp.jit.su), so why not just have it do the parsing as well, and just give you some structured JSON that you can work with on either end?

  • Your answer would be stronger if you explained a bit more about the problems you have had with cross-compilers.
    – user53019
    Jun 24, 2013 at 17:07
  • Aidan, the client-side parsing is initiated by a bookmarklet that chews through the current pages DOM (exactly how the Pinterest and ReadLater bookmarklets work), which works 95% of the time. I want a solution that allows reusing the existing code on the backend to do the same process "on demand" Jun 24, 2013 at 17:21

Whats the best way to avoid business logic duplication for apps that need to do both client-side and server-side processing of similar data?

Yes, this is possible. I've used node.js on the server, and this is why I tell everyone to use it. It will come a day you need your client side stuff on the server and viceversa... Currently I thing twice before adding something only to the server side part of the app.

I use the require.js module system on both of the client and server side.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.