Mass Website Deployment Workflow
by WebAsOne - Single-Stage website process platform
Scale by multiplying
Creating a scalable website application is a challenging task. WebAsOne is a platform to develop scalable SaaS. This architecture is not a universal fit for all website applications, but it has its advantages.
You created a fantastic design with amazing features. Most likely, others can replicate. The mission of WebAsOne is to copy similar websites and integrate them into WebAsOne's existing, growing platform. The operational cost of delivering similar functionality with extended integrations will be much lower. In this post, we will demonstrate how WebAsOne accomplishes this.
The common WebAsOne website is a PHP file without any database involvement, like a static HTML file.
Using the local website listing service provided by WebAsOne as an example to showcase the mass website deployment workflow.
Akamai Cloud's shared VPS is used. The management server is a 2CPU/4GB. The three hosting servers are 1CPU/2GB.
The local listing service is done by having a city/state subdomain website for each city. To divide the load, California has its own domain and server. To accommodate a larger city, update the DNS entry for the targeted city to point to a different server. Or each can have its own unique domain, too. Upgrading the hosting server is also an option. With this approach, serving millions of users is straightforward. Developing this kind of app without worrying about volume is much easier. The listing service component is not a complex Vue 3 app. Most capable developers can do it in days or weeks. Develop an app and let WebAsOne do mass deployment for you.
A complete WebAsOne website is stored under a directory that defines pages, modules, and other components. At the management server, run the website-generating script to create and deploy the websites. For local service websites, it takes about 7 hours to create/deploy 1600+ websites.
There is a single master website for the local listing service on the auxiliary server, managed from the management server. For each city, it could have a custom local listing website on the auxiliary server. When running the website-generating script, it will pull content from the master website and the custom local website. The custom local website will be able to overwrite the master's. The content is not limited to components; it could have pages.
This workflow pattern can be applied to an organization with several subdivisions' websites that share common content and also have their own unique content.