Jimmy has an amazing ability to find real-world analogies to the problems found in system design. That makes the explanations "click" with so much power once you understand them! Great talk once again.
Perhaps it's the result of taking a more pragmatic viewpoint, but these solutions get hacky in a hurry. What I'm wondering is why that last note on the front end having its own service boundary wasn't unpacked more. Because we already have an implementation paradigm/philosophy for composition in the form of microservices. What if the frontend were just more microservices, composed horizontally (in parallel, handling different application needs) and vertically (in series, handling different stages of the same application need). Allowing horizontal *and* vertical composition of microservices means that the problem of styling can be deferred to later down the pipeline, making it global by definition and intention (since every component passes through it) rather than global by cooperation. To be fair, I have a different mental model of microservices than most, so perhaps I should use a different term. A push-based event-driven microservice composes much more nicely than a request-driven one, because a request driven architecture is inherently coupled to the thing it is requesting from. If application data is completely banned from message responses, then these kinds of things actually work.
Web components are useful when they can be isolated to its own functionality, not when we want them to communicate with other components because then they become tightly couple.
What is wrong with keeping composition to the browser (or presentation components) and use the back-end microservices as data/transaction components. It is simple, intuitive and keeps concerns well isolated. The vertical splitting to make microfrontends is the last mile, understood, but isnt front-end composition fast and clean(granted there are much more network calls, but that can be overcome) ? This server side MVC composition as a argument on compositional UI is just stretching the options a bit much. The product search example in the presentation is actually suited for the DB Composition via search data that is aggregated in the search DB. How does that become a MVC View layer composition case . Hufff...
Another thing about multiple requests is it actually fits reactive UI design better. Most of the time in a reactive UI you would actually track the loading/availability of components independently, which we see a lot in modern applications. For example, you may hit a product page and immediately see the price and description, and then just see a loading graphic for something like shipping details or reviews. This seems to actually couple the rendering of the page to all the services involved (unless I missed something). And honestly, the fact that everything gets coupled and tied together in the frontend makes sense: it's basically the UIs job to combine all the pieces into one. If you have zero coupling in a system, it's not a single system. The point of microservices is that your coupling is restricted to a minimum number of well defined interfaces that require (hopefully) coordination to change. So the idea that service A is allowed to change it's API and that may break the client isn't a problem: that's the entire point of it being an API and it should have the strictest contract of any service. I've worked on microservices before and I never really saw making multiple requests to individual services (or endpoints on an API gateway) as an issue.
please just do microservices. Pulling data into ELK for search is a must Now. consider modelizing : - autonomous ui, - event-driven ui - and clean up your coffee cup:)
@@RiwenX I moved to Blazor from Angular... understandably, with my heavy experience of backend programming with asp.net, Blazor was simply one of the best things ever to come into my life. And it will only get better. :)
why every speaker thinks its a good idea to insert these shitty jokes every couple of minutes which ALWAYS fail. do they all contemplate about their failed stand up comedian career or something along those lines?
Jimmy has an amazing ability to find real-world analogies to the problems found in system design. That makes the explanations "click" with so much power once you understand them! Great talk once again.
Am I the only one designing something that is NOT a webstore?!
I'd love to see an updated version with the latest toys - like Blazor for example
that makes the two of us... :)
Perhaps it's the result of taking a more pragmatic viewpoint, but these solutions get hacky in a hurry.
What I'm wondering is why that last note on the front end having its own service boundary wasn't unpacked more. Because we already have an implementation paradigm/philosophy for composition in the form of microservices. What if the frontend were just more microservices, composed horizontally (in parallel, handling different application needs) and vertically (in series, handling different stages of the same application need). Allowing horizontal *and* vertical composition of microservices means that the problem of styling can be deferred to later down the pipeline, making it global by definition and intention (since every component passes through it) rather than global by cooperation.
To be fair, I have a different mental model of microservices than most, so perhaps I should use a different term. A push-based event-driven microservice composes much more nicely than a request-driven one, because a request driven architecture is inherently coupled to the thing it is requesting from. If application data is completely banned from message responses, then these kinds of things actually work.
"I don't even bother to keep up" The sign of enlightenment 😉
Web components are useful when they can be isolated to its own functionality, not when we want them to communicate with other components because then they become tightly couple.
If the web components agree on a common api, broadcasting events Is scalable and extensible
What is wrong with keeping composition to the browser (or presentation components) and use the back-end microservices as data/transaction components. It is simple, intuitive and keeps concerns well isolated. The vertical splitting to make microfrontends is the last mile, understood, but isnt front-end composition fast and clean(granted there are much more network calls, but that can be overcome) ? This server side MVC composition as a argument on compositional UI is just stretching the options a bit much. The product search example in the presentation is actually suited for the DB Composition via search data that is aggregated in the search DB. How does that become a MVC View layer composition case . Hufff...
Another thing about multiple requests is it actually fits reactive UI design better. Most of the time in a reactive UI you would actually track the loading/availability of components independently, which we see a lot in modern applications. For example, you may hit a product page and immediately see the price and description, and then just see a loading graphic for something like shipping details or reviews. This seems to actually couple the rendering of the page to all the services involved (unless I missed something). And honestly, the fact that everything gets coupled and tied together in the frontend makes sense: it's basically the UIs job to combine all the pieces into one. If you have zero coupling in a system, it's not a single system. The point of microservices is that your coupling is restricted to a minimum number of well defined interfaces that require (hopefully) coordination to change. So the idea that service A is allowed to change it's API and that may break the client isn't a problem: that's the entire point of it being an API and it should have the strictest contract of any service. I've worked on microservices before and I never really saw making multiple requests to individual services (or endpoints on an API gateway) as an issue.
Thanks for the talk Jimmy. Could you please share the font you are using in snippets. I really want to understand the font name and specially size.
Point taken, Thanks @JimmyBogard..
please just do microservices. Pulling data into ELK for search is a must Now. consider modelizing :
- autonomous ui,
- event-driven ui
- and clean up your coffee cup:)
This talk could be shorter. Talks starts at 37:00
i googled for that noun.js thingy '__')
Blazor says Hello.. :)
Gotta give Blazor a try. I'll be sad to abandon React, tho, even if I have a love-hate relationship with JS.
@@RiwenX
I moved to Blazor from Angular... understandably, with my heavy experience of backend programming with asp.net, Blazor was simply one of the best things ever to come into my life.
And it will only get better. :)
The pricey riverbed accordingly support because camel feasibly glue over a curly loss. impossible, unable meteorology
why every speaker thinks its a good idea to insert these shitty jokes every couple of minutes which ALWAYS fail. do they all contemplate about their failed stand up comedian career or something along those lines?
You seem nice.
@@jimmybogard4178 i dont have a goal to be nice. in fact I dont care. what I care for is the content. and these shitty jokes just waste my time
Meizu M2 Mini You sound like an absolute delight to work with.
Who hurt you?
@@jiggajim your mom. nobody complained about working with me yet, quite the contrary