That's exactly what I'm saying. If you're writing an inventory service, that service might have eg endpoints to add/remove stock and others for querying stock levels from a customer facing {something}. Same logical concern, vastly different priorities. You would want that in the same developer view - ThreadSky

bertyjobbo.bsky.social • 43 days ago

That's exactly what I'm saying. If you're writing an inventory service, that service might have eg endpoints to add/remove stock and others for querying stock levels from a customer facing {something}. Same logical concern, vastly different priorities. You would want that in the same developer view

Comments

martindotnet.bsky.social•43 days ago

Those wouldn't be separate projects in my opinion. There's no reason for them to be.

Hyper-micro optimisation at that stage.

If the querying is a separate thing from performance angle, I'd expect those to not be run together, separated by a message/event.

bertyjobbo.bsky.social•43 days ago

But they'd be part of the same feature/story/PR/MR/deployment right?

martindotnet.bsky.social•43 days ago

If the querying requires different scaling, they'd be separate repos, separate infrastructure.

bertyjobbo.bsky.social•43 days ago

Got you. And this is where I have to disagree. I've seen both ways and the separate repo version causes huge amounts of pain for devs. What you're describing is what EA and DevOps at my org enforce. And most teams hate it and it causes many defects because the logic is fragmented across repos.

icooper.bsky.social•43 days ago

https://12factor.net/concurrency

martindotnet.bsky.social•43 days ago

Having, essentially, a mono repo, where you have multiple projects deployed in multiple ways, developed for different things is where you end up with different issues

There's way too many "it depends" in there though

For everytime I can see "run it all at once locally" I end up with better options

bertyjobbo.bsky.social•43 days ago

Yes, very much "it depends". Also terminology arguments - I'm not describing a monorepo. I'm describing a service repo which might have more than one deployable asset, because that makes the most sense and provides the highest quality software, for the given scenario.

bertyjobbo.bsky.social•43 days ago

But you wouldn't want it in the same deployment/physical view because they need to scale differently. Whether that's old school or not, I'm not sure 😂

bertyjobbo.bsky.social•43 days ago

But agree there's better ways to do most things than the Aspire way. It's neat and kinda fun. But doesn't really solve many problems, yet.

Comments

Posting Rules

Reply