Rails - Apr 2006 - multiple applications to reduce complexity but how to interact...

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

On Sun, Apr 23, 2006 at 04:29:16PM +0200, Abdur-Rahman Advany 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

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

Thnx,

Abdul

Gregory Seidman wrote:
> On Sun, Apr 23, 2006 at 04:29:16PM +0200, Abdur-Rahman Advany 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
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>

On Sun, Apr 23, 2006 at 06:38:45PM +0200, Abdur-Rahman Advany wrote:
} Well, I really want to know (I am sorry for being unclear) what worked 
} for people in practice :) 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 Seidman wrote:
} >On Sun, Apr 23, 2006 at 04:29:16PM +0200, Abdur-Rahman Advany 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
} >Rails@lists.rubyonrails.org
} >http://lists.rubyonrails.org/mailman/listinfo/rails
} >
} >  
} 
}

Abdur-Rahman Advany 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?
> What do we want to achieve?
> - integration when having multiple subscription in different apps
> 
> How can we achieve 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?
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

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

Ray Baxter wrote:
> Abdur-Rahman Advany 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?
>
>> What do we want to achieve?
>> - integration when having multiple subscription in different apps
>>
>> How can we achieve 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?
>
> 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 Baxter wrote:
> Abdur-Rahman Advany 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.

-- 
Posted via http://www.ruby-forum.com/.