# Geoximity

## Stack

The tech stack to use in the backend will be:

- Django >= 2.2.6
- Django ORM mixed with SQLAlchemy
- Celery
- Django-rest-framework

The tech stack to use in the frontend will be:

- Vue 2

## Components

### DB

#### Current status

The main DB is a PostgreSQL (PostGIS). The data is managed through Django framework with the ORM.

#### Drawbacks

TBD

#### Solution

The main DB will be a PostgreSQL (PostGIS). The data will be managed with a mix of SQLAlchemy and Django ORM.

### Models

#### Current status

The Proximity's model changes for each client, the main core is re-used but there are many differences between clients.

#### Drawbacks

- Problems with the code, it's little scalable and a mess.
- Every new custom field for a specific customer will add a new column for every customer, even when this column won't be used

#### Solution

The Proximity's model changes for each client, the main core is re-used but there are many differences between clients, because of this it's needed to build a dynamic model, these models can be developed using a set of pre-defined fields or using a third-party packages as:

- django-mutant
- eav-django
- django-hstore

After the last discussion, we won't use special packages, JSON or HSTORE. We will use meta-models that overwrite the Django's base model in order to add custom fields, these custom fields will be set by a custom configuration. The following code shows an approximation of the solution:

from django.db.models.base import ModelBase
from django.db import models


CONF = {
    'aux_str_1': {
        'name': 'zone_name',
        'type': models.CharField(max_length=200, db_column='aux_str_1')
    }
}


class ShopMetaClass(ModelBase):
    def __new__(cls, name, bases, attrs):
        for field in CONF:
            attrs[CONF[field]['name']] = CONF[field]['type']
        return super(ShopTestMetaClass, cls).__new__(cls, name, bases, attrs)


class Shop(metaclass=ShopMetaClass):
    name = models.CharField(max_length=200)

> Luis comment on 2019-10-16
>
> I was thinking in something more similar to the following. Field types and
> initialization should not be editable, just fields involving no database
> operations.
>
> ```python
> from django.db.models.base import ModelBase
> from django.db import models
>
> CONF = {
> 'aux_str_1': {
> 'name': 'zone_name',
> 'kwargs': {
> "max_length": 32
> }
> },
> 'aux_fk_1': {
> 'name': 'updated_by',
> 'kwargs': {
> 'to': 'auth.User'
> }
> }
> }
>
> class ShopMetaClass(ModelBase):
>
> class AdvertCustomFieldTypes:
> TEXT = {
> "field": models.TextField,
> "enforced_kwargs": {},
> "default_kwargs": {"max_length": 256},
> "db_columns": set(`aux_str_{x}` for x in range(1,5))
> )
> INTEGER = {
> "field": models.IntegerField,
> "enforced_kwargs": {},
> "default_kwargs": {},
> "db_columns": set(`aux_int_{x}` for x in range(1,5))
> )
> FOREIGN_KEY = {
> "field": models.ForeignKey,
> "enforced_kwargs": {"db_constraint": False},
> "default_kwargs": {},
> "db_columns": set(`aux_fk_{x}` for x in range(1,5))
> )
>
> @classmethod
> def field_types(cls):
> return sorted(x for x in dir(cls) if isintance(x, dict) and 'field' in x)
>
> @classmethod
> def db_columns(cls):
> return sorted(chain(*(getattr(cls, field_type)['db_columns'] for field_type in cls.field_types)))
>
> @classmethod
> def attr_field_type(cls, attr_name):
> for field_type in cls.field_types:
> if attr_name in getattr(field_type, field_type)['db_columns']:
> return field_type
> raise AttributeError('Field not found')
>
> @classmethod
> def attr_field_conf(cls, attr_name):
> field_type = cls.attr_field_type(attr_name)
> return getattr(cls, field_type)
>
>
>
> def __new__(cls, name, bases, attrs):
> # In order to have properly working transactions, we have to add
> # all fields to the model, even if they are not used.
> for column_name in AdvertCustomFieldTypes.db_columns:
> field_conf = AdvertCustomFieldTypes.attr_field_conf(column_name)
> kwargs = field_conf['default_kwargs']
>
> if column_name in CONF:
> attr_name = CONF[column_name][name]
> kwargs.update(CONF[column_name]['kwargs'])
> else:
> attr_name = column_name
>
> kwargs.update(field_conf['enforced_kwargs'])
> kwargs['db_column'] = field_name
>
> attrs[attr_name] = field_conf['field'](**kwargs)
>
> return super(ShopTestMetaClass, cls).__new__(cls, name, bases, attrs)
>
>
> class Shop(metaclass=ShopMetaClass):
> name = models.CharField(max_length=200)
> ```

#### Other solutions

- Use JSON fields (performance it's not bad at all).
- Use a NO-SQL DB.

### API

#### Current status

The project uses django-rest-framework.

#### Solution

The project will use django-rest-framework. It can be useful use drf-yasg as Swagger automatic provider.

### Extensibility

#### Current status

Each client has a different instance with their models and their business logic.

#### Drawbacks

- In order to not repeat code, you must know every client models and logic.
- Not maintainable.

#### Solution

Maybe, the best approach is creating a new Django application for every client, these apps will use the core models and specific models, but all models are accesible always.

After the last discussion, we will use the signals system in order to inject attrs to the serializers and inject data to the core data retrieved.

### Apps management

#### Current status

Each client has a specific instance deployed with the apps that needed.

#### Solution

The idea behind this component is allowing to activate or deactivate some apps (understanding that the business logic is encapsulated under an app).

After the last discussion, all features are available for all clients, the startup of these features will be determined via data extracted from the DB for each client.

#### Info

In Django 2.2, we can do some operations in order to load apps (https://stackoverflow.com/a/57897422).

### User management

#### Current status

The users are managed by the Django framework.

#### Solution

The users users will continue to be managed by the Django framework.

### XY integration

#### Current status

The XY integration is used for some features through the util.

#### Solution

Maybe, a more elegant solution can be used XY as standalone application.

After the last discussion, maybe will be needed an XY refactor to share the geospatial model with Proximity, in this way, the performance will be better because we use the DB directly without using an API.

### Multi-tenancy

#### Current status

There is not a multi-tenancy system. The Django's "site framework" seems to be used.

#### Drawbacks

- The "site framework" helps but it doesn't give you the necessary to be a completed multi-tenant system.
- Though Django provides some mechanisms in order to use multiple databases (https://docs.djangoproject.com/en/2.2/topics/db/multi-db/), these mechanisms are not linked with the "site framework" but thanks to some ugly hacks we can force the link between sites and multi-databases (https://stackoverflow.com/a/12353583).

#### Solution

After the last discussion, initially we will deploy multiple instances, it can be very interesting to use global info for the site info and other shared data (geospatial data shared with XY).
With the previous approach (using the site framework), there will be problems with the feature load, if this load is determined by the settings is complicated to use because the load is executed at the start and not at runtime.

#### Other solutions

- Use a third-party package as:
- django-tenant-schemas
- django-tenants
- django-multitenant
- Deploy a standalone instance with some apps enabled only.

#### Info

- https://buildmedia.readthedocs.org/media/pdf/building-multi-tenant-applications-with-django/latest/building-multi-tenant-applications-with-django.pdf

#### Examples

DATABASES = {
    'bk': {
        'NAME': 'bk',
        'ENGINE': 'django.db.backends.postgresql',
        'USER': 'postgres_user',
        'PASSWORD': 's3krit'
    },
    'bmw': {
        'NAME': 'bmw',
        'ENGINE': 'django.db.backends.postgresql',
        'USER': 'postgres_user',
        'PASSWORD': 's3krit'
    },
}

class BKRouter:

    def db_for_read(self, model, **hints):
        if model._meta.app_label == 'bk':
            return 'bk'
        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == 'bk':
            return 'bk'
        return None
        
DATABASE_ROUTERS = ['path.to.BKRouter',]

Using multiple databases with site trick:

DATABASES = {
    'default': {
        'NAME': 'default',
        'ENGINE': 'django.db.backends.postgresql',
        'USER': 'postgres_user',
        'PASSWORD': 's3krit'
    },
    'bmw': {
        'NAME': 'bmw',
        'ENGINE': 'django.db.backends.postgresql',
        'USER': 'postgres_user',
        'PASSWORD': 's3krit'
    },
}

def get_current_site():
   SITE_ID = getattr(settings, 'SITE_ID', 1)
   site_name = Site.objects.get(id=SITE_ID)
   return site_name

class BMWRouter(object):

  def db_for_read(self, model, **hints):
     site_name = get_current_site()
     if site_name in ['bmw']:
         return 'bmw'
     return 'default'

  def db_for_write(self, model, **hints):
     site_name = get_current_site()
     if site_name in ['bmw']:
         return 'bmw'
     return 'default'
    
DATABASE_ROUTERS = ['path.to.BMWRouter',]

### Tasks

#### Current status

The tasks are managed by a Django app called django-background-tasks.

#### Drawbacks

- This package has multiple lacks mainly related to the fact that it's not a distributed task queue.

#### Solution

The tasks management will be managed by Celery.

### Tests

#### Current status

The tests are developed under the Django test strategy.

#### Solution

The tests will continue to be managed by the Django's test system, for the e2e tests, we will use a strategy to populate the data in order to test always with "fake-real" data.

#### Other solutions

- Can be useful to use projects as "Tavern".
- Hypothesis.