Add general notes for deployments

org-cyf/content/guides/deployment/_index.md

@@ -0,0 +1,15 @@
+---
+id: deployment
+title: Deploying applications
+emoji: 🖥️
+---
+
+# What is deployment?
+
+Deploying in short is making sure the application you are developing is made available for the world wide web to see (or in case for internal systems it is at least visible to the intended audience). Without the ability to deploy the only way to show what you have done is ask others to come to your computer, and show them the work on it in person.
+
+{{<note type="note" title="TL;DR">}}
+The CYF Curriculum team suggest [Netlify Deployment guide](../deployment-netlify/index.md). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations.
+
+This suggestion assumes that you are interested in a fully free option, and you can accept the limitations. If you have a deployment budget for your work and/or the limitations are not acceptable you are free to look at other choices as well.
+{{</note>}}

org-cyf/content/guides/deployment/application_stack.md

@@ -0,0 +1,56 @@
+---
+id: application_stack
+title: The application stack
+weight: 3
+emoji: 🖥️
+---
+
+# The application stack
+
+In the previous section, we talked about the fact that most full-stack web applications have multiple layers (generally at least a frontend and a backend component and some kind of persistence layer in the form of a database). In this section, we go through these layers and talk about how they are usually deployed.
+
+## Frontend
+
+In the curriculum we teach, frontend files are considered static. What this means is that once you deploy them, they will never change until the next deployment comes. Your `index.html`, `index.js` files, your CSS files and your image assets will always contain the same content regardless of how many times they are downloaded and shown in browsers around the world.
+
+This makes them an ideal candidate to serve them through CDNs, Content Delivery Networks. These systems deploy your static files around the globe allowing people to access them quickly. Serving static files is fairly inexpensive, as you only need disk space and bandwidth, so a lot of companies provide this for free for small projects and you only need to pay once your user count becomes large enough.
+
+CloudFlare Pages and Netlify are some examples of CDN providers that have generous free tiers allowing you to host your static files with them. GitHub Pages, while not strictly considered a CDN, also allows you to host files from your repository simply.
+
+{{<note type="warning" title="Other frameworks">}}
+Do note that while the fact that frontend files are static is true for the frameworks we teach, it is not universally true for all frameworks. Web-focused languages like PHP, and MVC frameworks like Ruby on Rails or Django, allow you to create dynamic frontend files. Some React frameworks also support server-side rendering which can make the frontend part of your application dynamic, and ineligible to be served through CDNs. Anything static, like CSS files or images however you can still serve through CDNs, and it is generally still a good idea to do so to improve your application's loading speed.
+{{</note>}}
+
+CDNs are however not the only way to deploy and serve your frontend. You can also add code to your backend server that will enable it to serve your static files. This allows you to use any of the backend providers (that support persistent deployments) to serve your frontend as well. The main benefit of this approach is that your frontend and backend parts remain closely tied together, you can for example easily deploy them at the same time making sure there are no version discrepancies between the two. However you would lose the benefits of CDNs, and although serving static files are not computationally too involved they still need to be handled, which will in turn slow down your backend.
+
+## Backend
+
+In contrast to the frontend, your backend systems are almost always considered dynamic. Every request they receive they need to generate a response on the fly based on the request and usually the contents of the database. This means deploying backends are much more involved, and this shows in free offerings as well - there are fewer options to host your backends for free, and the available ones have hefty limitations, forcing you to pay for an upgrade.
+
+To deploy your backend there are generally two wide categories of deployment mechanisms: persistent and serverless.
+
+### Persistent deployment
+
+In a persistent deployment scenario, you run your backend server all the time. This is very similar to how you usually run your backend during development on your local computer. This allows you to fully utilize the features of your backend framework, including features like backend workers. Latency - the time needed for your server to respond - is usually quite low compared to serverless deployments.
+
+The biggest drawback is that running a server constantly is more expensive, therefore free tiers are in very limited supply. Glitch, Render and Fly.io are some providers that still offer this, but all of them have strict limitations: the first two will for example stop your server if it doesn't receive activity for a longer time. This will make your service very slow whenever it needs to be restarted.
+
+Apart from the providers above persistent deployment is what people usually use VPS providers for, and the big players usually have a free tier available. AWS's EC2, Azure's Virtual Machines and Google's Compute Platform all have a one-year time-limited trial that allows you to use their slowest computer for free. However because neither of these services supports automated deployments out of the box, and it is very easy to accidentally overshoot the trial package (for example by accidentally starting up a slightly larger computer than the slowest one) we don't recommend any of these options for the projects we do in the curriculum.
+
+### Serverless deployment
+
+Serverless, sometimes called on-demand, functional or lambda deployments means that your server is not running constantly. Whenever there is a request the serverless provider will start up your backend, let it serve the request and then stop it immediately afterward.
+
+Benefits of this approach are that your service doesn't consume resources unless it's used. It is usually aimed for systems that are either not used constantly, or where there are periods of high usage, which needs more resources to handle. Running your backend on-demand only is also less expensive, so there are more free options available to use.
+
+The drawback of this approach is that your server is getting started and stopped all the time, so it needs to be developed in a way to make this less of a problem. Unfortunately, Express.JS is not designed with serverless operation in mind, but there is a plugin to allow its core functions to operate. However anything that requires your system to run constantly, including global variables or backend workers will not work and need to be replaced with an alternative. The constant starting and stopping is slow; therefore serverless functions have a higher latency than persistent servers.
+
+Netlify Functions, Cloudflare Pages, Supabase Functions are some examples that have free tiers available, and big players like AWS's Lambda also provide support for this in their time-limited free tier.
+
+## Database
+
+The final part of a full stack application is the persistence layer, which is usually a database, in our current curriculum likely a relational database, like Postgres.
+
+It's not the only kind of data store that you might need. For example, if your application needs to support file uploads and you need to store those files somewhere you would need to opt in for some kind of file storage server as well, this is outside of the scope of this guide however.
+
+Free Postgres databases are offered by Supabase, Fly.io and Render with some limitations. Other kinds of SQL databases are available from Cloudflare and are present inside the free tiers of AWS, Azure and GCP. These offerings do not follow Postgres' SQL standard, however, so are outside of the scope of this guide.

org-cyf/content/guides/deployment/deployment_strategies.md

@@ -0,0 +1,42 @@
+---
+id: deployment_strategies
+title: Deployment strategies
+weight: 4
+emoji: 🖥️
+---
+
+# Deployment strategies
+
+In the previous section, we went through where you can deploy your application. In this guide, we will go through how to do that.
+
+## Manual deployment
+
+Manual deployments are when you need to take action yourself to get your application deployed. This can be anything from running a couple of commands to needing to press a button on a website.
+
+For example in the scenario where we imagined that you have both a development computer and a small server in your house, deploying your latest version manually could be following the steps below:
+
+1. Commit your changes and push them to the `main` branch on the development machine
+2. Login onto your server computer
+3. Go to the running application's directory
+4. Stop the application
+5. Pull the latest changes from the `main` branch
+6. Run `npm i`
+7. Start the application again
+
+Manual deployments done in the way above can be error-prone. For example, if you forget to do step 7 your application will not be running at all at the end. If your provider does not support built-in automated deployments it is usually advised to create scripts that would do all of the steps above, so any time you wish the latest version to be deployed you would just need to run the script. Scripts can fail so you would still need to make sure to check the logs and see if everything went as expected. Trying to access your website after deployment is also a good way to check that everything is in order.
+
+## Automated deployment
+
+Automated deployment or Continuous deployment is whenever your code changes, the deployment flow is initiated automatically. For example, any time your code ends up in the `main` branch of your GitHub repository deployment will commence automatically, and your code will end up on your servers. You can imagine this by someone automatically running the deployment script we've created above whenever your repository changes.
+
+Some frontend and backend providers have GitHub integration and will support automated deployments out of the box. For others, you either need to deploy manually by following a set of steps or automate these manual steps by creating GitHub workflows manually.
+
+## Pull Request checks
+
+While automated deployments might sound scary, for example if you make a mistake in your code automated deployments would deploy that mistake automatically. There are ways to mitigate these risks by adding checks that run after each pull request is created, blocking merging if they fail. Common checks include linting, which would make sure that your code adheres to good coding conventions. Other checks that you can include are running unit, integration and end-to-end tests for each PR making sure that the code you've done passes these requirements.
+
+## Snapshot builds
+
+Another feature that helps make automated deployments less risky is snapshot builds. These are a feature of some providers where they not only deploy your `main` branch but also deploy your other branches as well in a temporary fashion. For example, if you create a new pull request from branch `new-awesome-feature` the provider will deploy this branch separately to your production environment. This will allow you, and anyone assessing your pull request to check how your changes would look like before actually merging them.
+
+Not all providers support snapshot builds. For the ones that do not, a common way to mitigate this is to set up two sets of servers, one called _production_ and the other _staging_ (other common names for this second set are _pre-production_ or _sandbox_). You would then deploy to this environment first, and only after checking that it works as expected continue the deployment to _production_ one. Do note that this usually requires you to set up your environment multiple times, and this will also increase the cost of your setup.

org-cyf/content/guides/deployment/free_deployments.md

@@ -0,0 +1,44 @@
+---
+id: free_deployments
+title: Free deployment offerings
+weight: 5
+emoji: 🖥️
+---
+
+# Free deployment offerings
+
+In this section, we will showcase some free options that allow you to deploy your application stack. We will also take note of any limitations each of the providers have.
+
+{{<note type="note" title="TL;DR">}}
+The CYF Curriculum team suggests Netlify({{< ref "/guides/deployment/netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. You will need to check these however to make sure they are still suitable for your use case.
+
+If the limitations of Netlify and/or Supabase are not suitable, a good alternative is Fly.io. Do note its free tier is limited to two computers, either one backend and one database, or two backends. If you have multiple projects that you want to deploy you'll need to either use a different provider or need to pay for those.
+{{</note>}}
+
+## Frontend
+
+| Provider         | Type                              | Deployment            | Snasphots               | Limitations                                                        |
+| ---------------- | --------------------------------- | --------------------- | ----------------------- | ------------------------------------------------------------------ |
+| Netlify          | CDN                               | Automatic from GitHub | Supported, PRs          | -                                                                  |
+| Cloudflare Pages | CDN                               | Automatic from GitHub | Supported, All branches | -                                                                  |
+| Render           | CDN or Frontend served by backend | Automatic from GitHub | Supported, PRs          | Backend is stopped after inactivity, startup time is slow          |
+| Fly.io           | Frontend served by backend        | Manual                | None                    | Free tier limited to two backends, or one backend and one database |
+
+## Backend
+
+| Provider         | Type       | Deployment            | Snasphots               | Limitations                                                                                                            |
+| ---------------- | ---------- | --------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| Netlify          | Serverless | Automatic from GitHub | Supported, PRs          | Requires Express.JS serverless wrapper, does not support all Express.JS features                                       |
+| Render           | Persistent | Automatic from GitHub | Supported, PRs          | Backend is stopped after inactivity, startup time is slow                                                              |
+| Fly.io           | Persistent | Manual                | None                    | Free tier limited to two backends, or one backend and one database.                                                    |
+| Glitch           | Persistent | Manual                | None                    | Backend is stopped after inactivity, startup time is slow. Not designed for production system                          |
+| Cloudflare Pages | Serverless | Automatic from GitHub | Supported, All branches | Does not support Express.JS serverless wrapper at all, backend needs to be written in a different framework, like Hono |
+
+## Database
+
+| Provider      | Type                   | Integration                                         | Limitations                                                                                            |
+| ------------- | ---------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
+| Supabase      | Relational, PostgreSQL | None                                                | Stops after one week of inactivity                                                                     |
+| Render        | Relational, PostgreSQL | Integrates with Render based backends automatically | Gets deleted after 3 months without payment                                                            |
+| Fly.io        | Relational, PostgreSQL | Integrates with fly.io based backends automatically | Free tier limited to one backend and one database. Database can only be accessed from Fly.io backends. |
+| Cloudflare D1 | Relational, SQLite     | Integrates with Cloudflare Pages automatically      | Not following the Postgres SQL standard                                                                |