Multiple applications to reduce complexity but how to intera

Rails
1

Hi,

we are building couple of application that will need to communicate with
each other, because there where special in what they do, I will explain
it with some general application:

For example, you have a projectmanagement application, where you can
store messages, milestones, enc, and you have a online time registration
application. Now you want to be able to setup the task for each
milestone in the timeregistration application but still have a
projectmanagement application for client that don’t need the time
registration.

Why do we want to split it up?

  • easy interface
  • application focused on one task

What do we want to achive?

  • integration when having multiple subscription in different apps

How can we achive this?

  • option 1: use the same database and make one big application (we think
    this make developing complicated)
  • option 2: use the same database, models but implement the logic again
    (mhhh, not in favor of that)
  • option 3: let the application handle the integration by directing it
    to the secondary application, that application should direct it back
    when its done (look like the best alternative)
  • option 4: use the application api to communicate between apps (rails
    doesn’t have a good way of handeling services or am I wrong?)

How have you done it? what are your ideas?

Greets,

Abdur-Rahman

2

On Sun, Apr 23, 2006 at 04:29:16PM +0200, Abdur-Rahman A. wrote:
[…]
} Why do we want to split it up?
} - easy interface
} - application focused on one task
}
} What do we want to achive?
} - integration when having multiple subscription in different apps

This is very clearly stated. Kudos for asking a question well. That
said,
all of the following choices are plausible, but some are better than
others.

} How can we achive this?
} - option 1: use the same database and make one big application (we
think
} this make developing complicated)

You can also have one big application with multiple databases. I don’t
have
the Agile book in front of me, but I know it is possible to set up
subclasses of ActiveRecord::Base that each define their own database
connection, and have your models subclass the appropriate one of those.

It is also possible to split out your models into modules, to keep the
major pieces of your application separate. Controllers can likewise be
placed in modules.

} - option 2: use the same database, models but implement the logic
again
} (mhhh, not in favor of that)

I’m not quite clear on what you mean by this approach, but repeating
yourself is never a good idea. It is, however, possible to share code
between separate applications, just as you can share code between
scripts
with additional Ruby libraries (e.g. gems).

} - option 3: let the application handle the integration by directing it
} to the secondary application, that application should direct it back
} when its done (look like the best alternative)

If your system is sufficiently separable to do this, it definitely
sounds
good. It does have some hard limitations, however, so you should be sure
your application will never need to go beyond them before taking this
approach.

} - option 4: use the application api to communicate between apps (rails
} doesn’t have a good way of handeling services or am I wrong?)

Actually, Rails supports web services quite nicely. It’s probably
overkill
for several applications that are likely to be running on the same
server.
On the other hand, this is the most scalable solution since you can move
your individual applications to separate machines without disrupting the
system as a whole.

} How have you done it? what are your ideas?
} Greets,
} Abdur-Rahman
–Greg

3

Well, I really want to know (I am sorry for being unclear) what worked
for people in practice :slight_smile: How have you done it? and why?

Thnx,

Abdul

4

On Sun, Apr 23, 2006 at 06:38:45PM +0200, Abdur-Rahman A. wrote:
} Well, I really want to know (I am sorry for being unclear) what worked
} for people in practice :slight_smile: How have you done it? and why?

Ah, you are looking for case studies. Unfortunately, I can’t help you
there. I have not yet been in a position where I needed to create a huge
app.

} Thnx,
} Abdul
–Greg

} Gregory S. wrote:
} >On Sun, Apr 23, 2006 at 04:29:16PM +0200, Abdur-Rahman A. wrote:
} >[…]
} >} Why do we want to split it up?
} >} - easy interface
} >} - application focused on one task
} >}
} >} What do we want to achive?
} >} - integration when having multiple subscription in different apps
} >
} >This is very clearly stated. Kudos for asking a question well. That
said,
} >all of the following choices are plausible, but some are better than
} >others.
} >
} >} How can we achive this?
} >} - option 1: use the same database and make one big application (we
think
} >} this make developing complicated)
} >
} >You can also have one big application with multiple databases. I
don’t have
} >the Agile book in front of me, but I know it is possible to set up
} >subclasses of ActiveRecord::Base that each define their own database
} >connection, and have your models subclass the appropriate one of
those.
} >
} >It is also possible to split out your models into modules, to keep
the
} >major pieces of your application separate. Controllers can likewise
be
} >placed in modules.
} >
} >} - option 2: use the same database, models but implement the logic
again
} >} (mhhh, not in favor of that)
} >
} >I’m not quite clear on what you mean by this approach, but repeating
} >yourself is never a good idea. It is, however, possible to share code
} >between separate applications, just as you can share code between
scripts
} >with additional Ruby libraries (e.g. gems).
} >
} >} - option 3: let the application handle the integration by directing
it
} >} to the secondary application, that application should direct it
back
} >} when its done (look like the best alternative)
} >
} >If your system is sufficiently separable to do this, it definitely
sounds
} >good. It does have some hard limitations, however, so you should be
sure
} >your application will never need to go beyond them before taking this
} >approach.
} >
} >} - option 4: use the application api to communicate between apps
(rails
} >} doesn’t have a good way of handeling services or am I wrong?)
} >
} >Actually, Rails supports web services quite nicely. It’s probably
overkill
} >for several applications that are likely to be running on the same
server.
} >On the other hand, this is the most scalable solution since you can
move
} >your individual applications to separate machines without disrupting
the
} >system as a whole.
} >
} >} How have you done it? what are your ideas?
} >} Greets,
} >} Abdur-Rahman
} >–Greg
} >
} >_______________________________________________
} >Rails mailing list
} >[email protected]
} >http://lists.rubyonrails.org/mailman/listinfo/rails
} >
} >
}
}

5

Ray,

Tnx for your feedback, yes we are currently in a situation where 5
applications have been developed than need to be merged into one
application, when we started developing we expected to do this. But know
we are reconsidering, maintaining one application is already very
complex, maintaining one big integrated application is much more
complex. How have the peepz at 37s solved this? they have multiple
applications but still an integration.

Greets,

Abdul

p.s. the pm/timeregistration was only an example, we are not creating an
other application suite that aims at serving that market

6

Abdur-Rahman A. wrote:

For example, you have a projectmanagement application, where you can
store messages, milestones, enc, and you have a online time registration
application. Now you want to be able to setup the task for each
milestone in the timeregistration application but still have a
projectmanagement application for client that don’t need the time
registration.

Why do we want to split it up?

  • easy interface
  • application focused on one task

I’m not convinced that this is a good idea. A large fraction of the
enterprise software development is trying to do the reverse, combine two
or more separate software applications into one. Rails can easily
handle giving you separate controllers and views so that the interface
works well in the different use cases you mention and is modular enough
that the parts of the application will be decoupled for ease of
development.

Second, it is premature to be asking the question at this point. Are you
sure you are trying to solve a real problem? Perhaps one large app would
be complicated, but I would bet that having two or three applications
intercommunicating would be even more complicated.

In your scenario, isn’t there going to be some notion of roles? Client A
can only see projects belonging to Client A, Manager Employee B can see
projects belonging to all Clients, and Employee C can see projects
belonging to Clients Q, R and S and can only complete tasks belonging to
Client S’ Project W. This means that you are going have to either have a
separate authentication module on your project and time applications, or
you are going to have to pass not only the fact of being authenticated,
but also the detailed credentials back to the project and time apps.

At that point, wouldn’t it be simpler just to have a single app?

when its done (look like the best alternative)

  • option 4: use the application api to communicate between apps (rails
    doesn’t have a good way of handeling services or am I wrong?)

How have you done it? what are your ideas?

Here is how I’d do it.

Start by developing the project management portion of the application.
Once you have an idea what that looks like you can start to add the
timekeeping functionality. Add in authentication and user specific
customizations as necessary.

If it ever becomes necessary to separate the applications, you will be
the expert on what the pain points are in your application and you will
be in a better position to evaluate and implement possible solutions.

–

Ray

7

Ray B. wrote:

Abdur-Rahman A. wrote:

At that point, wouldn’t it be simpler just to have a single app?

I agree that you are better off with one app. Rails makes it easy to
keep things encapsulated and organized.