Haarlem goes Reactive with Vert.x

Haarlem Software Development Meetup

Transcript

1. HAARLEM SWDEV HAARLEM GOES REACTIVE - VERT.X3 / Paulo Lopes @jetdrone
2. REACTIVE WHAT'S THAT? Responsive Resilient Message Driven Elastic
3. RESPONSIVE The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively.
4. RESILIENT The system stays responsive in the face of failure. This applies not only to highly- available, mission critical systems — any system that is not resilient will be unresponsive a er a failure.
5. ELASTIC The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs.
6. MESSAGE DRIVEN Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. This boundary also provides the means to delegate failures as messages.
8. TOOLKIT < d e p e n d e n c y > < g r o u p i d > i o . v e r t x < / g r o u p i d > < a r t i f a c t i d > c o r e < / a r t i f a c t i d > < v e r s i o n > 3 . 2 . 1 < / v e r s i o n > < / d e p e n d e n c y >
9. UNOPINIONATED i m p o r t i o . v e r t x . c o r e . A b s t r a c t V e r t i c l e ; p u b l i c c l a s s S e r v e r e x t e n d s A b s t r a c t V e r t i c l e { p u b l i c v o i d s t a r t ( ) { v e r t x . c r e a t e H t t p S e r v e r ( ) . r e q u e s t H a n d l e r ( r e q ­ > { r e q . r e s p o n s e ( ) . p u t H e a d e r ( " c o n t e n t ­ t y p e " , " t e x t / p l a i n " ) . e n d ( " H e l l o f r o m V e r t . x ! " ) ; } ) . l i s t e n ( 8 0 8 0 ) ; } }
10. REACTIVE c o n n . q u e r y ( " S E L E C T * f r o m E M P " , r e s ­ > { i f ( r e s . s u c c e e d e d ( ) ) { / / G e t t h e r e s u l t s e t R e s u l t S e t r e s u l t S e t = r e s . r e s u l t ( ) ; } e l s e { / / F a i l e d ! } } ) ;
11. POLYGLOT $ v e r t x . c r e a t e _ h t t p _ s e r v e r ( ) . r e q u e s t _ h a n d l e r ( ) { | r e q | r e q . r e s p o n s e ( ) . p u t _ h e a d e r ( " c o n t e n t ­ t y p e " , " t e x t / p l a i n " ) . e n d ( " H e l l o f r o m V e r t . x ! " ) } . l i s t e n ( 8 0 8 0 )
12. DISTRIBUTED E v e n t B u s e b = v e r t x . e v e n t B u s ( ) ; e b . c o n s u m e r ( " n e w s . u k . s p o r t " , m e s s a g e ­ > { p r i n t l n ( " I h a v e r e c e i v e d a m e s s a g e : " + m e s s a g e . b o d y ( ) ) ; } ) ;
13. VERT.X & REACTIVE
14. REACTOR PATTERN
16. GOLDEN RULE
18. HOW IT WORKS...
19. HOW IT WORKS...
21. MULTI REACTOR PATTERN
23. EVOLUTIONARY MIGRATION
24. P2P MESSAGES
25. PUB/SUB MESSAGES
26. REQ/RES MESSAGES
28. TO THE POINT DISCOVERY
29. DISTRIBUTED COMPUTING
31. BREAK
32. TUTORIAL
33. HANDLER e v e n t B u s . c o n s u m e r ( " e v e n t s " , e v e n t ­ > { p r i n t l n ( " R e c e i v i n g " + e v e n t . b o d y ( ) ) ; } ) ;
34. HTTP v e r t x . c r e a t e H t t p S e r v e r ( ) . r e q u e s t H a n d l e r ( r e q ­ > { r e q . r e s p o n s e ( ) . e n d ( " H e l l o ! ! ! " ) ; } ) . l i s t e n ( 8 0 8 0 ) ;
35. ASYNC p u b l i c s t a t i c v o i d a d d ( i n t a , i n t b , H a n d l e r < I n t e g e r > h a n d l e r ) { i n t r = a + b ; h a n d l e r . h a n d l e ( r ) ; }
36. CLUSTER
37. SOCKJS BRIDGE
38. HIGH AVAILABILITY
39. POLYGLOT $ v e r t x . c r e a t e _ h t t p _ s e r v e r ( ) . r e q u e s t _ h a n d l e r ( ) { | r e q | r e q . r e s p o n s e ( ) . p u t _ h e a d e r ( " c o n t e n t ­ t y p e " , " t e x t / p l a i n " ) . e n d ( " H e l l o f r o m V e r t . x ! " ) } . l i s t e n ( 8 0 8 0 )
40. PACKAGING (FAT-JAR) j a v a ­ j a r m y a p p . j a r
41. SERVICES
42. HOW ABOUT PERFORMANCE?
45. THANK YOU! Vert.x is fun! http://vertx.io