Brilliant talk, I disagree only with the comment "Kill REST APIs" but do agree with reducing the focus on request/response systems. Req/Res are implementations details of HTTP, REST can work over websockets. REST is a concept for building distributed systems, it is in no way is it limited to APIs or HTTP(req/res). That being said most "REST" APIs are implemented incorrectly since they lack Hypermedia controls in their message structure.
I like Martin Kleppmann, he's a very bright person and a good teacher. I disagree though with his statement "Kill REST". In this talk he proposes to use streams over REST but imo this is all use case dependent. Also the idea of a stream is not so new, publish/subscribe communication flow is pretty widely used already, just think about web sockets. Think about an application that doesn't need to be updated about any CRUD operations within the DB in real time (like 95% of applications). Would you still introduce a complex stream based backend over simple REST?
MQTT is a publish/subscribe server with open source JavaScript web socket libraries that's been around for a long time. I used it in the public safety sector for officers to subscribe to streams published by the dispatch center. I guess I'm fuzzy on how this differs from that other than fuzzing the lines between the MQTT server and the database it may ride on.
+maverick88NL Totally! However, in upcoming period, I bet that many people will feel uncomfortable by switching from CRUD to CQRS. Worst issues I encountered was the essential separation of write model from read model. Especially, how to fit everything with specific technology. Implementation of CQRS pattern can be ridiculous sometimes. :)
I read the phrase "When a client reads from a materialized view, it can keep the net‐ work connection open." from Martin's book "Making sense..." and wondered where was that coming from. How a materialized view offers such a feature ?
2024 and it is still not possible to wish away state. Many thanks for this work!
2017 and this is still incredible interesting. Thank you.
2021 still awesome! Thank you!
amazing speaker. explaining a difficult concept with simplicity. 2024 still interesting !
Martin Kleppmann The God of Distributed Systems! Thanks Strange Loop for sharing this
This talk is the most important talk in the century about all kind of computer future logic
Still Relevant! Awesome content Martin :)
Brilliant talk, I disagree only with the comment "Kill REST APIs" but do agree with reducing the focus on request/response systems. Req/Res are implementations details of HTTP, REST can work over websockets. REST is a concept for building distributed systems, it is in no way is it limited to APIs or HTTP(req/res). That being said most "REST" APIs are implemented incorrectly since they lack Hypermedia controls in their message structure.
really digging these hand written slides
Genius! Way ahead of his time
I really enjoy this kind of thinking. Thanks for the talk.
I like Martin Kleppmann, he's a very bright person and a good teacher. I disagree though with his statement "Kill REST". In this talk he proposes to use streams over REST but imo this is all use case dependent. Also the idea of a stream is not so new, publish/subscribe communication flow is pretty widely used already, just think about web sockets. Think about an application that doesn't need to be updated about any CRUD operations within the DB in real time (like 95% of applications). Would you still introduce a complex stream based backend over simple REST?
Excellent presentation.
MQTT is a publish/subscribe server with open source JavaScript web socket libraries that's been around for a long time. I used it in the public safety sector for officers to subscribe to streams published by the dispatch center. I guess I'm fuzzy on how this differs from that other than fuzzing the lines between the MQTT server and the database it may ride on.
CQRS?
+maverick88NL Totally! However, in upcoming period, I bet that many people will feel uncomfortable by switching from CRUD to CQRS. Worst issues I encountered was the essential separation of write model from read model. Especially, how to fit everything with specific technology. Implementation of CQRS pattern can be ridiculous sometimes. :)
Amazing! Thanks!
I wonder if this guy knows Datomic. I think it's exactly what he wants :)
+Matúš Lešťan He mentions this IN THE VIDEO...
+Matúš Lešťan He compares to Datomic at 43:05
+Matúš Lešťan Yes, He has mentioned Datomic in his book Designing Data Intensive Applications, 2nd chapter.
If he wants it, chances are he probably built it.
So Event Sourcing then?
"Martin Kleppmann - Event Sourcing and Stream Processing at Scale" - ua-cam.com/video/avi-TZI9t2I/v-deo.html
good presentation. very interesting.
24:22 "Kappa" Architecture. :)
I wonder what Martin Kleppmann thinks of relay and graphql
more like redux ...
Does anyone know what software was used to draw theses slides? Would be great for university
thanks folks
iPad Pro with pen would suffice :)
Kafka streams seems to have killed Samza
I read the phrase "When a client reads from a materialized view, it can keep the net‐
work connection open." from Martin's book "Making sense..." and wondered where was that coming from. How a materialized view offers such a feature ?
databases are so 1970's
Turing machines are so 1940's
Pants are so 1800's
Wheels are so 4000 BC