|
| 1 | + |
| 2 | +# Summary and term values are used in both the page meta tags and also the auto generated |
| 3 | +# open graph and twitter card images. Those 2 fields should not exceed the following character counts: |
| 4 | +# term: 30 |
| 5 | +# summary: 250 |
| 6 | + |
1 | 7 | - term: 'Atomic deploys' |
2 | 8 | id: 'atomic' |
| 9 | + summary: 'Contained and complete deploys, which begin being served only when all of their assets and config are complete and totally in place.' |
3 | 10 | definition: 'The word "atomic" is used to describe deploys which include no interim state or maintenance window. With atomic deploys, all of the code, assets and configuration of a site are updated at once so that a website cannot be be served in a partially updated state. |
4 | 11 | |
5 | 12 |
|
6 | | - While deploying and updating sites via FTP was once popular this would result in some updated files being present on the server and ready to serve while others were still in transit. Modern platforms avoid this situation by providing atomic deploys where the new version of the site only begins receiving request when all assets and configurations are available. See also [Immutable builds](/glossary/immutable).' |
| 13 | + While deploying and updating sites via FTP was once popular this would result in some updated files being present on the server and ready to serve while others were still in transit. Modern platforms avoid this situation by providing atomic deploys where the new version of the site only begins receiving request when all assets and configurations are available. See also [Immutable deploys](/glossary/immutable).' |
7 | 14 |
|
8 | 15 | - term: 'Immutable deploys' |
9 | 16 | id: 'immutable' |
10 | | - definition: 'While a "mutable" item can change (be mutated) over time, an "immutable" item cannot. Once created, an immutable build of a website becomes an artefact which will not change. Instead, deploys result in new versions or instances of the site, and traffic is routed to them accordingly. |
| 17 | + summary: 'Once created, an immutable deploy of a website becomes an artifact which will not change. It is a known version of the site which can be redeployed with ease.' |
| 18 | + definition: 'While a "mutable" item can change (be mutated) over time, an "immutable" item cannot. Once created, an immutable deploy of a website becomes an artifact which will not change. Instead, deploys result in new versions or instances of the site, and traffic is routed to them accordingly. |
11 | 19 | |
12 | 20 | |
13 | 21 | When paired with [atomic deploys](/glossary/atomic), immutable builds make it possible for sites to enjoy abilities such as instant rollbacks and versioning, and help to ensure that the code and assets of a website can be maintained in a known state.' |
14 | 22 |
|
15 | 23 |
|
16 | 24 | - term: 'CDN (Content Delivery Network)' |
17 | 25 | id: 'cdn' |
| 26 | + summary: 'A network of optimized for serving assets to users. A CDN can provide redundancy and also improve delivery performance as a result of being geographically distributed.' |
18 | 27 | definition: 'A distributed network optimized for serving assets to users. By being geographically distributed, a CDN can provide redundancy and also improve delivery performance as a result of servicing requests from the infrastructure closest to the user making the request.' |
19 | 28 |
|
20 | 29 | - term: 'Edge Network' |
21 | 30 | id: 'edge-network' |
22 | 31 |
|
23 | 32 | - term: 'Serverless' |
| 33 | + summary: 'Serverless functions are a means of providing a run-time environment for code without the need for knowledge of, or control over, the underlying environment.' |
24 | 34 | definition: '"Serverless" or "serverless functions" are a means of providing a run-time environment for code without the need for knowledge of, or control over, the underlying environment. [It allows event-driven logic on the server without setting up infrastructure](https://twitter.com/sarah_edo/status/1361692489384517634). |
25 | 35 | |
26 | 36 | |
|
29 | 39 |
|
30 | 40 | - term: 'Pre-render / Pre-generate' |
31 | 41 | id: 'pre-render' |
| 42 | + summary: 'To generate the markup which represents a view of in advance of when it is required instead of just-in-time in response to requests.' |
32 | 43 | definition: 'To generate the markup which represents a view in advance of when it is required. This happens during a build rather than on-demand so that web servers do not need to perform this activity for each request recieved.' |
33 | 44 |
|
34 | 45 | - term: 'Server render' |
35 | 46 | id: 'server-render' |
| 47 | + summary: 'To generate markup on the server rather than on the client. Server render usually refers to the process happening at request time, rather than in advance at build time.' |
36 | 48 | definition: 'To generate markup on the server rather than on the client. Server render usually refers to the process happening at request time, rather than at build time. Some do use this term as a catch all for any rendering taking place on a server, and so disambiguation is often sensible.' |
37 | 49 |
|
38 | 50 | - term: 'Static site generator' |
39 | 51 | id: 'ssg' |
| 52 | + summary: 'A tool which can transform content, data, and templates into files that can be deployed to a hosting environment as a ready-to-serve web site.' |
40 | 53 | definition: "A tool which can be run as part of a build to transform content, data, and templates into files which can be deployed to a hosting environment as a ready-to-serve web site. Find a more detailed description in this article: <a href='https://www.netlify.com/blog/2020/04/14/what-is-a-static-site-generator-and-3-ways-to-find-the-best-one/?utm_source=jamstackorg&utm_medium=what-are-ssg-pnh&utm_campaign=devex'>What is a Static Site Generator? And 3 ways to find the best one</a>." |
41 | 54 |
|
42 | 55 | - term: 'Headless technology' |
43 | 56 | id: 'headless-technology' |
| 57 | + summary: 'Often referring to decoupled content management systems, headless tools have no responsibility for generating the view or presentation of content, but instead focus on the management of and access to content via APIs.' |
44 | 58 | definition: 'The term "headless" refers to removing the dependency of knowing where data will be displayed and instead just holding the data to be used wherever the developer chooses. This is often used to describe a CMS where content can be entered, held, then where and how that content is displayed is decided separately.' |
45 | 59 |
|
46 | 60 | - term: 'Client render' |
47 | 61 | id: 'client-render' |
| 62 | + summary: 'To generate the view of content, or update user interface elements, in the browser using JavaScript.' |
48 | 63 | definition: 'To generate the view of content in the browser using JavaScript. This often involves transmitting data to the browser rather than markup which is ready for the browser to display, and then using JavaScript to transform that data into a view by modifying the DOM' |
49 | 64 |
|
50 | 65 | - term: 'Hydration' |
51 | 66 | id: 'hydration' |
52 | 67 |
|
53 | 68 | - term: 'Decoupling' |
54 | 69 | id: 'decoupling' |
| 70 | + summary: 'Creating a distinct separation between systems or services. By decoupling the services needed to operate a site, each component part can be more easily swapped out, upgraded, and understood.' |
55 | 71 | definition: 'Decoupling is the process of creating a clean separation between systems or services. By decoupling the services needed to operate a site, each component part can become easier to reason about, can be independently swapped out or upgraded, and can be designated the purview of dedicated specialists either within an organization, or as a third party.' |
56 | 72 |
|
57 | 73 | - term: 'Dynamic server' |
58 | 74 | id: 'dynamic-server' |
59 | 75 |
|
60 | 76 | - term: 'API' |
61 | 77 | id: 'api' |
| 78 | + summary: 'API is the acronym for Application Programming Interface. It defines interactions that allows two applications to talk to each other.' |
62 | 79 | definition: 'API is the acronym for Application Programming Interface. It defines interactions that allows two applications to talk to each other.' |
63 | 80 |
|
64 | 81 | - term: 'API Economy' |
65 | 82 | id: 'api-economy' |
| 83 | + summary: 'A term that has come to mean the depth and breadth of APIs that are available for developers to use in the current landscape.' |
66 | 84 | definition: 'A term that has come to mean the depth and breadth of APIs that are available for developers to use in the current landscape.' |
67 | 85 |
|
68 | 86 | - term: 'Microservice' |
69 | 87 | id: 'microservice' |
| 88 | + summary: 'A programming paradigm where many parts of a large application are broken down into various units that have smaller responsibility.' |
70 | 89 | definition: 'A programming paradigm where many parts of a large application are broken down into various units that have smaller responsibility. We can use Serverless or APIs for this, but it''s not that APIs or Serverless are necessarily Microservices, it''s that we have split apart what we want to access, and that modularity is what we call Microservices.' |
71 | 90 |
|
72 | 91 | - term: 'Monolith' |
|
0 commit comments