Case study 1: Wordpress to Svelte
A client had a Wordpress-based platform that used several off-the-shelf plugins from the WP ecosystem to create a learning management system (LMS). Despite being well-resourced with dedicated hardware, this was painfully slow and consisted of a blend of custom PHP code and commercial plugins that was difficult to maintain.
In consultation with Sealgar the decision was taken to move to a bespoke site. It would:
- have to mirror the functionality of the existing site,
- transparently port over the data for thousands of existing users and
- fix the original performance and maintainablity problems.
Redoing what was a very large site from scratch was not feasible, so the existing database-bound data structures had first to be reverse-engineered and the content extracted. Custom java code was used for this, and an object model of it was constructed. A separate java-based object model of each user’s progress data was also built.
Work could then begin on building the new site. For this SvelteKit was used, “a framework for rapidly developing robust, performant web applications”. For the frontend, Svelte was combined with both Tailwind CSS and daisyUI, although substantial design cues were ported over from the original site.
Whilst an advantage of Sveltekit is how easy it is to launch on serverless platforms (like Vercel), things become complicated and/or expensive when a highly utilised read-write database must also be catered for. In addition, a project goal was to have as few dependencies on third-party companies as possible.
The server architecture chosen therefore uses the Node.js server on AWS EC2 instances behind a load balancer. The instances run stock AWS Linux, so are (in principal) easily portable to any other company or datacentre.
The need for a single-point-of-failure database server was avoided by installing a custom Galera build on each instance. For the use-case of the app (a small amount of important reads and writes) this works well. It allows for resilience and easy horizontal scaling if required.
In-site search was handled by a local Solr installation (this was easy to set up as the site's content is largely fixed—negating the need to set up regular crawls of all pages).
This solution has improved page load times by at least a factor of ten, as well as considerably simplifying maintenance. And, as the content of the site is now stored in text (svelte) files rather than a database, git-based change control has made quality control and editing much more straightforward.
Whilst the initial decision to use SvelteKit over other, more established frameworks such as Angular or React was something of a risk, it has paid off handsomely. Indeed, it has become Sealgar's go-to framework for any website that requires more than a few simple, static pages.