I mean, if you have a public API, it makes sense, engineering-wise, to build your internal API on top of that, doesn't it? But apparently not everyone does it like this.
I mean, if you have a public API, it makes sense, engineering-wise, to build your internal API on top of that, doesn't it? But apparently not everyone does it like this.
Old reddit for example uses the reddit API essentially directly. now with new reddit, there's been a split, and it looks like from my count that reddit is currently supporting like 7 different APIs internally, parts of them all used in various different places. The reddit API is pretty functional and most of what anyone would ever really want to do was already supported in the API (and therefore available basically with few current restrictions).
Few of the actual undocumented/internal APIs on reddit are all that interesting.
[1]: https://www.reddit.com/r/redditdev/comments/14nbw6g/updated_...
So, for example, if those clients have only a fraction of the features of your internal clients, it may make sense to relegate them to a separate, stable backend service while you work on your internal one. But if there's just a couple of internal methods and everything else has to be public, it probably makes sense to have a single backend.
There's a lot of in-between cases, and that's where an engineering architect shows his skills in choosing the right approach.