Web components run your application’s source code. Now, a single app can have multiple web components, each with their own code base, unique configuration, and DNS Alias. Each component has access to application databases, caches, and workers, and each is independently scalable.
Single web components are automatically created when you launch an app. Multiple web components are launched by including multiple web configurations in your Boxfile. During the next deploy, additional web components are created.
Example Web Components in the Boxfile
web1:
name: front-end
document_root: public
php_version: 5.3.10
web2:
name: admin
document_root: admin
php_version: 5.3.8
shared_writable_dirs:
- user/uploads
php_extensions:
- gd
- mysql
web3:
name: api
document_root: app/api
A Hybrid Scaling Model
An ecommerce store like Magento may have a heavy admin panel suited for few instances with higher RAM for large routines. The more optimized front-end and would benefit from more concurrency (instances) requiring less RAM. Dividing the admin panel and front-end into two separate web components makes each scalable for optimal performance, without overbuilding.
Dependency Isolation
A front facing web application may need a special version of php with many php extensions. An api might be much slimmer, perhaps taking advantage of a newer PHP api and anonymous functions. Splitting the web application and api into separate web components makes each independently configurable to suit specific functions.
Shared Services
Two completely unrelated applications may need to share a database or key/value store. Instead of creating two separate apps, launch an additional web component. Host unique applications in complete isolation, yet share resources between them.
Simplicity and Organization
If you would like to keep your collaboration management and billing administration to a minimum, this allows multiple apps to be grouped within the same umbrella app namespace.
Managing the GIT Repo
Multiple web components introduce a unique workflow dynamic. Managing multiple applications in a single repo may become cumbersome. Creating each application as a git submodule, which may be managed separately. When the main repo is pushed, git submodules are automatically updated.
For more in-depth information, check out our Web Components guide.
This is a very exciting announcement! I look forward to try it out on some of our projects.
I do have one question though. What if my application doesn’t use the document root as the web root? Say I have a root folder with an application folder and a public folder. All the public assets live in the public folder but all (non js code) code live in application folder. I guess my question boils down to is the whole repository pushed to all of the components or only the part specified in the dococument_root parameter?
Because if this is the case then I don’t consider it to be two truly separated environments/application parts. Anyway it is a very cool feature that I definitely think I will be using. I just hope it will be possible to separate different parts completely as it would make it easier to use in a team workflow where people are only working on one part of the application (code on one component).
Hey Jesper,
Your whole repo is pushed to each web component. The document root specifies the root of public web access to each component. Web components still have full access to code within your repo.
It’s important to draw the line between application and environment. Each web component has separate environments individually configured in the Boxfile. By environment I mean php version, extensions, shared writable dirs, etc. Application code is the same across web instances, but the access points for those components are different.
To manage each component as completely separate parts, you could turn each into git submodules. When the parent repo is deployed, all submodules are automatically updated. This would allow members of your team to work and collaborate on specific parts of your application without having to deal with the entire code base.
This is great! When creating an app I want the frontend site to run separate from the actual app. So far, this meant running 2 separate apps and you were left with a problem in giving the frontend access to the backend’s resources like cache and databases.
There is, however, a problem I see in deployment. It’s easy to setup the main repo with 2 submodules, the front and backend so that you can actually use 2 repos, but this would mean that if you deploy a new release on the frontend, the backend would also be redeployed. Especially when the backend is strongly cached, but a redeploy would invalidate the caches, you can see how this is something you’d want to avoid.
Any thoughts on this?
@jaap When you are setting up your cacheing, you shouldn’t clear them all on a redeploy (at least, in most cases.) It wouldn’t be too difficult however to namespace your caches if you are using something like redis. That way you can invalidate only the backend cache.
But then in the end, I’m still redeploying my precious / heavily used backend when I just want to push some little changes on the frontend site. So even though, with a bit of trickery you can make stuff like cache’s be fine, that could work, it’s just a side effect I think nobody who runs a web app should want.
With this being the situation, I’d use the multiple web components for separating parts of the same codebase, say a webapp and it’s API, but not to share my DB between a frontend site and that webapp. I would put the time in creating a little RESTful interface between the two instead of having to redeploy my web app everyime I made a css change on the frontend site.
I was wondering the same thing Jaap Rood