DigiSnaxx Construction

This posts explains how DigiSnaxx is built; so let's go

A basic application, DigiSnaxx is composed of a database (SQLite), a Django server (Python) and VueJS client (JavaScript).

The Database

The database is just a bunch of tables with rows and columns ... and DigiSnaxx has three primary tables for Events, Organizations and Promo.

I'm still figuring out the User and Profile tables, so I'll have to wait to talk about those.

Nonetheless, the idea is that I've built a bunch of webscrapers that visit the websites of venues and I "scrape" the events that they have posted to their website.

This data gets written to may database as an Event, with an Organization attached.

Promo, or advertisements, are also connected to an Organization; though are not automatically connected, or created; that is still a manual operation.

The Server

Next up is the server which has direct access to the database ... I liken it to a restaurant ... the database is the fridge, the server is the kitchen and cook line, while the client is front of house staff.

The server does this via API endpoints that make the database available to the outside world.

We have two primary endpoints at present, /events and /promo; though they are also protected by API keys, which prevent our database being overloaded with calls.

While the /events endpoint takes a series of parameters which allow for a variety of data to be extracted; the parameters being show_date, event_type, and calendar.

The server also describes the data within the database, by describing database models.

For example the Promo database model looks like this:

class Promo(models.Model):
    PROMO_TYPE = (
            ('Ar', '🎨'),
            ('Bv', '🍻'),
            ('Fo', '🥗'),
            ('Ev', '🎟️'),
            ('Re', '🛍️'),
            ('Sv', '📌'),
            ('Ma', '🪢'),
            ('Ca', '🔍'),
            ('Jo', '📝'),
            ('Ja', '✒️'),
            ('Sp', '⚙️'),
            ('An', '🩺'),
            ('Su', '🧩'),
        )

    title = models.CharField(max_length=63)
    organization = models.ForeignKey(Organization, on_delete=models.CASCADE)
    calendar = models.ManyToManyField(Calendar, blank=True, null=True)
    promo_type = models.CharField(max_length=15, choices=PROMO_TYPE, default='Ar')
    promo_image = models.ImageField(upload_to="promo", blank=True)
    short_text = models.CharField(max_length=255,blank=True, null=True)
    long_text = models.TextField(blank=True, null=True)
    target_link = models.URLField(blank=True, null=True)
    notes = models.TextField(blank=True, null=True)
    published = models.BooleanField(default=False)
    tags = models.ManyToManyField(Tags, blank=True)

    class Meta:
        verbose_name_plural = "Promo"
        ordering = ['published', 'organization', 'title',]

    def __unicode__(self):
        return "%s" % self.title

    def __str__(self):
        return u'%s' % self.title

Each item becomes a column, and each Promo record becomes a row.

We start off by making a Python Class, which is modeled after something called models.Model; then we have PROMO_TYPE which is a tuple of tuples. Random, but ok.

Finally we get to something more recognizable ... something called 'title' and this equals something called CharField that has a few obvious parameters.

The organization line creates a ForeignKey which connects the column to another database model for the Organizations; the calendar line allows the Promo db object to connect to multiple Calendar db objects.

Then our promo_type line is also equal to a CharField, but this set of parameters include a choices= options that connects our tuple of tuples.

We've got an image field, which connects to a file path where uploaded images are stored; a few more character and text fields, a Boolean (true/false) field, and then another ManyToManyField for tags.

Lastly we define a few details such as how to order the rows and what to return when either unicode or a string is requested.

The server contains a few other gadgets that enable us to fine-tune how data can be filtered for return, though that is what the server does ... takes a request from the client, and fulfills it by knowing what data is available and how it's organized.

The Client

The client is the one making the requests, the one with the menu, if you will.