I have two frontends in which one is VueJS based and another is traditional server side rendered frontend. Both these frontends use cookies to identify users and user data is stored on MongoDB. I want to deploy 2 or more instances of one frontend (used by the public) and one instance of other frontend (used only by employees).
I also want to deploy public facing frontend static assets via AWS Cloudfront.
How do I deploy to Kubernetes above scenario? Do I deploy frontends to multiple Pods in Kubernetes?
Do I deploy Cloudfront to Pods on Kubernetes?
If I use AWS managed Kubernetes, EKS, does anything change in above scenario?
How do I deploy dynamic assets ( pulled from MongoDB database) on AWS Cloufront?
The Java Spring Boot APIs backend uses OAuth 2 to athenticate users (on VueJS frontend login form). VueJS frontend uses JWT access/refresh tokens whereas Spring Boot frontend uses a fixed API user on its backend to make API requests to API backend to get content to show to customers.
What you are asking here is an architecture design question, and there are prerequisites to optimal cloud hosting. In a nutshell you need to be very strict about Separation of Web and API concerns.
SINGLE PAGE APPs
Web static content should be deployed via a Content Delivery Network (CDN), eg to 50 global locations. Using containers here is usually overkill and a system such as AWS Cloudfront will enable globally equal performance for web downloads without much technical effort.
COOKIE BACK ENDs
These require a runtime, so if you use a website technology, eg Spring Boot, you will be unable to use a CDN in the preferred way. AWS Cloudfront only hosts static content, not runtimes.
APIs
It is often preferred to deploy APIs and other back end components using Kubernetes, in order to keep code portable, and to host best of breed supporting components alongside the APIs.
TOKEN HANDLER PATTERN
APIs can perform cookie issuing for Single Page Apps, rather than needing a website back end. It is tricky, but see this article for an overview of how it works.
DYNAMIC ASSETS
In this model anything that needs securing is best managed via APIs rather than Cloudfront. Dynamic images etc could be pushed to Cloudfront at any time. It is also possible, if you have special reasons, to send API issued cookies to Cloudfront and use them in lambda edge functions.
EXAMPLE OF MINE
My Single Page App uses only the latest secure cookies in the browser, and is also deployed via Cloudfront - there is an online version you can run, and some blog posts that accompany it.
SUMMARY
Enabling optimal cloud hosting for web apps requires effort, partly because the current security best practice is for SPAs to use only the latest secure cookies in the browser.
You will have to use container hosting for websites, and you have the option to use it for SPAs, if that best fits your current architecture. With effort though, it is possible to use Cloudfront for SPAs secured by cookies.