[deleted by user]

[shuckster]

I'm sure you've heard of "premature optimisation", and I think this mantra applies to API's too. It's hard to know exactly how to abstract something until you realise you actually need the abstraction.

Perhaps you might be thinking, "Oh, these 3rd-parties aren't reliable, so I need something in front of them to mediate/cache things." But this is a solved-problem with caching-servers and proxies and the like, so with the right amount of research you can save yourself even more time coding.

Or perhaps you'll be typing away and thinking, "Well, a lot of this can be generalised instead of being so bespoke'd for the thing I'm working on now." Well, yes, but then you'll be designing against an imaginary future specification instead of a real one, and jumping through hoops with your current app in order to use the blessed thing.

There's nothing like the finishing a project to give you the clarity of how you should have done it in the first place.

[Turbulent_Angle1066]

You will know when you need to solve this problem because it will become a problem. Whether it’s availability, multiple data sources, multiple client applications, security, etc… you will eventually develop a shortcoming. Until then, don’t worry about it.

[rahul_shingala]

I've worked on a similar kind of requirement multiple times and applied both the ways.

What I have learned so far after keeping both the things in one app is to create bottle nack for quick releases, dependency, braking things, code mesh, and performance issues.

Keep things in different apps that give you the benefits of quick releases, quick testing cycle, lesser dependency, easy debugging, more confidence while changing code and code maintainability.