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
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
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