Your thoughts align with mine very well. Thank you for that. I find it unreasonable to dismiss any technology outright. Requirements drive solutions, and if it's coincidence that we've landed on no APIs I could understand. But it' not a coincidence; it's a directed effort to disallow them.
Would love to hear your thoughts on my use case and proposal linked above.
To give better context, we're building a new internal app, let's call it AppX. Let's say this app manages IMDB-like data. Many other apps in the org will need to use AppX.
The vast majority of apps are probably used by a handful of people. If any external app with heavier traffic wanted to use AppX, we should architect it accordingly.
So, before sending a proposal I'd do everything possible to understand the reasons of the situation.
You think you know who's responsible for it; just ask him
You'll have a hard time at changing things without knowing the background of the situation.
I realized that in the microservices world this kind of duplication could be acceptable; are those apps meant to be microservices?
---
I disagree with the "data alone isn't valuable" paragraphs of your proposal; I was actually going to tell you to keep in mind DBMS, besides APIs: they're specifically built to provide data to many parties, efficiently and safely.
One concern of allowing APIs might be that it might be demanding for an app, it could require adjustments and fine-tuning.
Allowing direct access to a DBMS would largely avoid any such problem.
You might well not even need any read replica, if you don't have an enormous load of requests (but you might prefer to make them, for redundancy and decoupling).
Even some derived data could be handled by stored queries, although your team might not enjoy dabbling with sql too much.
> This architecture was designed to achieve loose coupling, high availability, and independent deployability. These remain valuable goals that any proposed changes should preserve.
Were you explicitly told that these were the goals?
If so, it sounds a lot like microservices; data duplication and very strong decoupling is encouraged, and it could be hard to convince your colleagues.
> Our current approach draws inspiration from event sourcing,
Are you sure? A core aspect of data sourcing is storing all the events, and deriving the current state from them. It might be just an event-driven architecture.
---
I agree with most of your document, anyhow, although it might be hard to convince the others, if they're all-in into microservices.
I'm familiar with event sourcing. From what I understand, it's useful within bounded context/domain/app. I.e., from the outside you'd never know an app is event sourced (it's an implementation detail). Event sourcing is fantastic.
My concern is with cross-app event sourcing: N copies of data/events across N apps. Greg Young strongly advises against this in this video: https://www.youtube.com/watch?v=LDW0QWie21s
I have no idea how this came about. I think it's mainly driven by one engineer. I don't think it's related to any issues related to APIs in the past, in fact I'm not sure they've ever had APIs. There are numerous issues that have come up due to the nature of this system.
These are mostly internal apps not used by that many people. Scale isn't an issue.
I'm advocating for Events + API. With the idea that if you get an event that says "Widget 123 updated", you're free to hit the API to get whatever data you need.
Correct.
I added more context here for you: https://news.ycombinator.com/item?id=46838143
Your thoughts align with mine very well. Thank you for that. I find it unreasonable to dismiss any technology outright. Requirements drive solutions, and if it's coincidence that we've landed on no APIs I could understand. But it' not a coincidence; it's a directed effort to disallow them.
Would love to hear your thoughts on my use case and proposal linked above.
reply