If you have a service with an API in multiple processes communicating over HTTP, that's no longer a single service. This is why I say it's training wheels. It's good to get a feel, but when you hit more scale you need fewer of the things that Aspire gives. - ThreadSky

martindotnet.bsky.social • 43 days ago

If you have a service with an API in multiple processes communicating over HTTP, that's no longer a single service.

This is why I say it's training wheels. It's good to get a feel, but when you hit more scale you need fewer of the things that Aspire gives.

Comments

bertyjobbo.bsky.social•43 days ago

Totally agree with everything other than the last bit. A logical service can comprise more than one "physical" service. And often should due to different scaling demands. Eg an event subscriber vs an HTTP endpoint.

martindotnet.bsky.social•43 days ago

If your logical service has 2 different HTTP API services, i.e. processes that are deployed and developed separately, you're saying that's still a single microservice?

I can understand a HTTP API, and autoscaled async queue subscriber being a single service sure.

martindotnet.bsky.social•43 days ago

You could absolutely run them in Aspire and join them up to the same ASB.

What I'm saying is that there are better ways to do that, testing using tests from the outside, treating each component separate.

It's quite old school to hit play to test those kinds of systems.

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

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?

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.

bertyjobbo.bsky.social•43 days ago

But don't get me wrong, I see v little value in aspire for anything I've worked on. And feels a *bit* like a lock-in in the way it wants/needs to be in your app code.

Comments

Posting Rules

Reply