http://rockalabs.com
xergioalex
It’s autonomous: self-contained unit of functionality. A unique location (URL) identifies it.
It’s isolated, so we can modify it, test it and deploy it without impacting other areas of the solution
It’s elastic. Can be scaled independently of other services.
Vertical
Escaling
Horizontal
Escaling
It’s resilient. Is fault tolerant and highly available.
It’s responsive, it responds to requests in a reasonable amount of time.
It’s message oriented. Rely on asynchronous message-passing to establish a boundary between components.
It’s programmable. Thanks to API’s for access by developers and administrators and Applications are composed from multiple microservices.
It’s automated, the lifecycle of a microservice is managed through automation that includes dev, build, test, staging, production and distribution.
Scalable
PROS
CONS
Network latency increased by the messages interchange.
Reduce deployment costs
Deployment and testing complexity increase exponentially based on the number of interaction between services.
Can be developed by a small team.
PROS
CONS
Too fine grained microservices may create an overhead that outweighs its utility.
Team only has to be aware of the business logic that represents the service and its interactions.
Message formats, restrictions, and interactions knowledge is needed.
Continuous deployment.
PROS
CONS
Must pay lot of attention in versioning because of the interaction with older version of other services.
Use the technology you prefer to create it.
Transactional operations that goes through the boundaries of many microservices increase the logic complexity.
It was created by Facebook in 2012, driven by the mobile team
GraphQL Especificación
(http://facebook.github.io/graphql/October2016/)
Implementación de referencia en js:
Graphql is query language designed to communicate clients and servers.
A complete alternative to REST.
GraphQL is not like SQL.
Platform agnostic (implemented in 20 languages)
It's just a convention
It is a typed language
The server exposes
resources.
The client defines
what receives
Usually send more
information than necessary.
Only what is necessary
is sent
Multiple requests per
view or custom
One request per view
Documentation foreign to development.
Documented by
definition.
Only one endpoint is required
Multiples endpoints exposed
/puppies
/puppies/:id
/puppies/update/:id
/puppies/delete/:id
Por qué API REST está muerto y debemos usar APIs GraphQL - José María Rodríguez Hurtado
https://www.youtube.com/watch?v=cUIhcgtMvGc
Por qué API REST está muerto - José María Rodríguez
Cheatsheet
GraphQL SWAPI
http://graphql.org/swapi-graphql/
GraphQL Voyager
https://github.com/APIs-guru/graphql-voyager
Apollo Launchpad
https://launchpad.graphql.com/
GraphQL Anywhere
Graphene (Python)
Relay (Client)
https://facebook.github.io/relay/
Apollo (Client)
https://www.apollographql.com/client
Codenames
https://github.com/GraphqlBA/codenames-gql/
APIs GraphQL
https://github.com/APIs-guru/graphql-apis
Github GraphQL API
https://developer.github.com/v4/
Why GraphQL (Github)
https://githubengineering.com/the-github-graphql-api/
Docker
Docker Compose
https://docs.docker.com/compose/
Github GraphQL API
https://developer.github.com/v4/
Docker Machine
https://docs.docker.com/machine/
Docker Swarm
https://docs.docker.com/engine/swarm/
Divide and conquer – The Microservice approach
https://www.art2link.com/divide-conquer-microservice-approach/
Docker Load Balancer Demo
http://rockalabs.com
xergioalex