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

flow-mm content revision

This commit is contained in:
Ray Elliott 2020-02-18 18:56:29 +00:00
parent 5caf7ddfaf
commit a58c38a57a
1 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
content/posts/flowmm.md
View File

@ -14,7 +14,7 @@ They were created solely for the purpose of giving me a reason to create their [
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.
And so, my 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.
@ -31,7 +31,7 @@ caption="For this project I wanted to build a **Single Page Application** using
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.
Instead of reloading an entire page, when maybe only one small component of the page needs updating, a browser may request only the much smaller data needed to update that component.
So, once the initial page is loaded, the amount of data that needs to be transmitted can be greatly reduced.
@ -53,16 +53,14 @@ A major 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.
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.
One solution is to render the HTML on the server, rather than letting the browser do it.
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.
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.
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.
To name a few:
There are also a number of pitfalls and considerations that need to be kept in mind:
* there are no requests for new pages and so the browser history needs to be managed,
* there are many threats of security vulnerabilities and exploits,
@ -84,6 +82,7 @@ For example, it may be decided in future that the features commonly found in **P
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