• Convention for the SDL - Pending
• Convention for Strawberry Objects - Pending
• Convention for DataLoaders - Pending
• Conventions for the view_model

  1. The folder inside of view_model should have the next structure

     view_model/
     ├─ {table_name}_service/
     │  ├─ graph_ql/
     │  │  ├─ {table_name}.py 
     │  │  ├─ schema.py/
     │  │  ├─ test/
     │  │  │  ├─ {table_name}_test.py
     

     • File {table_name}.py This only returns strawberry objects, we need to validate the permission before requesting the information.
     • Folder schema
     • Folder Test (Pending)

  2. If a model is used off the side of the model's folder should use the alias Model. This is only to prevent confusion with the Strawberry Objects and Schema Objects

     • Example

  3. We need to create enums at this level? We have something like this CandidateSortBy but that is in view level, we need to define the way to send that information to query:

     1. We want to check and parse that in a dictionary

        dict_to_filters = {...}
        if [CandidateSortBy](<https://github.com/apploitech/python_api/blob/integration/graph-ql-mvp/graphql_gateway/schema/candidate.py#L43>).LAST_NAME != variable_from_input:
        	dict_to_filters.update({"sort_by": "surname"})
        

     2. We can create an enum similar to CandidateSortBy but in another part off of the view and used it.

• Convention for the queries

  1. The folder for queries should have the next structure

     model/
     ├─ queries/
     │  ├─ {table_name}.py 
     │  │  ├─ test/
     │  │  │  ├─ {table_name}_test.py
     

     • The {table_name}.py is a query builder for the creation of the query, and we need to create the class {tabla_name}QueryBuilder, that implements the class Pending.

       • The name of the Class should use the name of the model and not the method used in the view

         #expected
         class ApplicationFormQueryBuilder
         #unexpected
         class ApplicationQueryBuilder
         

     • The public methods only can return results, we can’t return any query offside of the model.

     • The filters are implicit when the method is created. For that reason, we need to put a comment in the class with the filters that we can support.

       • Example
       • Example: The name of the filters should be similar to the model

     • If a filter has an unexpected typing we need to raise an error.

Notes

• We have the Authorization to manage the permission and with the token info (In Draft)
  • We can find teams like reference of team_ids.
    • We don’t know if team_ids is used for something and maybe we need to delete it
  • We can find the team like the reference of team_id.