rayelliott
/
hugo-blog
Archived
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

second draft

This commit is contained in:
ray 2020-02-09 15:57:38 +00:00
parent 46e3a1b1e2
commit 46b8a28c59
1 changed files with 56 additions and 126 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

182
content/posts/flowmm.md
View File

@ -7,159 +7,89 @@ featured_image: "/images/flowmm/flowmm-home.jpg"
draft: true
---
**Flow Model Management** are a fictitious modelling agency. They were created
as an ... .
**Flow Model Management** are a fictitious modelling agency.
They were created solely for the purpose of giving me an excuse to create their [website](https://flowmm.rayelliott.dev).
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.
However, despite being imaginary, the owners of Flow Model Management felt that it was about time their business should have an internet presence.
And so, discussions with the stakeholders began.
It quickly became apparent that the primary purpose of the proposed website would be to provide an attractive and stylish platform that would encourage visiting candidates to apply to join.
Essential to this, would be to provide a simple process for users to submit an application.
## 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.
For this project I wanted to build a **Single Page Application** using [Nuxt.js](https://nuxtjs.org/), which is an open source framework based on [Vue.js](https://vuejs.org/).
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.
One advantage of an SPA is speed.
SPAs are fast.
Instead of reloading an entire page, when maybe only one small component of the page needs updating, a client may request only the much smaller data needed to update that component.
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.
So, once the initial page is loaded, the amount of data that needs to be transmitted can be greatly reduced.
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.
This 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 lengthy page reloads typically associated with websites.
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.
**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.
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.
However, Vue along with other SPA frameworks do have some disadvantages.
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.
The main disadvantage is regarding **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.
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.
This means sites requiring SEO, need to take steps to mitigate these issues.
One solution is to render the HTML on the server, rather than the client.
The HTML can be quickly displayed by the client browser, reducing the initial page load, with updates to the site being handled by Ajax calls, as with a conventional SPA.
## The Back End
This may be taken even further, if desired, so that *all* pages are rendered on the server. In effect, creating a static site.
This will then bring all the benefits of a fast, easily indexable static site.
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.
These, **Server Side Rendered** applications can require a lot of setting up
There are also a number of pitfalls and considerations that need to be kept in mind.
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.
For example, as there are no requests for new pages, the browser history needs to be managed.
There are many threats of security vulnerabilities and exploits.
Although browser standards have improved over time, there are still a number of differences in behaviour between the many devices and browsers in use.
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.
This is where a framework such as **Nuxt.js** comes in.
A lot of the tedious scaffolding is 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 and tested for.
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.
A further benefit to using Nuxt.js, is the client application can be easily extended.
For example, 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.
With SPAs being an important component of the modern web I wanted this project to further my experience and understanding of the technology and techniques involved.
## 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
simple. A visually appealing, elegant 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
A monochromatic colour scheme was chosen. I felt that a primarily black and
white colour scheme that uses the brand colour of orange would give a classy and
elegant feel to the site.
social links - important, in header, contact form and bottom of home page.
**Montserrat** and **Lato** were the fonts chosen for the headings and body text respectively.
These are both clean, easily readable fonts.
Montserrat was chosen for its classy and elegant qualities.
It is formal, but not too formal, reminding me of the classy, stylish fashions of the early 20th century, and yet still appearing modern.
Lato, which goes well with Montserrat, is also modern and elegant, much like Montserrat, and keeps with the formal but not overly so, feel of the site.
extended future version:
As the site is for a modelling agency, I decided that making the models a prominent feature would be an ideal way to make the site visually appealing.
By bringing the models to centre stage and focusing attention on stylish images of the models, this focuses the aesthetic of the site towards an elegant, stylish look.
stuff learned during project
## The Deployment
stuff I would do different if starting again.
The project is hosted on a **Virtual Private Server**, using [Dokku](http://dokku.viewdocs.io/dokku/).
* the hero - definitely would use SVG clip paths instead.
* login form - have on own page, not just a modal.
**Dokku** is a [Docker](https://www.docker.com/) based, open source, Platform as a Service in which Heroku compatible applications can be deployed to and hosted upon.
Using Docker during development has many advantages.
The main one being that it encapsulates the application within a consistent environment.
This allows for the development environment to exactly match the environment it is deployed to, ensuring there will be no compatibility issues after deployment.
Combining Docker with Dokku also allows for simple deployment, which can be done with just a [Git](https://git-scm.com/) push.