Serving Single Page Applications with Domino

Single Page Applications (SPA) are all the rage. They get developed with AngularJS, ReactJS or {insert-your-framework-of-choice}. Those share a few communialities:

• the application is served by a static web server
• data is provided via an API, typically reading/writing JSON via REST or graph
• authentication is often long lasting (remember me...) based on JWT
• authentication is highly flexible: login with {facebook|google|linkedin|twitter} or a corporate account. Increasingly 2 factor authentication is used (especially in Europe)

How does Domino fit into the picture with its integrated http stack, authentication and database? The answer isn't very straight forward. Bundling components creates ease of administration, but carries the risk that new technologies are implemented late (or not at all). For anything internet facing that's quite some risk. So here is what I would do:

The main rationale for this approach is a best in breed selection of components separated by firewall components. In detail:

• The front facing machine is a NGINX http server. I would configure it to support http/2, PageSpeed and Certbot. All calls to http would get redirected to https provided by LetsEncrypt (or buy your own). Running in a VM or a Container I would wipe it from time to time (daily), so anything that might have established a foothold dies then
• The http server would contain the SPA with proper manifest and http expiry headers. That makes delivery fast and saves server resources up the chain. Deployment would be bound to the VM/Container creation process, so the http server would be mainly readonly
• The authProxy would be a NodeJS application using the PassportJS framework. It offers an unparalleled selection of more than 300 ways to authenticate. The identified user then can be passed on to Domino. In addition some URL sanitisation could be performed. Since only API calls would land there, checking them for plausibility can be done cheap and easy
• The Domino server's role is the provision of API access powered by its NoSQL NSF store. If so choosen its LDAP could serve as the identity source for the passport authentication

Who is member of the green or red zone is subject to debate, so you might want to go with a different approach like the one below.

As usual: YMMV