Canopus 0.1.1
The fast, unopinionated and minimalist GraphQL web framework for Python.
License: MIT
Requires Python: >=3.8

# [Canopus GraphQL]()
[![Build Status](https://github.com/canopusgraphql/canopus/workflows/tests/badge.svg)](https://github.com/canopusgraphql/canopus/actions)
[![codecov](https://codecov.io/gh/canopusgraphql/canopus/branch/main/graph/badge.svg?token=US3LIA8EI9)](https://codecov.io/gh/canopusgraphql/canopus)

Canopus is a performant [ASGI](https://asgi.readthedocs.io) web framework that makes
building GraphQL servers faster.

## Why Canopus?
A lot of the time, people ask the same question- Why use Canopus when you can already
make a GraphQL API with Flask/Django? Firstly, because GraphQL is meant to be *an
alternative to REST*, it makes more sense to have a GraphQL web framework. If you relate
to Flask/Django as a web framework which helps in making RESTful APIs, you can relate to
Canopus as a web framework which helps in making GraphQL APIs. When GraphQL became
popular, the community started building APIs with existing RESTful frameworks like
Flask/Django. These frameworks were specifically designed to make building REST APIs
easier. This is why making a GraphQL API with it is relatively harder, compared to
creating a RESTful API. Most of the RESTful web frameworks you'd find will bring you
into a synchronous environment, mostly because it's ideal for RESTful services. That's
not the case for GraphQL applications, however.

> GraphQL inherently wants to work at a concurrent environment because the whole
> purpose is, 'I can access data along the graph and load it concurrently,
> hypothetically in a lot of cases.'

GraphQL plays really well in a concurrent environment, but this will be very hard
if supported in frameworks like Flask/Django, given their nature and philosophy.

You'd find a myriad of tools for creating RESTful services in and around these
frameworks - like routing and views. The amount of GraphQL libraries you'd find, on the
other hand, will be relatively low. This is because *the GraphQL ecosystem cannot grow
inside an existing RESTful ecosystem*. If GraphQL is an alternative to REST, we need to
see it having its own and dedicated set of web frameworks/ libraries.

This marks the advent of GraphQL web frameworks - Canopus is the first of its kind.
Canopus gives you a fully fledged toolkit that helps you build GraphQL servers faster.
It is fully compliant with the [ASGI](https://asgi.readthedocs.io) spec, letting you
work in a concurrent environment and giving you the liberty to make non-blocking calls
to batch-load data, with the standard asyncio library. It boasts a performant schema
builder that makes it easy to build and test your GraphQL schema. It also provides
what a standard web framework gives you - sessions, caching and more.

## Proposed Features

- asyncio Python 3.8+ codebase with [typehints](https://docs.python.org/3/library/typing.html)
- optimized to be fast and scalable
- minimalist and unopinionated API
- follows a code-first approach to building schemas
- built-in support for caching and batch-loading
- data-agnostic. Pull data in from any data sources
- sessions support out of the box
- query batching support (for use with
[Apollo-Client](https://github.com/apollographql/apollo-client))
- complete support for the [relay](https://github.com/facebook/relay) spec
- fully compatible with the [ASGI](https://asgi.readthedocs.io) spec

## Installing

Install and update using [pip](https://pip.pypa.io/en/stable/getting-started/):

```text
$ pip install -U Canopus
```

## Contributing

This project is open for contributions! Make sure to read the
[contributing guidelines](CONTRIBUTING.md) to get started.