Any formula to decide whether to use a script (eg bash) or code an app (LAMP)?

Question

We have a few different apps X,Y,X from different third parties and we want to pull the data into a central app C, so when users enter data into C they can pre-populate forms with related data. If they enter a customer-id from app X into C, they will get related customer-id info, address, etc. from X, populating forms in C.

One idea, have a cron job script for each app X, Y, Z ..., that queries their databases and produces a standard json file/url: X-related-info.json, Y-related-info.json etc. every day. App C can pick this up on demand. This info changes rarely and it's a fixed low number of records. You could run the cron every minute with no issue.

Cost to write custom bash script/cron + tests + docs = 60 mins (for each X,Y,Z... app).

[ X ] --> bash script --> [ C ]

Another idea is to create a gateway app GW, that would do a real-time query to X,Y,Z and similarly present a json url to app C. It would have a GUI to add third party apps you want to get data from. However, you would still need to write custom code for each X, Y, Z as they are apps by different 3rd parties with different database designs.

So cost to make GW app + tests + documentation = 1 week, + cost to write custom code + tests = 60 mins (for each X,Y,Z... app)

[ X ] --> custom code --> GW app --> [ C ]

My conclusion is that since you have to do custom code anyway for each X,Y,Z, for the GW app, then just use cron and bash script - there's no need for the GW app. I felt it's quite clear cut. I am hesitant to make another app because we are low resourced, testing and docs overhead, and dealing with future bugs/issues maintenance of another app, and we're behind on schedule on other things. But a senior dev says no, we should create the GW app because it's more flexible and future-proof. Went over his explanation again, we still need custom code per X,Y,Z... app. I don't think the flexibility/future-proofing beats the actual time costs.

Answer 1

Seems like you've basically answered your own question.

Regarding flexibility, the question is how many extensions you expect to have in the foreseeable future. Do they offset the cost of the up-front app development?

With the estimates you provided, it would, of course, take an infinite amount of extensions to amortize the costs, because you don't seem to be gaining anything: in both cases, you need 60 min per app.

But since the investment is small anyway, and provided you don't expect a new app in the next few weeks, why not suggest the simple approach as a prototype that you can always replace later.

Answer 2

Based on your question and on your comment, I would propose a different approach:

Another idea is to create a gateway app GW, that would do a real-time query to X,Y,Z and similarly present a json url to app C. It would have a GUI to add third party apps you want to get data from. However, you would still need to write custom code for each X, Y, Z as they are apps by different 3rd parties with different database designs.

Cost to write custom bash script/cron + tests + docs = 60 mins (for each X,Y,Z... app).

So cost to make GW app + tests + documentation = 1 week, + cost to write custom code + tests = 60 mins (for each X,Y,Z... app)

In my opinion, the GW Gui is totally non-sense. This GUI would make C app to look highly customizable, which it isn't (because you still need code to do the new queries).

Therefore, I suggest an approach more like a plugin. For an additional third-party app, you just implement a new "custom code" (kind of a plugin code to C), which you said takes the same amount of time as the bash script. I suggest code instead of bash, because you can benefit from OOP features, and provide some interfaces for your plugins to adhere and be able to provide additional third-party apps' data.

To summarize: define some "third-party data" interface in your C app, and create new code that implement this interface for each new additional app.