Despite the specific title, there is so much to learn from this talk that I have re-watched it thrice. Beautifully explained, love the energy and very practical!
Very interesting talk! I think that lot of advises are pretty actionable quickly on most projects. Digression: I'm very frightened by the state of the audience... I'm feeling that DDD is getting so mainstream that people are coming to talks just because it's "fashion" theses days to go to a DDD conf.
on the flip side they may be trying to learn and change. I would look at it with a little more hope. Sadly there is information loss on esch generation, it is inevitable, I would be more worried if the audience was full of experts, at that point ddd is no longer growing.
Thanks you, this is a very interesting talk. I'm not familiar with hateoas, how about the request which perform an action that need a large body, we can't put it in url, as usual we make a post request with a json body.
The htmx essays are a great way to learn about hateoas. This concept is defined in Roy Fielding's Rest Architecture paper and it describe how the web works. as such tou aren't limited to the url. you can use headers and the body. A form can serialize a big request in the body. There is form encoding, besides the json that is common. i recommend you check out htmx and learn why html is the best way to implement hateoas
htmx essays are the best place to learn about hateoas. They (and I agree) will advocate gor using html in the response and not json. forms will encode data into a the request (on the body in post and on the queryParams in get)
forms with a post method are the native way to tell the browser you want to encode a bunch of fields and send them in the request body when submited to the server. for more on hateoas and to learn the best way (and the right times) when to use it, i recomend you read the essays on htmx
well, basically, all we need is to go back to server-rendered content and forget about that rich-client crap. i totally agree with that. front-end should be simply about the look. functionality must be handled in single place - the back-end. simplicity is the ultimate sophistication -- leonardo da vinci
Not my responsibility but ok. 2 quick comments and I'm done. 1) The whole talk leads to one thing: HATEOAS - a useless overengineering model brings unnecessay complexities causing you to constantly fighting the tool to solve a problem that doesn't even exist 2) slightly brought up DDD as a buzzword but didn't have any compelling explaination. Also what's the point of talking about Domain Model when everything he touched on is still happening in the User Interface layer? A simple rule of thumb to save anyone time to watch the whole talk could be: Use Task based REST API instead. Only use resource based REST API when you are doing CRUD operations of a dead simple model e.g. updating a small internal config record in db
@@chauchau0825 Well you said "IMHO", so it's no one else responsibility to explain what did you mean I think. Personally I kind of agree with what you said about HATEOAS. Tried couple of time to implement it, but in the very end didn't find a very good reason to follow it further and in fact we were dropping that idea (especially the complexity/maintenance tradeoff). However after this talk I have the impression we didn't see the value, because the idea was dropped too fast. Gonna give it another try I think. Yes DDD is like a buzzword this days. However as I understood (also the title says that) he didn't want to showcase Domain modeling, but just how to build an API expressed a kind of domain way. In fact he managed to do it and I wouldn't say he has used DDD just to gather more attention. Thanks for sharing your thoughts, now it's constructive criticism 👍.
@@kamilszymanski1426 apologies for being rude if hat makes you unhappy. The industry has rejected it. Bare no one is talking about it. Rarely anyone is using it. But every now and then, someone jumps out and advocates about it. "See you don't understand it", "I understand it", "I know how it works", "Do it my way and it will work". [Trigger warning and nothing personally] HATEOAS is like communism. Where it applies, it always failed and caused disaster. But there are always someone foolish enough to think they out smart everyone else and keep trying it. Millions of people died due to communism and millions budgets wasted due to HATEOAS. The industry rejected HATEOAS not because no one understand it, but the exact opposite: understanding how dumb it is. IMO, He didn't managed to build an DDD REST API. What he said is basically saying, in my own way to summarize his words, "use a separate endpoint for different action". There is nothing in talk about DDD. I do think he did used DDD just to gather more attention.
ddd does seem like a stretch, i guess it was a way to make the talk more appealing to the conference. I wonder if you guys that have had bad experiences with Hateoas tried to implement it via json. I have found that using html (specially enhancing it with htmx attributes and related js library) provides a simple way to provide hateoas interfaces for humans. So I do agree with the hateoas solution.
Despite the specific title, there is so much to learn from this talk that I have re-watched it thrice. Beautifully explained, love the energy and very practical!
Fantastic! Loved this concept of workflow oriented REST APIs.
beautiful talk with an amazing start.
Very interesting talk! I think that lot of advises are pretty actionable quickly on most projects.
Digression: I'm very frightened by the state of the audience...
I'm feeling that DDD is getting so mainstream that people are coming to talks just because it's "fashion" theses days to go to a DDD conf.
on the flip side they may be trying to learn and change. I would look at it with a little more hope. Sadly there is information loss on esch generation, it is inevitable, I would be more worried if the audience was full of experts, at that point ddd is no longer growing.
Thanks you, this is a very interesting talk. I'm not familiar with hateoas, how about the request which perform an action that need a large body, we can't put it in url, as usual we make a post request with a json body.
The htmx essays are a great way to learn about hateoas.
This concept is defined in Roy Fielding's Rest Architecture paper and it describe how the web works.
as such tou aren't limited to the url. you can use headers and the body.
A form can serialize a big request in the body. There is form encoding, besides the json that is common.
i recommend you check out htmx and learn why html is the best way to implement hateoas
htmx essays are the best place to learn about hateoas. They (and I agree) will advocate gor using html in the response and not json.
forms will encode data into a the request (on the body in post and on the queryParams in get)
REST uniform interface isn't the same as CRUD.
so we don’t need pass post body as json? If we need pass body as json how do we return it through links
forms with a post method are the native way to tell the browser you want to encode a bunch of fields and send them in the request body when submited to the server.
for more on hateoas and to learn the best way (and the right times) when to use it, i recomend you read the essays on htmx
htmx essays are the best place to learn about hateoas. They (and I agree) will advocate gor using html in the response and not json
@@corlaezif the API is used by a mobile app also, how does that work?
Do mobile clients parse the HTML response and traverse the xml tree?
well, basically, all we need is to go back to server-rendered content and forget about that rich-client crap. i totally agree with that.
front-end should be simply about the look. functionality must be handled in single place - the back-end.
simplicity is the ultimate sophistication -- leonardo da vinci
What about native apps
@@sahilmulla1680 i thought it was about web apps.
IMHO, he is right on the problems but wrong on the solutions
You could give some examples of the right solutions to make your comment constructive :)
Not my responsibility but ok. 2 quick comments and I'm done.
1) The whole talk leads to one thing: HATEOAS - a useless overengineering model brings unnecessay complexities causing you to constantly fighting the tool to solve a problem that doesn't even exist
2) slightly brought up DDD as a buzzword but didn't have any compelling explaination. Also what's the point of talking about Domain Model when everything he touched on is still happening in the User Interface layer?
A simple rule of thumb to save anyone time to watch the whole talk could be: Use Task based REST API instead. Only use resource based REST API when you are doing CRUD operations of a dead simple model e.g. updating a small internal config record in db
@@chauchau0825 Well you said "IMHO", so it's no one else responsibility to explain what did you mean I think.
Personally I kind of agree with what you said about HATEOAS. Tried couple of time to implement it, but in the very end didn't find a very good reason to follow it further and in fact we were dropping that idea (especially the complexity/maintenance tradeoff). However after this talk I have the impression we didn't see the value, because the idea was dropped too fast. Gonna give it another try I think.
Yes DDD is like a buzzword this days. However as I understood (also the title says that) he didn't want to showcase Domain modeling, but just how to build an API expressed a kind of domain way. In fact he managed to do it and I wouldn't say he has used DDD just to gather more attention.
Thanks for sharing your thoughts, now it's constructive criticism 👍.
@@kamilszymanski1426 apologies for being rude if hat makes you unhappy.
The industry has rejected it. Bare no one is talking about it. Rarely anyone is using it. But every now and then, someone jumps out and advocates about it. "See you don't understand it", "I understand it", "I know how it works", "Do it my way and it will work".
[Trigger warning and nothing personally] HATEOAS is like communism. Where it applies, it always failed and caused disaster. But there are always someone foolish enough to think they out smart everyone else and keep trying it. Millions of people died due to communism and millions budgets wasted due to HATEOAS. The industry rejected HATEOAS not because no one understand it, but the exact opposite: understanding how dumb it is.
IMO, He didn't managed to build an DDD REST API. What he said is basically saying, in my own way to summarize his words, "use a separate endpoint for different action". There is nothing in talk about DDD. I do think he did used DDD just to gather more attention.
ddd does seem like a stretch, i guess it was a way to make the talk more appealing to the conference.
I wonder if you guys that have had bad experiences with Hateoas tried to implement it via json.
I have found that using html (specially enhancing it with htmx attributes and related js library) provides a simple way to provide hateoas interfaces for humans.
So I do agree with the hateoas solution.