• Problem: REST is a standard way to communicate with servers to retrieve data. It provides a specification based on the entities that we have present in our database. When done correctly, it can be more than adequate. When done wrong it can be a living hell.
  • Solution:
    • Implement HATEOAS [what is HATEOAS?] (Hypermedia as the Engine of Application State), and get a nice system that is flexible and easy enough to work with
    • more simple alternatives like GraphQL
      • GraphQL is an open-source project from Facebook that presents power with a simple idea… Instead of the application server defining the structure of responses, the client is given power and flexibility to request the data that it needs. GraphQL responses are tailored to the specific use case that the client is implementing, eliminating wasteful data transfer and providing future-proofing your API for use cases that your application hasn’t even encountered yet.
      • Is GraphQL a flash in the pan? Technology is hard to predict, but Github’s recent preview launch of their GraphQL API is super encouraging, and an interesting study.
  • Open Questions:
    • How to combine GraphQL with a Event Driven backend?
      • One query actually might indicate multiple events …
      • GraphQL might be a good candidate to implement Event Sourcing/CQRS pattern. Just the fact that GraphsQL allows two different query types – Queries and Mutation is a conceptual direct map to the basics of the Event Sourcing pattern of separating the reads and writes, gives a good foundation to explore this pattern, alongside other advantages. [link]

IT Security: keytool vs openssl