Видео

very helpful, thank you! 👍👍

my rule of thumb is you never lose precision/metainfo. by storing utc you are doing exactly that

there is a pgq extension to pg.

Good video thanks

why don't you use aggregator pattern for the same? You pull data from each service individually and using composite microservice, club the data how the user wants and sends it back. Since it is business data, API gateway won't be of right implementation than aggregator pattern using composite microservice

A massive problem with what they're advertising: An HTML partial is not the same thing as HTML. I can't just go to /contact/1/edit and expect the website to render with the edit form. That GET request is just returning a partial. The glory of the old internet was if I had something like a Ruby on Rails scaffold, when I go to /contact/1/edit I get the entire hypermedia resource with all the hypermedia controls. I could bookmark that edit resource and come back to it and I'd get the same edit form. Of course I could do something more clever on the server to understand whether the request is over HTMX or a browser navigation, returning a partial in the former case and a full page in the latter. But I'm not getting rid of any of the added complexity of trying to do in-line edit, and I'm certainly not rescuing the simplicity of the REST model with HATEOS, statelessness, and the simplicity of collapsing resource and representation. Trying to get fancy stuff like in-line editing still means moving state and behavior to the client, and it still means giving up the simplicity and robustness of pursuing a REST design where we can represent something like an edit form as its own hypermedia resource rather than as a stateful on-client interaction.

I get what you're saying, but if accessing a rest API synchronously with fixed transmission format and url is "tight", what is a mega monolith, a shared database or a big ball of mud? To me those look like "loose" and "looser". Even more so if the url is a runtime parameter that is easily changed.

Good video. I think coupling and cohesion are human problems. They only matter because programs require people to maintain them. And people need order and patterns to process large amounts of data. Remove the people aspect and coupling and cohesion go out the window. Because my machine could care less what what interface exists between two classes. If anything good code is slower than any other code my machine can execute. I know, this is not some revelation, i am just saying, its not a machine problem, its an us problem.

TLDR: The only way to achieve a decoupled system is to not have a system!

thanks for the video

Hi Derek. Nice video, appreciate it. Coupling and cohesion are the roots of all architectural matters.

New Derek Coupling video!

Isn't thinking about all these types of coupling is really overengineering? ok, for sync vs async call i get it, but i can't understand why i should care about other aspects.

I find it often helps to look at our real lifes. We have many types of useful abstractions and temporal decoupling there. We tend to work asynchronously, because it makes a lot of sense. Just think of what happens when you go to a restaurant, how the waiters and cooks do their work for many guests. There are such things as message queues (order list, preperation queue, delivery queue). You don't know which person in the kitchen actually makes your meal, nor do the person in the kitchen know who will eat it. You can do other things while waiting. There are many other good examples from real life which can help to model software systems.

A should not know/care that B will process it. i was following for about a month both you and Milan, and after a while it all becomes confusing as in some videos you are contradicting yourself (its very informative nevertheless) . but that constant content churn-out in order to monetize is backfiring... it now turns into technology attrition and disinteresting

Everything depends on one thing or other. That is not the definition of coupling. Coupling implies tight coupling that disallows or making it hard to change what you depend on. Its dependency not coupling. Coupling was meant to refer the mechanism of dependency and not the dependency itself. The moment there is a agreed upon contract, there is a dependency no matter even if you build redundancy into your dependencies.

i didnt get if there is any solution to this coupling

More levels of indirection doesn't reduce coupling; hatoes just moves it from a load bearing url to a load bearing arbitrary string.

It's a distributed monolith, since you never mentioned versioning of events in the broker.

As a new programmer, I have a question: Is this task-based UI you mentioned the same as DDD? I'm actually looking for more resources on this.

I cannot follow what you are saying half of the time. Please speak in a less convoluted manner. You often start making a point, then you stop mid way, the you go back to another point and then return to your original point. You are chaining multiple unfinished statements and it becomes confusing. I had to rewind multiple times because a few things didn't make sense. You literally said nothing from 01:32 to 01:53. That was a word salad that didn't feed anyone. Another example, when you were explaining about the timestamps: "But I am gonna add a little bit to this, I am gonna have a link at the very end of this video to a video I've done about storing date-time, specifically not just UTC. Because date-times in the future not so much." I might be missing something, but "no so much" WHAT?

Great example and thanks for placing it on GItHub for free!

Event sourcing has been around for 5,000 years. 🙂 Love the breakdown in this presentation.

👍👍

👍👍

"HTTP APIs don't magically remove Coupling" Do queues next!

Cache shouldn't be used to fix unavailability. Cache is small and expensive and it's used to store only the info that is more likely will be needed in the future to improve the performance. I recommend reading "Designs Data-Intensive Applications" by Martin Kleppmann. Please reply to this comment

Great take, really enjoyed this video

More typesafe config than dockerfiles seems attractive

Isn't this supposed to beef up your local development? I think you are missing the point with Aspire.

First, thank you for these videos. I seem them more as a discussion, kind of a "retrospective" in a way, rather than a discussion of "ok, based on what we've learned, let's do X". Part of the difficulty for me personally is...how do we measure the effectiveness of one approach, vs the other? And get visibility. For example: Implementing a system using a more monolithic approach, vs a microservice approach. It's difficult to see the "real" costs of everything from start to end, and to see the true measurement of latency, performance, maintainability, all the side tasks related to devops, etc. I feel like with topics like this, the industry does a "let's try this for 10 years...ok, now lets try something else. Or something we did before. Or a hybrid.". It all just seems like guesswork and experimentation, there's no way to get a clear answer when it comes to effectiveness, or we wouldn't be in this situation.

What's with the Hype? There is no hype. It's literally just Fowler tweeting about his newest framework pet project because he wants to make it a thing.

Welcome to IaaS

this is for local dev only...no place in prod. This (with the help from .Net 8) removes the need to use docker locally.

To me Aspire seems to be one of those things that can make previously straightforward things super trivial and previously complicated things next to impossible. At least for the time being. If you're not familiar with microservices and you're starting a new microservice based project, it can save you a lot of time. But then again you probably shouldn't start a completely new project using microservices if you don't have enough experience with them. Or even if you do. Imho you should resort to a distributed architecture only once it's absolutely necessary and there's no reasonable way to avoid it.

I've been playing with it for a couple of weeks since GA. The local dev experience is nice so far, though I haven't tried it on a large microservices implementation. I think there is value add with the C# layer of abstraction on top of docker. I don't care what ports are what, I just want to say which services can talk to what. That's a problem it seems to solve. ServiceDefaults is really nice to have. It seems like a solution that could be shipped outside of Aspire, maybe, but it's nice to get some recommended defaults for those cross-cutting concerns. The deployment story is not there yet. It works if you want to use the exact default resource types, but customizing things gets a bit gnarly. infra synth to bicep or using unstable APIs in C#.

I really liked the Orleans example but the big problem I see is everything being one big solution. First I don't like gigantic solutions hard to use and navigate. Second multiple teams setup where I don't run everything in Debug because it's some others team responsibility. I am not sure how this will scale.

It's just pointless right now. I was hyped for dapr and that turned out pretty bad when i tried to actually use it but aspire is not even on the level of dapr. It reminds me more of service fabric, which was truly awful.

I'll continue to work as a C# Dev for work, but C# is too much for side projects which is why I've moved on to Go

Great honest review! Local development is definitely where we add the most value! We’ve got lots of feedback as to where to spend time improving (multi repo etc etc). Deployment will be a longer journey but we will get there! One of the big advantages that people are beginning to realize is the extensibility. We’re seeing people build some very cool things by extending the model.

It looks similar to spring cloud. Your app code depends on "cacheService" and the runtime figures it out; locally that means spinning up a docker redis, in dev it means no cache and in prod it means a managed redis.

I recently converted my solution to Aspire - 20+ projects. I'm glad that I had my own service defaults. But it was so tedious to do. I had been using Tye before, and I liked it, but switched to Docker Compose when that experiment ended. I kind of miss the YAML now.

The standalone aspire dashboard is the easiest way to see Opentelemetry data locally. Using it daily already. Not sure about the rest of aspire. Feels like there's potential here but also feels like this might turn into yet another excuse to do microservices in the wrong context.

I don't see a lot of value on aspire at this moment.

Personally I find the standalone Aspire dashboard to be more interesting. I see it as being very useful with local dev / docker-compose scenarios so that I can get visibility into my OTEL data during local development but then replace it with an enterprise grade APM solution for staging and production environments.

I've been playing around with it and I think it has a lot of promise but it falls just short right now. Specifically when it comes to testing, I'd like to use the same AppHost configuration to spin up instances of my dependencies for integration tests and to configure test services like you can with WAF. It feels very all-or-nothing right now but hopefully, it'll be more flexible in the future. I've been using a combination of docker/compose/makefile to simplify local setup and I don't think I can walk away from it yet. However I might use both Aspire and my current tooling together in my next greenfield project to get a better sense.

how I see it the "needing javascript" isn't about javascript being somehow superior, it's about javascript being the only client-side programming language on the web and webapps requiring client-side logic to have a good UX. As you pointed out the popup problem is solved by preloading, but how do you achieve that? It can only be done with javascript.

This video is my first look at Aspire and I think I can ignore it for while (maybe forever)

Still need to look at this more, my gut reactions to this were a concern about centralized configuration and not quite understanding how or if various teams working on parts of a system would or could use this. It feels like a solition in search of a real problem. Really feels like DevDiv is being asked to try hard to influence devs to use more azure instead of solving real problems. Apologies for the sinicism, I've just been doing this too long. Maybe it will be the next big thing and i'll see the light, as of now though I'm not convinced.

I’ve used it in anger. It’s decent enough, but it’s maintained by a knob (David Fowler is horrendously arrogant and unhelpful). It’s a solution to Microsoft’s problems (a bit like azure which is overpriced hosting). It’s nowhere near production ready. Perfect workflow is for developing with dependencies, avoiding docker compose for local is ideal. Most people won’t benefit though, as if you’re running real microservices it doesn’t work well across teams.