1

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.

7
  • The custom code from the second approach is simply calling the binary program and convert the results into json format? – Emerson Cardoso Nov 29 '17 at 18:29
  • Your senior dev may have insight into future needs that you don't. – Blrfl Nov 29 '17 at 18:32
  • 2
    I'm voting to close this question as off-topic because this seems to be a people problem, probably be a rant in disguise against the senior dev. FWIW, if writing a bash script takes just 60 minutes, just sell it to your senior as "a workaround/prototype/proof of concept before the GW app will be ready". Then, when it is running (tomorrow, before noon, if I take you literally), there will probably be more important things to do than building the app. – Doc Brown Nov 29 '17 at 20:33
  • No, trying to find something objective to highlight. I don't think future flexibility/demand is clear enough - especially when there is a history of apps/features not being used. – user95437 Nov 30 '17 at 14:13
  • @EmersonCardoso just like the bash script it would be a custom mysql query, as each third party app has their own database model/column names. This would then be put into a json file, third-party-appname.json, with standard keys. – user95437 Nov 30 '17 at 14:16
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.

1
  • I guess I would be in favour of the GW app if it eliminated all custom coding. But that would be impossible unless you get the third-parties to modify their app to talk nicely with the GW app. – user95437 Nov 30 '17 at 14:19
0

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.

1
  • Cardaso Good idea, but difficult if C and the third party apps are on different servers. MySQL is restricted to localhost only. I guess you could white-list some IP addresses. – user95437 Dec 6 '17 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.