LecCory
commented
2 years ago I Deployed a small SPA project that I contributed infrastructure as code for to my personal Azure portaL. The project is a simple questionnaire but it has both the front end and back end decoupled from one another and can serve as a demonstration on how we can leverage Azure's serverless features to break away from containerization.
Front End
The front-end was built in Vue due to the simplicity of this particular app. This demo doesn't mean we have to use Vue, any of the major frameworks will work since they output a build with an index file that points to a bundle with all your styles and JS.
Break away from Containers and Webservers
- All the major frameworks from what I've seen output the same bundle of files
- All frameworks are client side rendered and eliminate the need for a webserver or web microservice
- The client pulls all the static front-end content and renders all components in the browser locally
How?
- Microsoft allows storage resources to be web enabled.
- Enable the feature and direct the container to look for specific entry point (index.html)
- Upload build into the container
- A default url is generated by Azure but a CNAME DNS entry can be created to provide a proper URL to the end user
Why?
-
During the planning stages of this project, the original plan was to host the front end out of a Docker container but due to constraints with IMDT requiring specific approved Docker images the plan was abandoned.
-
Azure does have a managed service specifically for serving static files (Azure Static Web service) but it is unfortunately not available in Canada.
-
After some research we discovered the storage container web feature. This ensures that our data remains in Canada, avoids Docker containers and the constraints that come along with them and so far has worked great during our testing and development.
Back End
The back is comprised of multiple Azure functions written in Typescript, however much like the front end framework support for multiple languages is made available by Microsoft.
Break away from Containers and Webservers
Function apps are stored in an Azure App service plan not a web server or container There are a number of trigger types that can execute the function HTTP Triggers will likely be the only ones we'll use
How?
- A function app can be comprised of multiple functions.
- Each function executes one single task
- Each function is given an end point url that contains {baseURL}/api/{apiname}
- The front-end during build can be passed the API baseURL so functions can be triggered when required
Why?
- Function apps by design autoscale
- Cost is approximately $0.20/1,000,000 requests after the first million which are free
- We only pay for the compute that we use so we don't need an always on server
- These functions can speak to any database server be it MySQL, MongoDB, CosmosDB, or MSSQL.
- Database connection information is saved in the function apps configuration page and passed into the function on execution
- The development of function apps is very simple a lot of boilerplate code is given to you via the Azure function app extension.
- Function apps are broken into 2 files - Instruction files (tells function app what to expect for input, triggers, location of the script to run and output) and the script file where the instructions on what to do and return as output.
- Function apps can then be imported into an API management gateway where further control over the incoming and outgoing of data can be managed such as request policies to limit the number of requests one requester can make in a given time frame
nschonni
vid
Do research and options analysis on how to upgrade or improve the core backend solution for the GCcollab app. Options can include: