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.