Hi,
I am working on a project which involves two application running separately with separate database.
There are some data which I need from app 2 in app 1, and vice versa.
Currently, I am calling api of app2 in app1 and getting the data needed.
Is there any other better way to get the data between two django rest application, so that I can limit the number of api calls between two applications and make the system more reliable?
Regards,
Ajith
Why do you think that limiting the number of api calls is better or would make the system more reliable?
Thanks Ken,
Reasons:
If app2 is down due to some reasons, then some features dependent on app1 won’t work. Hence thinking of how to reduce the dependency and make the application fault-tolerant.
The data shared between these two apps are not likely to change every seconds/minutes. Hence trying to limit the number of api calls.
Few front-end developers asked me to check if there is a better way to handle these scenarios.Most-likely reason : 
Given the constraint of two applications serving data from two different databases, there’s always going to be the possibility of some type of inconsistency between the states of the two systems. An application API is no more or less likely to fail, assuming it’s reasonably well-written.
Fault tolerance comes from being able to gracefully handle errors. Your code in app1 that makes requests from app2 needs to handle that situation. If you use something like the requests library, you have a lot of control over handling errors. (For example, you can specify a short timeout if you can reasonably expect 1 - 2 second response times from your API - not unreasonable in a lot of cases. There are other errors as well where you can get more details and make conscious decisions as to how they need to be handled.)
In a logic class, I believe they would call that “begging the question”. You’re still assuming that there’s an important reason for limiting the number of API calls by assuming that there is a reason for limiting the number of API calls. You’re not going to burn out your ethernet cables by transferring data through them.
Likewise, you’re assuming the conclusion that there needs to be a better way - without identifying why there’s something wrong with this way of doing it.
There’s a famous old saying, first made popular by Donald Knuth in his book The Art of Computer Programming
“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”
If you’re having a real problem, then yes, it’s something that should be addressed. But if this is all conjecture based on some round-table discussions, then I wouldn’t spend any time on it.
There are cases where minimizing the number of API requests could be a valid consideration. (Consider a service where you pay a fee for each request - you definitely want to minimize the number of requests you make.) That’s why I’m trying to probe in that direction. But I’m not seeing that from anything you’ve posted so far.
Ken
Thanks a lot ken.
Looks like we are following the right approach for communicating between two apps using the REST API.
“Likewise, you’re assuming the conclusion that there needs to be a better way - without identifying why there’s something wrong with this way of doing it.”
I wasn’t assuming, was curious to learn if there are better ways to handle these kind of scenarios.
I guess if there’s any bottom line to it, it’s that there is no “better” or “worse” in absolute terms. Architectural decisions like these need to be made in the context of your particular needs. What’s better for you in your environment may not be better for me in mine - and that’s why I kept drilling into the “why” you were looking for a different solution.
(I also am of the general opinion that, all other things being equal, the simplest solution that works is the better choice than a solution engineered for an issue that might occur.)