Slides from Laracon 2015 talk about Service-Oriented Architecture in Laravel and Lumen

1. SERVICE-ORIENTED
ARCHITECTURE
By Samantha Geitz

2. LET’STALK ABOUT A PROJECT
(A HYPOTHETICAL ONE)

3. THE API ENGINEER

4. THE PROJECT

5. SOUNDS SIMPLE, RIGHT?
LET’S DO IT IN LARAVEL!

6. THE ENTITIES
• Users
• Admins
• Shirts
• Images
• Orders
• Shipping
• Payment Methods
• (Blog) posts
• Comments
• Mugs
• Laptop Stickers
• 3rd-party prices
• Search indexing
• Customer Service
• Reviews
• Videos
• ???

7. • 16 entities means (at minimum):
• 16-22 database tables
• 80-160 classes
• 800-1600+ unit tests
• A routes file that makes you want to
throw your computer out of a window

8. AND IF SOMETHING BREAKS,
IT ALL GOES DOWN

9. THIS IS A
MONOLITH
Keep building on top
of the project you
already have

10. SO WHAT IS
SERVICE-ORIENTED
ARCHITECTURE?
Lots of little separate
pieces (that talk to
each other when they
need to)

11. BOTH APPROACHES HAVE
THEIR PROS AND CONS
Just don’t do this

12. LET’S LOOK ATTHIS AGAIN
• Users
• Admins
• Shirts
• Images
• Orders
• Shipping
• Payment Methods
• (Blog) posts
• Comments
• Mugs
• Laptop Stickers
• 3rd-party prices
• Search indexing
• Customer Service
• Reviews
• Videos
• ???

13. SO WHAT MIGHTTHIS LOOK
LIKE USING SOA?
• Users
• Admins
Users API
• Shirts
• Images
• Mugs
• Laptop Stickers
• Reviews
Products API
• (Blog) posts
• Comments
• Videos
News API Orders API
• Orders
• Payment
Methods
• Customer
Service
• Shipping

14. Price Collector
• Price collecting
• Add prices to
product API
Search API
• Search indexing
• Search results

15. MICROSERVICES
• APIs organized around business capability /
function
• Only call other APIs when needed
• Single-responsibility principle

16. THE GOOD!
• Less code = easier to onboard new developers
• Fewer merge conflicts
• Easier to make changes and upgrades
• Improved fault isolation
• Running the test suite is far quicker
• Easier to scale and load-balance servers

17. THE BAD :(
• Deployment / Dev Ops complexity
• Cost
• Time investment for new microservices
• Shared code between projects can be a hassle
• More planning required

18. SO HOW DO I ACTUALLY
BUILD USING SOA?

19. LARAVELVS. LUMEN
• Lumen is great if you are building:
• APIs
• Small worker services (such as the search indexer)
• Use Laravel if:
• You don’t want to manually install front-end niceties like Elixir or
Bootstrap
• You know you’ll be using packages that don’t support Lumen
• You want/need Symfony’s more powerful routing component
• You’ve never built a Laravel application before

20. MAKINGYOUR
MICROSERVICES PLAY NICE
• Build APIs with a standard formatting schema
• JSON API / JSend / Other — just be consistent!
• Standardize HTTP codes / errors
• APIs call ONLY the endpoints they need using cURL or Guzzle
• Front-end clients (JavaScript application or Laravel project with
Blade templates) call endpoints they need

21. EXAMPLE
• Order API needs user info to print shipping label
• Send GET request to http://user-api.artisanalswag.com/
api/v1/user/{id} with user ID
• Check for API response
• If 200, return user
• If 400 / 404 / 500 / etc., pass along error message

22. AUTHENTICATION
• A few problems:
• How do you know what user is logged in?
• How do you keep unauthorized users out?
• Can you share session data? Should you?

23. USE OAUTH2!
• Authentication should be *stateless*
• You send user credentials to an authentication endpoint in User
API (along with client ID and secret)
• User API sends back two things — access token and refresh token
• Access token — short expiration time
• Refresh token — longer expiration time
• You send access token in header with your API requests

24. • User API confirms access token is still valid
• If access token is expired, the client should
send refresh token instead
• If refresh token is still valid, User API sends new
tokens (and deletes old ones)
• If refresh token is expired, require user to log
in again

25. SCOPES
• OAuth2 supports scopes (client permissions)
• Different clients can have different scopes
• Use with roles to protect your APIs

26. LOCAL DEVELOPMENT
• Homestead for local
• All software you need to run Laravel is included
• Same versions as your team / Forge
• List all applications in Homestead.yaml and hosts file
• Database — local or remote?

27. DEPLOY
• Laravel Forge
• Your Dev Ops guy
• Same cost no matter how many projects
• Taylor Otwell support
• Continuous integration (Travis, Codeship, etc.)
• Envoyer

28. AREYOU SAYING
MONOLITHS ARE BAD?
No! Do what makes sense for your application.

29. QUESTIONS?
Twitter: @samanthageitz
Email: samanthamichele7@gmail.com