Combine two apps into one? Engines?

Hey,

I have two applications I’d like to combine using a wrapper application.
I thought about using engines but that turned out to be rather
difficult.

Does anyone know of a solution how to do this?

Iframes isn’t really an option and the apps don’t have APIs. What I need
is have the routes and their functionality in one app. The wrapper app
wouldn’t need to have any functionality at all.

On Jul 17, 2013, at 12:06 AM, Patrick B. [email protected]
wrote:

I have two applications I’d like to combine using a wrapper application.
I thought about using engines but that turned out to be rather
difficult.

Does anyone know of a solution how to do this?

The simplest way I can think of doing this is just have an app that
wraps the other two apps in iframes.

More complex ways involve Rails engines, but integrating two existing
apps into that could be difficult, I can see

Another way is treat your two existing apps as services that your
wrapper app makes API calls to but that means your existing apps need to
have APIs.

What is it you hope to achieve with this? What will you and your users
get by having these two apps combined into one?

Another question to help clarify – are both of the other apps hosted on
your server? Do you control them in any way? If not, then you’re well
into the realm of “screen scraping”, which is a fragile way to build an
app.

Walter

Yes, both are my applications. I own the repositories and the server
they’re gonna be hosted on.

Is proxying maybe a solution?

I knew I just read about this:
http://blog.rlmflores.me/blog/2013/07/16/ruby-patterns-webservice-object/

Now that’s dealing with a proper API, using Faraday. Depending on the
HTML you are consuming (assuming – big leap here – that there are some
defined IDs or classnames that can be used to get to the data you want),
you can get similar data by parsing the HTML instead:

require ‘open-uri’
require ‘nokogiri’

src = open(‘http://example.com’)
doc = Nokogiri::HTML.parse(src)

now you can use either Xpath or css to get to your data

data = doc.css(‘#data_table tbody tr’)
data.each do | row |
fields = row.css(‘td’).map(&:text)

do what you will with the data, etc.

end

Walter

You could create data objects in your wrapper app that are just proxies
for the other services then. Since you know they won’t change underneath
you, you can literally scrape the HTML and use it as a poor man’s API.
Nokogiri is where I would start with this, since it can turn any janky
HTML into a clean object tree. But I am curious – what made adding an
API to the two other apps such an ordeal? Are they older Rails versions?
Not your work and too much hassle to untwist? (Not critical to your
answer, just asking.)

Walter

What makes it an ordeal is that the first app is massive with hundreds
of views etc., the second one is rather small with only a couple of
dozen views.

Creating APIs or even scraping it with nokogiri.

In fact I’ve kind of transformed the big one into an engine already and
added it to the wrapper app as a gem. However, my current problem is:
when I run rake routes, I get all routes from the app turned into an
engine however, login_path etc. doesn’t work in the views.

That’s exactly what I’m trying but routes etc. are not working hence
this post :slight_smile:

I think you’re on the right track. It sounds like your views are not
properly scoped to the engine, or you’re trying to call routes from the
engine that it doesn’t know about. Can you try qualifying the routes
with
the application/engine they came from? See
here: Getting Started with Engines — Ruby on Rails Guides

What about an approach where you publish both applications as gems?
wouldn’t that work? a setup like spree where you have spree_social and
stuff like that?

1.So what is that happens on the views?
2.When you try to visit the login path, what happens?
3.Do you have tests for it? where does it fail in the tests?
4.Whats the output on the logs?
5.Have you tried to use something like ruby-debugger to go through the
code
and see what happens on the views?

all the best,

Andre