Blog

Software startup case study. Documenting of the architecture of Mobile Ordering Application (Freewaiter) for restaurants and hotels

About Freewaiter

Freewaiter platform allows to create web and mobile applications for ordering of the food take-out and delivery.

Project prerequisites

Initially metadata was not formally specified. The data structure could be estimated based on database tables and source code. Interfaces for connecting of the external systems were not formally specified as well.

Systems and Applications

There was no reason to define separate Systems in DifHub due to the relatively small size of project.

The following 4 applications were introduced into DifHub: FreewaiterMain (main application used by the restaurant), FreewaiterAdmin (application for the instances administration and monitoring), FreewaiterPartner (application used by the partner company, where partner can see the list of its instances, administer ones and create new instances for the new restaurants) and FreewaiterInstanceCreator (self-service module for the new restaurant registration and launching of the new instance)

Project objectives

  • Introducing current project architecture into DifHub in order to effectively support new outsourced development and seamlessly expand development resources
  • Maintain the most current system architecture description
  • Support agile software development and team collaboration for local and remote developers
Applications list

Datasets

FreewaiterMain application has 45 MySQL tables and some 30 configuration files containing minor sets of serialized data. Tables store restaurants clients’ data, orders and menus. Configuration files contain specific restaurant parameters such as open hours, design elements, payment processors data, premium guest features.

Prior to DifHub the structure of the configuration files was not specified and the only program code did exist.

Partial list of the main application datasets

Metadata transfer

We've built compact converter for exporting of the metadata from MySQL to DifHub which allowed to generate datasets JSON description in the DifHub format accordingly. Only tables structure was exported and conversion of the limited subset of the data types was provided. Keys were introduced to Difhub manually.

Converter allowed to minimize time of the metadata transfer.

The structure for the configuration files was defined from the scratch as no formal description did exist.

{ 
   "identity": { 
      "name": "discounts"
   },
   "structure": { 
      "fields": [ 
         { 
            "identity": { 
               "name": "id_discount"
            },
            "usage": "Column",
            "type": "Integer",
            "size": "11"
         },
         { 
            "identity": { 
               "name": "name"
            },
            "usage": "Column",
            "type": "String",
            "size": "256"
         },
         { 
            "identity": { 
               "name": "total"
            },
            "usage": "Column",
            "type": "Integer",
            "size": "11"
         },
         { 
            "identity": { 
               "name": "discount_value"
            },
            "usage": "Column",
            "type": "Float",
            "size": null
         }
      ]
   }
}
Example of JSON description of the table received from Converter

Publications and Subscriptions

Freewaiter main application publishes 2 datasets specifying: 1) restaurants applications configuration and 2) accounts of the restaurant applications admins. These datasets are used by other Freewaiter applications.

FreewaiterAdmin application publishes the instances table with restaurants applications data. This table is used by FreewaiterPartner and FreewaiterInstanceCreator applications.

There is a strong applications dependency and general tables structure can’t be changed without impacting all Freewaiter applications.

Interfaces

FreewaiterMain application supports the ability of the external applications to address its functions via REST API.

FreewaiterMain\AdminInterface specifies functions for receiving of the orders list and orders handling. It enables third party developer to create his own version of Order Manager application responsible for actual orders administration.

FreewaiterMain\GuestInterface specifies functions for receiving of the restaurant menu and restaurant properties (open hours, address, delivery fees, etc.) and order submission. It enables third party developer to create his own version of the guest application instead of Freewaiter native application or sending orders from the external systems.

Interface specification in Difhub can use internal structures and standard enums defined in the organization. Interface specification uses the most current version of these objects.

Interfaces can be published in Swagger format.

Results

Metadata specs in Difhub will help new developers to get familiar with the existing code and architecture. It will also simplify and streamline all further development. Interfaces specs will be used by developers of the external applications which will be integrated with Freewaiter.

We have got clear understanding of what architecture improvements and advancements are needed.

We also discovered redundant database tables and configuration files which can be removed.

Partial view of Dataset Chart related to the menu
Partial view of Dataset Chart related to the coupons
by Michael Orzhenovsky

You can register and start using DifHub immediately

Try it now