Core Web Stack
Unlike applications that live only on the Web, WWT has an installed base of Windows clients some of which are more than a decade old. Some of those Windows clients are installed at planetariums or museums that are using WWT in public-facing exhibits but, generally speaking, very reluctant to experiment with their technology infrastructure. Therefore, it is extremely important to preserve the detailed behavior of the WWT web API endpoints used by the historical clients.
What makes this requirement a bit tricky is that the historical WWT web API endpoints are served off of the domain worldwidetelescope.org, the same domain that is used to host the webclient (at worldwidetelescope.org/webclient/), the Communities service, and user-facing web pages. In principle, we might like to use different web server frameworks for each of these components of the WWT web presence. However, web requests to the same domain name must all be handled by the same server(s) as seen by the public internet.
Azure Application Gateway🔗
Until April of 2020, traffic to worldwidetelescope.org was all handled by a pair of virtual machines running a customized ASP.NET setup on IIS 8.5 that dealt with all forms of traffic to the domain. Deployment was manual, seriously bottlenecking development due to the aforementioned importance of keeping the core WWT data services highly reliable.
As of April 2020, traffic to the flagship domain is handled by an Azure Application Gateway frontend, a "layer 7" load balancer and reverse proxy that can redirect traffic to different web server backends based on the URL path requested. This is the core capability that allows us to begin sharding out requests to the worldwidetelescope.org domain to different servers depending on the service being requested.
Furthermore, the app gateway acts as a TLS termination proxy, such that it can handle HTTPS traffic while the communication to the data backends can use plain HTTP, which is valuable since the data requests take the form of many small HTTP requests. Before April 2020, the flagship worldwidetelescope.org domain did not support HTTPS due to the configuration challenge and worries about the load that TLS processing would add to the core data VMs.
Web Backends on the Flagship Domain🔗
Since the transition to the App Gateway deployment model, requests to worldwidetelescope.org may be served by one of five backends.
Note that the classic website treated paths case-insensitively; that is,
/WWTWeb/ were routed identically. The App Gateway routing
infrastructure is also case-insensitive, but the Linux-based backends and the
Azure Storage static files website are case sensitive.
CORS/TLS proxy backend🔗
used by the web client to proxy requests that would otherwise be forbidden by
the user’s web browser because of either CORS or mixed content
These requests are handled by a small server running Squid inside a Docker
container. The assets to create the container are in the repository
wwt-squid-proxy. Merges to the
master branch of that repository trigger a
continuous deployment pipeline that updates the Docker image published as
aasworldwidetelescope/proxy. Finally, the WWT Azure infrastructure includes
an App Service named
wwtproxy that runs that Docker image, including
hot-reloads when the image is updated. The App Gateway routes proxy requests
wwtproxy App Service.
nginx utility server🔗
Requests to the
/docs prefix and the path
/webclient — but not
/webclient/ or any paths below it — are handled by a utility nginx server,
since it can easily be configured to issue both server-side redirects and
simple static content.
The infrastructure for this utility server mirrors that of the CORS/TLS proxy.
The container assets are tracked in the repository wwt-nginx-core. Merges to
master trigger a CD pipeline that publishes a built Docker image as
aasworldwidetelescope/nginx-core. In the WWT Azure infrastructure, an App
wwtnginxcore-prod runs a server based on that Docker image
with automatic reload when the image is updated.
The nginx utility server also services requests and redirects for miscellaneous WWT domains of mainly historical interest. See the README and configuration file in wwt-nginx-core for details.
IIS/ASP.NET "user" website server🔗
When we refer to the core or flagship “user” website, we mean the mostly-static user-facing content accessible through the portal at worldwidetelescope.org/home.
At the moment, this website is an ASP.NET application whose source is tracked in, and continuously deployed from, the repository wwt-user-website. Work is underway to refresh this content and switch to a static site generator backend. As such, the documentation of this framework will stop here.
Static content backend🔗
Much of the content served by worldwidetelescope.org consists of static file
content. Since the infrastructure rebuild of April 2020, that includes the web
client AngularJS application (URL paths
/webclient/*) as well as
miscellaneous data files in paths such as
Requests for this content are routed by the App Gateway to an Azure storage
account with the static website hosting feature
enabled. In the WWT Azure services, this storage account is named
wwtwebstatic. Updates to this content are deployed by uploading new files to
the Azure storage account, which can be (and is) automated in continuous
deployment pipelines for version-controlled assets.
Legacy virtual machines🔗
All web requests not handled by any of the other backends are routed to the legacy Windows Server 2012R2 virtual machines. This includes important elements of the WWT web services such as:
- Data and other services at URL paths
- The entire Communities web service
- Requests to the root path
/, required by the way that App Gateway works
The sources to these web backends are nominally tracked in the repository wwt-website. However, due to the manual deployment process required by these VMs, the actual assets running in production and the source repository have diverged somewhat. Work is underway to understand and minimize this divergence, as well as to migrate the infrastructure to a system whose deployment can be fully automated.
Further note that the production deployment includes configuration files containing various keys and connection strings that must be kept secret.
Web Client application🔗
Since the April 2020 infrastructure upgrade, a more careful distinction has been made between the web client application and the WebGL engine library powering it. The two are certainly closely connected, but they are now tracked in separate repositories and released independently.
Merges to the
master branch of the wwt-web-client repository are
continuously deployed to a testing prefix,
worldwidetelescope.org/testing_webclient/, by uploading built artifacts to
the appropriate location in the
wwtwebstatic Azure Storage account.
Version-tagged releases are deployed to production through an analogous
process. For more information, see the README in the source repository.
As of the April 2020 infrastructure rebuild, the worldwidetelescope.org domain supports HTTPS via TLS termination at the App Gateway.
The core content served by the worldwidetelescope.org domain is also made
available through a Content Distribution Network (CDN) associated with
A request for the URL
cdn.worldwidetelescope.org/SOMEPATH will yield
identical results as a request for the URL
except that the response may hopefully arrive faster if the user is near one
of the CDN point-of-presence nodes and it has already cached the relevant
Because this CDN frontend is expected to serve content for arbitrary URL paths
at exposed by the worldwidetelescope.org origin, CDN requests must be routed
through the Azure App Gateway load-balancer, imposing a minor efficiency cost
(as well as a financial cost in App Gateway bandwidth charges). The vision is
to start transitioning CDN-friendly WWT content to route through subdomains of
wwtassets.org domain, which can be set up to avoid the overhead of
routing through the App Gateway. A secondary advantage is that requests to a
separate second-level-domain will not include the HTTP cookies set by the core
worldwidetelescope.org domain, which can potentially increase the efficiency
of the HTTP traffic. (We are told that this is why most major websites use a
separate domain for their CDN traffic.)