4 ms·

REST is horrible. It encourages new developers to think in terms of CRUD, which is also horrible. It encourages developers to think in terms of data, which is

REST is horrible. It encourages new developers to think in terms of CRUD, which is also horrible. It encourages developers to think in terms of data, which is amazing. At the end of the day, we're just doing data transformations, that's it. GraphQL is an interesting iteration on that idea, because it focuses more on the data. REST is simply a way to design your APIs so that they're extensible, usable, and maintainable. If you're doing something really specific, maybe it's not the best thing, but it's a really good starting point. As per your CQRS comment.... https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html "Despite these benefits, you should be very cautious about using CQRS. Many information systems fit well with the notion of an information base that is updated in the same way that it's read, adding CQRS to such a system can add significant complexity. I've certainly seen cases where it's made a significant drag on productivity, adding an unwarranted amount of risk to the project, even in the hands of a capable team. So while CQRS is a pattern that's good to have in the toolbox, beware that it is difficult to use well and you can easily chop off important bits if you mishandle it."

daxfohl 10y ago
> At the end of the day, we're just doing data transformations, that's it That's kind of the thing though. REST doesn't do transformations. It just does CRUD of resources. For me, when designing an application, I will think, "is representational state transfer the only thing this application will ever need to do?" If the answer is "no" then REST seems like a poor model to build around. I've never answered "yes" to that question. (That said, I spent many years mindlessly building REST apps before I started asking myself that). Per CQRS etc., that's right. It's a tool. Use it when appropriate. Don't use it when not. (That said, the scare factor of that article is a bit high--I've had very little trouble with it since switching to it as my go-to update pattern about five years ago. Also note Martin Fowler has changed his mind on several topics lately, such as the Rich vs Anemic domain model, away from OOP and toward a more FP viewpoint. CQRS is certainly the more FP model here.)
- gary__ 10y ago
  Have you got a link to Fowlers new thoughts on Rich vs Anemic Domain Models?
- deleted 10y ago
  [deleted]

daxfohl 10y ago

> At the end of the day, we're just doing data transformations, that's it That's kind of the thing though. REST doesn't do transformations. It just does CRUD of resources. For me, when designing an application, I will think, "is representational state transfer the only thing this application will ever need to do?" If the answer is "no" then REST seems like a poor model to build around. I've never answered "yes" to that question. (That said, I spent many years mindlessly building REST apps before I started asking myself that). Per CQRS etc., that's right. It's a tool. Use it when appropriate. Don't use it when not. (That said, the scare factor of that article is a bit high--I've had very little trouble with it since switching to it as my go-to update pattern about five years ago. Also note Martin Fowler has changed his mind on several topics lately, such as the Rich vs Anemic domain model, away from OOP and toward a more FP viewpoint. CQRS is certainly the more FP model here.)

gary__ 10y ago
Have you got a link to Fowlers new thoughts on Rich vs Anemic Domain Models?
deleted 10y ago
[deleted]