How Helium and ProdigyView Is Designed For Startups

To begin this article, it is important to reference the article Programming Principles For Early Stage Startups. The tools a startup uses and how they choose to build their tech stack will determine how the company is able to scale, react to changes and decrease technical debt.

These principles will largely govern the thought process and architecture choices behind how to use Helium MVC. The focus of this article is why Helium is better suited for startups and micro-applications and how you can apply the principles when building your company.

Virtual Schema For Better Database Design

Every model in Helium is tied to a virtual schema, which is a representation of the actual table and columns in the database. The virtual schema has built-in features such as auto-creating the fields in the database, sanitizing data, performing joins and protection against data outside the schema. But the virtual schema also designed to help developers put more thought into their database design.

Similar to a UML diagram, the Virtual Schema depicts how a model acts in relation to other models in your application. A recommended development approach is too:

1. As you begin coding your application, first create all the models needed, including pivot tables.
2. As you create models, carefully think about the columns and their data types.
3. For each model, create the joins and how they relate to other models.
4. Review the indexes and primary keys of the models.

By taking this approach before writing the application, Helium’s goal is to help the developer think through the schema, which is much harder to change than the code.

Team Sets The Level of Complexity and Architecture

Some frameworks force the developers to use a Facade Design pattern, some use Factory, other require Service Locators. Some are incredibly simple in their approach and others can be overcomplicated. The developer is left without much choice.

Helium was first designed to allow the team to choose how they want to structure their application. Looking through the example sites, you will notice there are different strategies used.

• Site 1 focuses on having fatter models with the business logic residing there. The technology used is VueJS and Mysql.
• Site 2 focuses on having more of the business logic in the services, creating a different separation of concerns. The technology used is Angular, Postgresql, Redis and Mongo.
• Site 3 utilizes a lot of Factories, Facades, and microservices to achieve its goals Technology used is Redis, Firebase and Twig.

While each of the sites are examples of how to build your application, they want to give engineers more insight into different ways to develop a product in relation to the businesses needs. The level of complexity should be based upon the team’s decision, not the framework being used. For startups, this is crucial in how fast they will be able to scale and the reduction of technical debt.

Provides Great Base Functionality

During development, one way to waste valuable time is re-write basic functionality that is NOT unique to the application you are building. Because Helium is built on ProdigyView’s toolkit, many basic operations in PHP that require several steps to execute have been compressed into a single step. Take for examples, getting a files mime-type:

<?php
$file = ‘/path/to/file’;
$finfo = finfo_open(FILEINFO_MIME_TYPE, null);
$mime_type = finfo_file($finfo, $file);
finfo_close($finfo);
echo $mime_type;
?>

This is very easy to implement but not something as a developer you want to focus on understanding how finfo works and is not unique to your codebase. ProdigyView’s toolkit makes it simple by writing:

<?php
$file = ‘/path/to/file’;
$mime_type = PVFileManager::getFileMimeType($file);
?>

The toolkit takes it a step further by making it compatible with legacy versions of PHP and to check if a hosting provider has not installed certain packages. The PVFileManager::getFileMimeType method has several fallbacks like so:

<?php
$mime_type = '';
$file = '/path/to/file';
if (function_exists(‘finfo_open’)) {
   $finfo = finfo_open(FILEINFO_MIME_TYPE, $options[‘magic_file’]);
   $mime_type = finfo_file($finfo, $file);
   finfo_close($finfo);
} else if (function_exists(‘mime_content_type’)) {
   $mime_type = mime_content_type($file);
} else {
  ob_start();
  system(“file -i -b {$file}”);
  $buffer = ob_get_clean();
  $buffer = explode(‘;’, $buffer);
  if (is_array($buffer))
  $mime_type = $buffer[0];
}
return $mime_type;
?>

The Toolkit is ensuring that you are going to get a mime type. Several of the features in ProdigyView have the same kind of abstraction of basic lower level tasks, allowing developers to focus more on writing unique and specific code for the application.

Highly Targeted Inversion of Control

Inversion of Control (IoC) is the ability to extend an application without modifying the code that causes side effects. You can read more about Inversion of Control Principles here.

Normal IoC is implemented through Dependency Injection, which requires writing interfaces and replacing an entire class. Helium focuses on IoC through Adapters and Observers, which is focuses on the method level.

For example, the above method PVFileManager::getFileMimeType, you can rewrite the method by:

PVFileManager::addAdapter(‘PVFileManager’, ‘getFileMimeType’, function($file) { 
     return my_unique_mime_type_finder($file);
 }, array(‘type’ => ‘closure’));

And that’s its that simple to have your own custom function in place of the original!

For startups, completely rewriting custom class, especially when the change can considerate to one method, can be time-consuming and lengthen sprints. Heliums approach of a single method is a quicker and more targeted approach to IoC that has more value to startups with limited bandwidth.

Microservice Approach And Global Enforcement

One of the first observations that might be noted is because Helium utilizes ProdigyView, there is the use of static methods in places. Please keep in mind, static methods are NOT REQUIRED but is an optional approach. If you are hesistant to static methods, please read Debunking The Myth Of Static Classes, Methods and Variables.

The reasons behind this design approach is assumptions about a micro-services needs being global and simple.

Large monolithic codebases often require several strategies to accommodate multiple uses in an application. For example, there might be several types of encryptions being used throughout the application:

• Database data might be encrypted in AES-128
• Session data might be encrypted 3DES
• API calls might be encrypted in RSA

This creates higher level complexity and longer development cycles. Microservices often require much less complexity, ie only one encrypting/decrypting algorithm needed because the application has a singular focus vs multiple focuses.

As such, the framework focuses on enforcing a global approach to standardizing tasks. For example, all classes in the microservices will accomplish encryption like so:

<?php
$text = ‘ABC 123’;
$encrypted = PVSecurity::encrypt($text);
$decrypted = PVSecurity::decrypt($encrypted);
echo $decrypted ;
?>

With the adapter pattern built-in to create an inversion of control, the developer can re-write how the algorithms work, but the functionality is still global for the application. If you find that a microservice starts becoming very complex and requiring many dependencies and approaches, consider breaking into other services. And again, using a static approach is NOT REQUIRED.

Getting Started With Helium

The key takeaway is that development tools work differently for organizations at different stages. Some are more complex and make it hard to get started and scale, others are two simple require a rebuild relatively quicky. Heliums goal is to have the complexity and needs fit the business, and not the business try to fit itself into the framework.

If you are ready to give Helium a try for your startup or a fun application, header over to https://github.com/Helium-MVC/Helium.