hugo-blog/content/posts/flowmm.md

---
title: "Flow Model Management"
date: 2020-01-31T12:27:18Z
categories: ["Portfolio"]
tags: ["Vue", "Nuxt"]
featured_image: "/images/flowmm/flowmm-home.jpg"
draft: true
---

**Flow Model Management** are a fictitious modelling agency. They were created
as an ... .

Despite being imaginary, the owners of Flow Model Management felt that it was
about time their business should have an internet presence. During discussions
it became apparent that the primary purpose of proposed
[website](https://flowmm.rayelliott.dev) would be to allow potential members to
be able to easily apply online and facilitate the business goal of attracting
new members.

## The Front End

For this project I wanted to build a Single Page Application using Nuxt.js which
is an open source framework based on Vue.js.

One advantage of an SPA is speed. SPAs are fast. Once the initial page is loaded
it is only the data required to update particular components that need to be
transmitted to the client. As this site will be mainly composed of dynamic data,
with little in the way of static content, fetching requested data directly from
the backend servers to update the appropriate components will increase speed.
Rather than requesting entire pages from a web server, which itself needs to
communicate with other back end servers before transmitting an entire page of
data, a simple API request can quickly update a page.

This process of updating a web page through Ajax calls, also has the benefit of
an improved user experience. Navigation and updates to the state of the site
appear to be almost instant, similar to a native application, rather than more
lengthy page reloads.

Vue.js is a modern JavaScript framework for creating web interfaces. It makes
use of the virtual DOM, is small and fast, and is an ideal foundation for an SPA.

One disadvantage of Vue, and other SPA frameworks is in regard to their
suitability for sites that require good Search Engine Optimisation. SPAs can
require a relatively long initial page load, and aren't as efficiently crawled
by search engine crawlers due to the heavy use of JavaScript. A solution to
this is to render the HTML of the site on the server, which can then be
delivered to the client much faster, with further requests to update the site by
the client being handled by Ajax calls (????? ensure this is correct ?????).
This can be taken further, if desired, so that all pages can be rendered on the
server to create, in effect, a static site. This eliminates the SEO issues that
may affect an SPA.

Server Side Rendered applications can require a lot of setting up and there are
a number of pitfalls and ... that need to be taken care of and kept in mind.
For example, as there are no requests for new pages, then the browser history
needs to be managed. although browsers are better at sticking to common
standards than in the past, there are still a number of differences between the
many devices and browsers that this is not always straightforward. The threat of
security vulnerabilities and exploits also need to be kept in mind. This is
where a framework such as Nuxt can become valuable. A lot of the tedious
scaffolding is already taken care of and being a fully tested, mature framework,
we can be confident that many common, and not so common, issues have already been
solved.

A further benefit to using Nuxt, is the client application can be easily
extended to other functionality. It may be decided in future that the features
commonly found in Progressive Web Applications are desired, in which case these
can be more easily added due to already being supported by Nuxt.

So, above, are the reasons I would use to justify using Nuxt.js to build an SPA
for this project. However, a very large factor, to be entirely honest, was
that I had been gaining experience in using Vue.js and wanted an opportunity to
use Nuxt.js to create an SPA with server side rendering. SPAs are an important
component of the modern web and this project was useful in gaining further
experience and understanding of the technology and techniques involved.

## The Back End

For the backend I decided to use October, a Content Management System, based
on the Laravel framework, which itself is a popular, open source PHP based
framework.

The main requirements of a backend for this type of project involve user
creation and management and the ability for those users to upload and manage
content in the form of profile information and images. A perfect fit for a
Content Management System.

It would be possible to create a fully bespoke CMS to handle these requirements.
However, this would involve a considerable amount of work and a lot of
considerations, such as security best practices, browser compatibility, testing 
of code, etc.

Fortunately, there are already a number of libraries and frameworks available,
that have already solved these issues, been tried and tested with real world use
by many users, and are in active development. Using one of these shortens
development time considerably, whilst also ... safe and secure.

So for a CMS, in which there are no particularly special requirements, it makes
perfect sense to build upon an existing platform that has already solved the
challenges involved in creating a CMS and been fully tried and tested.

October, based on Laravel, is an ideal candidate.

Performant - isn't bloated with unneeded functionality. It instead provides a
base in which features and functionality may be added if required. This makes it
faster than some alternatives, such as WordPress for example, which can suffer
from having a large amount of features included as a base. Also has useful
default features such as minification of CSS and JavaScript. The templating
engine (TWIG) generates static HTML.

Developer oriented - is targeted towards developers. High quality documentation
and a clean and modern codebase makes it easy to extend and add functionality.
Plugins are entirely separate - have own database and namespaces preventing
conflicts between them. The templating system and text file based website
structure allows for separation of data and presentation and gives easy version
control management.

There is a large developer community. This means a large number of plugins and
themes provided by the community. Not as many as WordPress but many of the
WordPress plugins can be considered to be poor quality, particularly among the
free ones. It can also be difficult to extend WordPress plugins.

Secure when compared to alternatives like WordPress. Only one file that can be
accessed - `index.php`. There is a more rigorous approval process for plugins and
themes.

Administrative interface customisation. This is very useful for a site that will
involve a lot of users with the ability to manage their accounts.

These reasons are why I consider a platform like October to be better for
building a backend CMS than, for example WordPress - it is easier to customise
and add the required functionality without the inherent bloat.

Having said that, it may sound like WordPress just isn't very good when compared
to something like October. This, however, just isn't true. WordPress is very
good at what it actually is - a platform that allows users, who may have limited technical
ability, to publish a website. For this it is very successful, after all it
powers XX% of the world's websites. However, it is also a victim of its own
success. It is a very high profile target with a lot of effort expended in
finding exploits and vulnerabilities. That, combined with its start as solely a
blogging platform, with CMS features bolted on over time, can make leaner, more
focused alternatives more appealing to developers.


## The Design

The design brief from the non-existent owners of Flow Model Management was quite
simple. A visually appealing site, with some background information and an easy
to use method for applicants to sign up with.

black and white - classy and has a good contrast with the orange brand colour.
newest members - encourage users to sign up

social links - important, in header, contact form and bottom of home page. 



extended future version:

stuff learned during project

stuff I would do different if starting again.

* the hero - definitely would use SVG clip paths instead.
* login form - have on own page, not just a modal.