alanred400x400

AlanRed400x400

<h3>Introduction</h3>
Beginning of the year saw a big adoption of blockchain technologies and there was much incentives to build a Dashboard that can track cryptocurrency prices and portfolio of digital currencies. In order to get up and running fast and cost effective I started researching for suitable Backend stack (CMS, Database, API).
Project scope was simply to provide fast user experience with Public data (currency prices) and Personalized data (collection of transactions). While I was satisfied with Frontend stack built on Vue/Nuxt, the goal was to find low-code, scalable, database driven, cloud agnostic, modular Backend stack with REST/GraphQL API access.
&nbsp;
<h3>Requirements</h3>
Public portion of site should be accessible to all while Private parts  should be accessible and personalized for given user. MFA authorization, overall stack security and data privacy is a priority.
&nbsp;
<h3>Problem</h3>
First option was to leverage existing experience and off-the-shelf solutions within WordPress ecosystem. While there were working cost-effective options, most notable limitations were only one private page/view per user, relatively slow response times, no convenient way for horizontal scaling and lack of modern client side features.
&nbsp;
<h3>Solutions</h3>
After spending fair amount of time researching various services, ended up testing two solutions: AWS Amplify and Strapi CMS.
<img loading="lazy" class="wp-image-14637 alignleft" src="https://cvapi.monolit.me/wp-content/uploads/2021/12/amplifyLogo-200x169.png" alt="" width="119" height="101" srcset="https://cvapi.monolit.me/wp-content/uploads/2021/12/amplifyLogo-200x169.png 200w, https://cvapi.monolit.me/wp-content/uploads/2021/12/amplifyLogo.png 466w" sizes="(max-width: 119px) 100vw, 119px" />
1. AWS Amplify its a great set of high-level tools that automate deployment and configuration of many services hosted on AWS cloud. Amplify UI provides data modeling tools, database management, CMS, API deployment, user authentication, front-end development guidelines and much more.
&nbsp;
<img loading="lazy" class=" wp-image-14639 alignleft" src="https://cvapi.monolit.me/wp-content/uploads/2021/12/strapiLogo100x100.jpg" alt="" width="118" height="118" />
2. Strapi is open-source, self-hosted headless CMS built on Node and React. It provides UI to create custom data models, manage API endpoints, manage content and user administration without writing any code. Can run with PostgreSQL or other databases and allows customization by modules/plugin system.
&#8211; &#8211; Unfortunately at the time of research (May 2021) Amplify&#8217;s was still in development and UI that manages data models in DynamoDB instance was not working properly (once DB services were deployed, Amplify UI could not access/modify them). Ended up running Strapi.
*Late 2021 update: 
AWS Amplify just released stable version and introduced outstanding features, most notable ability to convert (Figma) UI designs to (React) components. 
Strapi released version 4 with lot of improvements, most excitements are around new Plugin system.
&nbsp;
<h2>Implementation</h2>
<h3>DevOps</h3>
One of the major advantages of Strapi is to use your own infrastructure to host and store data independent of hosting provider.  Unlike Amplify this also means that you have to take care of each step of stack implementation. Luckily Strapi has partnered with Digital Ocean and together provided server image that could be deployed in seconds. 
Server image consists of Nginx reverse proxy server, Strapi CMS,  PostgreSQL database and PM2 process manager. You have to manually implement and generate SSL certificates for Nginx server but overall installation is straight-forward. 
Strapi CMS codebase sits in dedicated folder and you can enable Git versioning to track customization and dependency upgrades. 
Security is hardened within server stack image, I also added external security and monitoring services for Node runtime.
&nbsp;
<h3>Design</h3>
With built in data models for user management it was straight forward to enable user authentication and authorization. Strapi features external email provider integrations for user registration/verification and also has plugin support for AWS Cognito with SMS phone verification for 2FA.
Main advantage of Strapi is UI for designing data models and relationships between them. All of it can be easily exposed via REST or GraphQL API endpoints. For extra customization it is possible to extend each segment within Strapi&#8217;s MVC architecture with NodeJS snippets. Upgrade of Strapi&#8217;s core dependencies can be done independently of custom code, just be sure to upgrade your code to be aligned with Strapi&#8217;s core API&#8217;s changes.
Another advantage of this stack is scaling, since Database and Strapi Node core could be deployed as independent instances, it is possible to achieve horizontal scaling of both PostgreSQL and NodeJS with introduction of load-balancing.
&nbsp;
<h3>Results</h3>
After all we end up with low-latency statically generated PWA Frontend, easily extendible Backend, custom REST API, solid security and very low maintenance costs. We retained full control over Data storage, infrastructure hosting and UX/UI.

Search for customizable and scalable low-code Headless CMS

<h3>Moving from a monolithic WordPress stack to microservices architecture with Nuxt, Vuetify and WP API.</h3>
After a long time developing web sites with open source CMS and being influenced by recent developments in the JavaScript world I decided to upgrade my development workflow and production stack. I&#8217;ll start with describing the production stack I have been using and moving to a new stack, examining the positive and negative traits of both.
Long story short, I converted my existing WordPress stack to serve as REST API to feed decoupled front-end in Vue.
<h2>Part 1. What have I been using in the past?</h2>
<ul>
<li>In short: VPS, CentOS, Apache, MySQL, PHP, cPanel/WHM, WP, Premium Themes</li>
</ul>
Infrastructure
For more than 10 years, I was relying on cPanel/WHM stack to provide a full set of web hosting services for my web development clients.
I was using various hosting companies like Rackspace, ServInt, and Contabo. More recently, I started using cloud services like AWS and Heroku. Renting servers or assembling the infrastructure was never approachable. Running WHM, once all quirks have been worked out, does not need much attention, except for regular updates and systems migration. Some unexpected time was dedicated during traffic spikes or security related issues around public libraries.
Since this was a “one-man-show” and since the ecosystem gave rise to pretty sophisticated licensed or open source themes and frameworks, the decision was made to leverage the benefits of affordably outsourced “heavy-lifting” in back-end development.
While focusing on overall UX and building on top of CSS frameworks with modular UI elements, custom logic could be built with Type Systems and raw PHP as Plugins and theme core extensions.
Back-end
The first step was to consider vertical compatibility between OS features and services in favor of application requirements. My choice for production ready stack in most situations was RedHat/CentOS. The second part and my tool of choice was Web Host Manager (WHM). Initial configuration is for basic usage including updates, backups and monitoring. After deploying working apps, more fine tuning was done for PHP, Apache, MySQL, and DNS. For security best practices and sometimes paranoid level of protection, I used tools like CSF, LFD, CXS, etc.. Two major benefits of this approach is metering of hostile IP’s/subnets and protection even if zero day vulnerabilities were found in application level, which PHP software had a fair amount in the last 10 years. I have to mention that MySQL played a big role and tools like SQLyog helped to get insights for fine tuning.
With extensive testing and feedback from real world situations, the stack was optimized to deal with much higher load than expected and retaining a high grade of security in much needed environment.
Pros: With a big percentage of unused code processed on the server and delivered to clients, various PHP caching and optimization techniques were used, like HTML/CSS/JS Minification, Concatenation, Deferred loading. Together with good optimization of Apache and MySQL, stack was tuned to deliver impressive performance on modest servers.
Cons: Scalability is limited to vertical scaling only, due to the nature of how WHM works.
Debugging issues throughout the stack can often be time consuming because of multiple layers of security.
At the time of the beginning of this stack, mobile internet was not a thing and desktops and laptops were quite capable of running websites with overhead code. Users came from fixed internet access with stable latency. After a period of mobile growth taking the majority of web traffic, responsive design was introduced and added more code overhead. Together with low media optimization and advertising practices, mobile experience at the time was in a bad state.
Front-end
I have been developing and researching client side solutions, making suitable decisions for project requirements. Rigorous testing was done for performance, UI/UX features, and back-end development experience. Also a major role in decision making involved the evaluation of open source projects behind the tools being used or commercial tools under licence. All of this was done to ensure a long lived product.
When all of the details mentioned above checked out, developing a user interface and custom business logic (as custom themes or building on top of premium themes) was usually a breeze and allowed for fast iterations from development to production.
All modifications and custom logic was done within specifications of a well tested stack at this point.
Pros: Building on top of premium themes with opinionated, premade UI elements and well defined and tested frameworks is a huge time saver!
Cons: These premade themes often have a decent amount of overhead code since it is oriented for general purpose use cases. Resolving front-end bugs because of JS incompatibilities introduced by code from various developers is highly time consuming.
<h3>Conclusion</h3>
This approach allowed one person to vertically control the stack, develop and deliver very fast modern products from a secure environment. Also I was being able to provide cutting edge features, stability and high performance for a variety of clients and security implication they bring.
<h2>Part 2. What I have moved onto?</h2>
<ul>
<li>In short: AWS, EC2, Linux2, Docker, NginX, NodeJS, Vue, Nuxt, WP API, GraphQL</li>
</ul>
Development stack: VScode, Github, TravisCI, EC2
I have started developing javascript single page applications with server side rendering and support for requesting and parsing external APIs. Generally, on landing pages, server side rendering is done with NodeJS behind NginX reverse SSL proxy with HTTP2 support.
While experimenting, I developed an app that is hosted on EC2 and fetches data from 3 different APIs and utilizes a CDN. I developed the following back end services to support the app:
<ul>
<li>Portfolio WP REST API, WordPress instance on cPanel VPS.</li>
<li>Currency Exchange REST API, Dockerized Python app on EC2.</li>
<li>News WP REST API, WordPress instance on cPanel VPS.</li>
<li>Media CDN, simple file hosting on cPanel VPS.</li>
</ul>
By adopting the above tools, I solved one of the downsides of the previous stack, which was scalability. With this kind of architecture, scaling is without boundaries if you include the option to expand with CDN, load balancers, static serving and autoscaling.
AWS example:
<img loading="lazy" class="alignnone size-full wp-image-7455" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/AWSexample.png" alt="" width="1792" height="1063" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/AWSexample.png 1792w, https://cvapi.monolit.me/wp-content/uploads/2020/08/AWSexample-285x169.png 285w, https://cvapi.monolit.me/wp-content/uploads/2020/08/AWSexample-768x456.png 768w, https://cvapi.monolit.me/wp-content/uploads/2020/08/AWSexample-1536x911.png 1536w, https://cvapi.monolit.me/wp-content/uploads/2020/08/AWSexample-1200x712.png 1200w" sizes="(max-width: 1792px) 100vw, 1792px" />
<h3>Enter Nuxt.JS</h3>
Major benefits of new client side features in Vue are built on top of and provided out of the box with Nuxt, allowing features like:
<ul>
<li>Universal/Isomorphic Application</li>
</ul>
By nature, JS single page applications fetch content after all parts or the shell of an app are loaded. This approach creates issues for search engines, since crawlers are expecting static HTML content. To solve this problem Nuxt can enable Universal Application mode which utilizes NodeJS to provide pre-rendered HTML content for any requested URL. For any subsequent request, only content API requests are made.
<img loading="lazy" class="alignnone size-full wp-image-7456" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtScheme.jpeg" alt="" width="600" height="436" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtScheme.jpeg 600w, https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtScheme-233x169.jpeg 233w" sizes="(max-width: 600px) 100vw, 600px" />
<ul>
<li>Per page code splitting</li>
</ul>
Usually, JS apps send code for all pages even though they are not used on a requested page. By utilizing Webpack, code can be separated for each page and sent just for requested page.
<img loading="lazy" class="alignnone size-full wp-image-7464" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/term1.png" alt="" width="1007" height="195" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/term1.png 1007w, https://cvapi.monolit.me/wp-content/uploads/2020/08/term1-300x58.png 300w, https://cvapi.monolit.me/wp-content/uploads/2020/08/term1-768x149.png 768w" sizes="(max-width: 1007px) 100vw, 1007px" />
<ul>
<li>Progressive Web Apps (PWA)</li>
</ul>
PWA Nuxt modules provide full support for offline usage, notifications, device hardware access and other features creating user experience similar to native apps. With recent Chromium advancements, PWA can be installed directly from Chrome browser. Afterwards this app behaves as classic native application and can be installed on any device and OS.
<img loading="lazy" class="alignnone size-full wp-image-7463" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/PWA.png" alt="" width="797" height="605" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/PWA.png 797w, https://cvapi.monolit.me/wp-content/uploads/2020/08/PWA-223x169.png 223w, https://cvapi.monolit.me/wp-content/uploads/2020/08/PWA-768x583.png 768w" sizes="(max-width: 797px) 100vw, 797px" />
<ul>
<li>Async components</li>
</ul>
For a large application, it is recommended to divide the app into smaller chunks and only load components on demand from the server.
<img loading="lazy" class="alignnone size-full wp-image-7457" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/Async1.png" alt="" width="810" height="235" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/Async1.png 810w, https://cvapi.monolit.me/wp-content/uploads/2020/08/Async1-300x87.png 300w, https://cvapi.monolit.me/wp-content/uploads/2020/08/Async1-768x223.png 768w" sizes="(max-width: 810px) 100vw, 810px" />
Wrapping import in function will be used by Webpack as Promise to load parts of the code asynchronously.
<img loading="lazy" class="alignnone size-full wp-image-7461" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/PageSplit1.png" alt="" width="779" height="79" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/PageSplit1.png 779w, https://cvapi.monolit.me/wp-content/uploads/2020/08/PageSplit1-300x30.png 300w, https://cvapi.monolit.me/wp-content/uploads/2020/08/PageSplit1-768x78.png 768w" sizes="(max-width: 779px) 100vw, 779px" />
<ul>
<li>Prefetching</li>
</ul>
Nuxt.js will automatically prefetch the code-splitted pages when visible in the viewport by default. After index page is loaded, second level page is lazy loaded and on standby for data fetch.
<img loading="lazy" class="alignnone size-full wp-image-7462" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/Prefetch1.png" alt="" width="785" height="76" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/Prefetch1.png 785w, https://cvapi.monolit.me/wp-content/uploads/2020/08/Prefetch1-300x29.png 300w, https://cvapi.monolit.me/wp-content/uploads/2020/08/Prefetch1-768x74.png 768w" sizes="(max-width: 785px) 100vw, 785px" />
<ul>
<li>Device detection code split</li>
</ul>
Shipping code only for specific device type and OS type.
<img loading="lazy" class="alignnone size-full wp-image-7458" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/DeviceDetection.png" alt="" width="860" height="81" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/DeviceDetection.png 860w, https://cvapi.monolit.me/wp-content/uploads/2020/08/DeviceDetection-300x28.png 300w, https://cvapi.monolit.me/wp-content/uploads/2020/08/DeviceDetection-768x72.png 768w" sizes="(max-width: 860px) 100vw, 860px" />
<ul>
<li>Offline detection</li>
</ul>
Simple network status notifications
<img loading="lazy" class="alignnone size-full wp-image-7460" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/offlinedetection.png" alt="" width="902" height="58" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/offlinedetection.png 902w, https://cvapi.monolit.me/wp-content/uploads/2020/08/offlinedetection-300x19.png 300w, https://cvapi.monolit.me/wp-content/uploads/2020/08/offlinedetection-768x49.png 768w" sizes="(max-width: 902px) 100vw, 902px" />
<ul>
<li>Nuxt architecture</li>
</ul>
<img loading="lazy" class="alignnone size-full wp-image-7459" src="https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtArchi.jpeg" alt="" width="1800" height="1222" srcset="https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtArchi.jpeg 1800w, https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtArchi-249x169.jpeg 249w, https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtArchi-1591x1080.jpeg 1591w, https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtArchi-768x521.jpeg 768w, https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtArchi-1536x1043.jpeg 1536w, https://cvapi.monolit.me/wp-content/uploads/2020/08/NuxtArchi-1200x815.jpeg 1200w" sizes="(max-width: 1800px) 100vw, 1800px" />
<h2>Conclusion</h2>
Comparing to the previous stack, the only downside is significantly longer development time which is only true in general use cases for small/medium enterprises.
The new stack provides blazing fast user experience. With SSR, Initial load is under a second. All subsequent loads with the help of service workers and well optimized API’s are around 50ms. For all returning users, the experience would feel native as the shell app is pulled from local cache and content preloaded from a persistent state. Fresh content from API and images from CDN will load and render under 400ms (Doherty&#8217;s Threshold), which is considered seamless interaction by human perception.
In short, this is a dream come true. Native experience delivered over the web with seamless updates using open source collaboration and technology.
&nbsp;

Articles

Search for customizable and scalable low-code Headless CMS

How I moved from a monolithic development style to embracing microservices