Skole Backend 🎓

This is the GraphQL backend for the Skole app.

Also check out the README from skole repo.

See detailed description for all top-level dependencies in dependencies.md file.

What's Inside? 🧐

A quick look at the top-level files and directories excluding Git ignored locations.

1. .github/: Configuration for Github Actions.
2. .idea/: Jetbrains editor configuration.
3. config/: Configuration for Django project.
4. media/: Few media files for testing.
5. skole/: Source code.
6. .dockerignore: List of files not sent to Docker build context.
7. .flake8: Configuration for Flake8.
8. .gitattributes: Additional Git repo metadata.
9. .gitignore: List of files ignored by Git.
10. .graphqlconfig: GraphQL configuration file, used by JS GraphQL JetBrains IDE plugin.
11. Dockerfile: Formal instructions for Docker how to build the image for the app.
12. README.md: The file you're reading.
13. dependencies.md: Documentation about the project's top-level dependencies.
14. manage.py: Auto-generated for a Django project, see docs.
15. mypy.ini: Configuration for Mypy.
16. pyproject.toml: Lists project's PyPI dependencies and contains configuration for various Python tools.
17. schema.graphql: GraphQL schema for noticing schema changes quickly from PRs.

Development Tips 🚀

• No pull requests can be merged without CI pipeline first building and running Dockerfile against it. See the CMD of the ci stage for the full list of stuff it runs and validates. The CI pipeline also verifies the code style, so there is no need to argue about formatting.

• Use Google style docstrings.

• All assert statements are just for type checking or for generally helping the developer. They should not be used for actual program logic since they are stripped away in production with the use of the PYTHONOPTIMIZE=1 env variable.

• Inherit all models from SkoleModel or TranslatableSkoleModel.
• Inherit all managers from SkoleManager or TranslatableSkoleManager.
• Inherit all forms from SkoleForm, SkoleModelForm, or SkoleUpdateModelForm.
• Inherit all mutations from SkoleCreateUpdateMutationMixin or SkoleDeleteMutationMixin.
• Inherit all GraphQL object types from SkoleObjectType.
• Inherit all graphene-django object types from SkoleDjangoObjectType.

• Do not access any "private" names starting with an underscore _ outside the class or module where it's defined, without a very good reason.

• Do not manually call Model.save() outside of model files. It's fine to call save() on a ModelForm to save the instance though.

• Sometimes Mypy doesn't understand a type, and that's completely fine. In these cases ignore only the specific error with # type: ignore[err-name] AND write a comment starting with # Ignore:  on top of it, which explains why the ignore was needed.

• All monkey patched code affecting 3rd party modules should go into patched.py. The compatibility of the patched code should also be verified with a test in test_patched.py.

• Since _ is reserved as an alias for Django's translation functions, use a double underscore __ for ignored values, e.g. foo, __ = Foo.objects.get_or_create(...) or [bar() for __ in range(n)].

• All GraphQL queries should be documented in their resolver docstring. All mutations should be documented in their class docstring. This info is shown in GraphiQL docs, together with information automatically taken from the actual code (see SkoleObjectTypeMeta for details).

• Use the @login_required decorator defined in skole.overridden instead of the one in graphql_jwt.decorators. The former automatically adds authorization required information to the API docs.

• Whenever you add fields to User model, or relations to settings.AUTH_USER_MODEL, make sure to add those to MyDataMutation in skole.schemas.gdpr.

• It's fine to use PostgreSQL specific Django utilities, such as ArrayAgg. They can make life a lot easier, and we can assume that the application is always run on Postgres.

• Don't use relative imports (from .foo import bar) outside of __init__.py files.

• Use @test.test for all email addresses when testing/developing. This makes their intent very clear since .test is not a valid TLD. Also, test.test has been whitelisted in settings.ALLOWED_EMAIL_DOMAINS.

• Use from __future__ import annotations in all non-empty source files to guarantee forwards compatibility with PEP-563.