Talk in English - US at PHP UK Conference 2014
View Slides: https://speakerdeck.com/nesquick/service-oriented-architecture-for-robust-and-scalable-systems
Short URL: https://joind.in/talk/d1ebb
(QR-Code (opens in new window))
Service Orientated Architecture for Robust and Scalable Systems
Comments
Comments are closed.
Very enthusiastic speaker and there was plenty of good stuff to take in. Taking a bit of time to introduce/provide some background to the subject worked well and it was nice to have confirmation of existing thoughts in the main SOA content. Some occasional overly-quick speaking did make some points difficult to work out.
Good talk. started a bit slow but some great advise in there
Very good talk, but would have liked more detail on actual tools used and a couple of practical examples.
Great talk, confirmed a few things for me and intoduced a lot of new ideas and insight.
Balanced view of good REST design without being overzealously purist. Thanks!
Nice to have some relatable examples of bad experiences to start. Some good advice on how to avoid common pitfalls.
Interesting points raises like the circuit breaker pattern.
Entertaining talk with a passionate speaker, a little fast in places sometimes made things difficult to follow. Wasn't so sure on the summary and when not to use SOA.
A great first talk of the day by Ole who came across very enthusiastic and humorous too, and took us through a comprehensive overview of SOA. Some direct application tips were covered as well as interesting points about the history, as well as his own experiences. Definitely lots of useful info here.
Nice talk, quite hard to follow from the video overflow track when you point at the screen ... we can't always see that! Great stories, good tech and I especially liked the warnings about not labelling your API as RESTful :) I think you could speak more slowly, might make you a little easier to follow and give better separation between points.
Great talk about services and why to separate them and how it helps.
Nice reference to Amazon where everyone had to define API and communicate only via this API.
HTTP protocol was suggested, which makes sense for majority of services which are basically only request-respond once over a time. You can also use all benefits of HTTP like methods, headers and much more.