GraphQL

Write an awesome doc for GraphQL. A very nice an practical one extracted from GraphQL official documentation.

View on GitHub
# Query language
A structured way to request specific data or operations from an API.
Allows clients (e.g. web or mobile apps) to ask for exactly the data they need from the server by writing queries.
# GraphQL operation
The thing that the client sends to the GraphQL server.
# Server-side runtime
The environment and processes on the server that interpret and execute GraphQL queries.
The GraphQL server-side runtime is a specific layer within the backend.
A specialized component of the backend.
# Type system
A structured definition of the data types, fields, and relationships available within the API.
Acts as a blueprint for both the client and server.
Describes what kind of data can be requested,
          what shape that data will have,
          how different data pieces are connected.
# Scalar value
It comes from linear algebra.
We use it to differentiate a single number from a vector or matrix.
Read more.
# First-class way
GraphQL provides a built-in, standardized, and recommended approach.
# Telemetry data
In general: the automated collection, transmission, and analysis of data related to the performance, status, or behavior of a system, device, or application.
In GraphQL: info about the operation or performance of the GraphQL server during the execution of a query.
Example of extensions response body
# Rate limit consumption
How much of the allocated request allowance (rate limit) a client has used when interacting with an API.
Enforce rate limits to control traffic, and prevent abuse.
Usually maximum number of requests or operations a client can perform within a specific time frame.
# Business domain
In one sentence: Primary area of operation of the company.

E.g., Starbucks is renowned for its coffee, while DHL offers global delivery services.
They can operate in multiple business domains too; e.g. Amazon operates in both retail and cloud computing.
Resembles what we call it core subdomains.

Like a wrapper around everything, a container.
# Building blocks
Different pieces of business can be expressed with many different implementation elements, these elements are called building blocks.
Entities that represent real-world concepts or logical parts of the domain.
Directly create the code in the domain.
Things like:
  • Aggregates.
  • Entities.
  • Policies.
  • Services.
  • Factories.
  • Builders.
  • Domain events.
    • </dd>
    # Custom notation
    Unique or tailored way of representing system components, processes, or workflows that doesn't adhere to standard notations like UML (Unified Modeling Language) or BPMN (Business Process Model and Notation).
    In other word some standards that you establish within your company and team.
    Our custom notation definition; what each shape/symbol means A simple example using the established custom notation
    # Bounded context
    An area of your application which has explicitly defined borders, has its own Model, and maintains its own code.
    Within it everything should be strictly consistent.
    A desirable goal is to align domains 1:1 with bounded contexts.
    Similar with SRP of SOLID
    E.g. book has a very different model in different "bounded contexts":
    In catalog, bounded context is picture, title, authors, rating, etc. In shipping, bounded context is dimensions, weight, international restrictions, etc. In search, bounded context is full-text content, copyright dealing policy, etc.
    So Amazon may have a very complex "book" domain with lots of attributes, BUT only some of them would be relevant in different bounded contexts.

    — Ref
    # Problem space
    A set of all problems that your product can solve.
    A term that defines the needs of customers for a product.
    It's about learning what kind of problems a user have. Then we can determine what the product needs to do.
    Best way to find a problem space: talking to real people and listening carefully.
    The foundation of a solution space.
    Also look at problem space VS solution space.
    # Solution space
    A set of all solutions that solve any given problem..
    Anything that depends on or is built upon the problem space.
    Things like mockups, prototypes, and wireframes.
    Also look at problem space VS solution space.
    # Origin
    A combination of a URL's domain (host), protocol (schema), and port.
    Identifies where a request is being made from.
    Determines whether a request is cross-origin or same-origin.
    # AS
    Stands for Apollo Server
    # Indirection
    Useful and simple technique.
    Decouple software units by introducing a layer between two existing units/layers.
    Enable you to introduce a new behavior, without directly impairing the existing units.
    E.g., your application needs to read some persisted data, instead of spreading the knowledge of how and from where your app can read all throughout the application.
    Isolate it (put that reading of data into a new layer called repository) and then let all of the other parts of your application call that method to get the data instead of each part of the app having to deal with those details itself.
    Learn more:
    </dl> ## Problem space VS solution space ![Let's say you want to build a product for managing meetings and appointments. Your product could be used to manage meeting rooms, conference rooms, and other spaces where people meet up. It could also be used to schedule appointments with customers and clients, which would fall under the “meeting management software” category. The first use case falls under the problem space, while the second use case falls under the solution space.](/graphql-js-ts/docs/assets/problem-space-solution-space.png) — [Ref](https://userstorymap.io/problem-space-vs-solution-space/).