mirror of
https://github.com/kamranahmedse/developer-roadmap.git
synced 2026-03-15 11:21:46 +08:00
Compare commits
22 Commits
content/sy
...
content/gr
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
5abd6f2927 | ||
|
|
c2ce8ed50a | ||
|
|
6b836f4912 | ||
|
|
7c14032d45 | ||
|
|
463e047849 | ||
|
|
b074e64854 | ||
|
|
9ac1c1c8cb | ||
|
|
e3a6fda3c7 | ||
|
|
1ca0afbed9 | ||
|
|
f16bd09a47 | ||
|
|
f5fcf1dccc | ||
|
|
ac8711a0aa | ||
|
|
4745811114 | ||
|
|
12c1773965 | ||
|
|
ff0215673c | ||
|
|
f5e980d8ec | ||
|
|
6187b1dc52 | ||
|
|
a3b8b5653a | ||
|
|
8f8e2f41d8 | ||
|
|
89a436a5b7 | ||
|
|
231e295f01 | ||
|
|
64e20e9fc1 |
@@ -2,13 +2,18 @@ const fs = require('node:fs');
|
||||
const path = require('node:path');
|
||||
|
||||
const jsonsDir = path.join(process.cwd(), 'public/jsons');
|
||||
const jsonFiles = fs.readdirSync(jsonsDir);
|
||||
const childJsonDirs = fs.readdirSync(jsonsDir);
|
||||
|
||||
jsonFiles.forEach((jsonFileName) => {
|
||||
console.log(`Compressing ${jsonFileName}...`);
|
||||
childJsonDirs.forEach((childJsonDir) => {
|
||||
const fullChildJsonDirPath = path.join(jsonsDir, childJsonDir);
|
||||
const jsonFiles = fs.readdirSync(fullChildJsonDirPath);
|
||||
|
||||
const jsonFilePath = path.join(jsonsDir, jsonFileName);
|
||||
const json = require(jsonFilePath);
|
||||
jsonFiles.forEach((jsonFileName) => {
|
||||
console.log(`Compressing ${jsonFileName}...`);
|
||||
|
||||
fs.writeFileSync(jsonFilePath, JSON.stringify(json));
|
||||
const jsonFilePath = path.join(fullChildJsonDirPath, jsonFileName);
|
||||
const json = require(jsonFilePath);
|
||||
|
||||
fs.writeFileSync(jsonFilePath, JSON.stringify(json));
|
||||
});
|
||||
});
|
||||
|
||||
@@ -82,7 +82,7 @@ function prepareDirTree(control, dirTree, dirSortOrders) {
|
||||
return { dirTree, dirSortOrders };
|
||||
}
|
||||
|
||||
const roadmap = require(path.join(__dirname, `../public/jsons/${roadmapId}`));
|
||||
const roadmap = require(path.join(__dirname, `../public/jsons/roadmaps/${roadmapId}`));
|
||||
const controls = roadmap.mockup.controls.control;
|
||||
|
||||
// Prepare the dir tree that we will be creating and also calculate the sort orders
|
||||
|
||||
@@ -3,10 +3,10 @@
|
||||
First of all thank you for considering to contribute. Please look at the details below:
|
||||
|
||||
- [Contribution](#contribution)
|
||||
- [New Roadmaps](#new-roadmaps)
|
||||
- [Existing Roadmaps](#existing-roadmaps)
|
||||
- [Adding Content](#adding-content)
|
||||
- [Guidelines](#guidelines)
|
||||
- [New Roadmaps](#new-roadmaps)
|
||||
- [Existing Roadmaps](#existing-roadmaps)
|
||||
- [Adding Content](#adding-content)
|
||||
- [Guidelines](#guidelines)
|
||||
|
||||
## New Roadmaps
|
||||
|
||||
@@ -23,7 +23,7 @@ For the existing roadmaps, please follow the details listed for the nature of co
|
||||
|
||||
## Adding Content
|
||||
|
||||
Find [the content directory inside the relevant roadmap](https://github.com/kamranahmedse/roadmap-astro/tree/master/src/roadmaps). Please keep the following guidelines in mind when submitting content:
|
||||
Find [the content directory inside the relevant roadmap](https://github.com/kamranahmedse/developer-roadmap/tree/master/src/roadmaps). Please keep the following guidelines in mind when submitting content:
|
||||
|
||||
- Content must be in English.
|
||||
- Put a brief description about the topic on top of the file and the a list of links below with each link having title of the URL.
|
||||
|
||||
@@ -32,6 +32,7 @@
|
||||
"@tailwindcss/typography": "^0.5.9",
|
||||
"gh-pages": "^4.0.0",
|
||||
"json-to-pretty-yaml": "^1.2.2",
|
||||
"markdown-it": "^13.0.1",
|
||||
"prettier": "^2.8.3",
|
||||
"prettier-plugin-astro": "^0.7.2"
|
||||
}
|
||||
|
||||
33
pnpm-lock.yaml
generated
33
pnpm-lock.yaml
generated
@@ -9,6 +9,7 @@ specifiers:
|
||||
astro-compress: ^1.1.27
|
||||
gh-pages: ^4.0.0
|
||||
json-to-pretty-yaml: ^1.2.2
|
||||
markdown-it: ^13.0.1
|
||||
node-html-parser: ^6.1.4
|
||||
npm-check-updates: ^16.6.2
|
||||
prettier: ^2.8.3
|
||||
@@ -33,6 +34,7 @@ devDependencies:
|
||||
'@tailwindcss/typography': 0.5.9_tailwindcss@3.2.4
|
||||
gh-pages: 4.0.0
|
||||
json-to-pretty-yaml: 1.2.2
|
||||
markdown-it: 13.0.1
|
||||
prettier: 2.8.3
|
||||
prettier-plugin-astro: 0.7.2
|
||||
|
||||
@@ -937,7 +939,6 @@ packages:
|
||||
|
||||
/argparse/2.0.1:
|
||||
resolution: {integrity: sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==}
|
||||
dev: false
|
||||
|
||||
/array-iterate/2.0.1:
|
||||
resolution: {integrity: sha512-I1jXZMjAgCMmxT4qxXfPXa6SthSoE8h6gkSI9BGGNv8mP8G/v0blc+qFnZu6K42vTOiuME596QaLO0TP3Lk0xg==}
|
||||
@@ -1777,6 +1778,11 @@ packages:
|
||||
once: 1.4.0
|
||||
dev: false
|
||||
|
||||
/entities/3.0.1:
|
||||
resolution: {integrity: sha512-WiyBqoomrwMdFG1e0kqvASYfnlb0lp8M5o5Fw2OFq1hNZxxcNk8Ik0Xm7LxzBhuidnZB/UtBqVCgUz3kBOP51Q==}
|
||||
engines: {node: '>=0.12'}
|
||||
dev: true
|
||||
|
||||
/entities/4.4.0:
|
||||
resolution: {integrity: sha512-oYp7156SP8LkeGD0GF85ad1X9Ai79WtRsZ2gxJqtBuzH+98YUV6jkHEKlZkMbcrjJjIVJNIDP/3WL9wQkoPbWA==}
|
||||
engines: {node: '>=0.12'}
|
||||
@@ -2993,6 +2999,12 @@ packages:
|
||||
resolution: {integrity: sha512-9JROoBW7pobfsx+Sq2JsASvCo6Pfo6WWoUW79HuB1BCoBXD4PLWJPqDF6fNj67pqBYTbAHkE57M1kS/+L1neOg==}
|
||||
engines: {node: '>=10'}
|
||||
|
||||
/linkify-it/4.0.1:
|
||||
resolution: {integrity: sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==}
|
||||
dependencies:
|
||||
uc.micro: 1.0.6
|
||||
dev: true
|
||||
|
||||
/load-yaml-file/0.2.0:
|
||||
resolution: {integrity: sha512-OfCBkGEw4nN6JLtgRidPX6QxjBQGQf72q3si2uvqyFEMbycSFFHwAZeXx6cJgFM9wmLrf9zBwCP3Ivqa+LLZPw==}
|
||||
engines: {node: '>=6'}
|
||||
@@ -3136,6 +3148,17 @@ packages:
|
||||
- supports-color
|
||||
dev: false
|
||||
|
||||
/markdown-it/13.0.1:
|
||||
resolution: {integrity: sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==}
|
||||
hasBin: true
|
||||
dependencies:
|
||||
argparse: 2.0.1
|
||||
entities: 3.0.1
|
||||
linkify-it: 4.0.1
|
||||
mdurl: 1.0.1
|
||||
uc.micro: 1.0.6
|
||||
dev: true
|
||||
|
||||
/markdown-table/3.0.3:
|
||||
resolution: {integrity: sha512-Z1NL3Tb1M9wH4XESsCDEksWoKTdlUafKc4pt0GRwjUyXaCFZ+dc3g2erqB6zm3szA2IUSi7VnPI+o/9jnxh9hw==}
|
||||
dev: false
|
||||
@@ -3301,6 +3324,10 @@ packages:
|
||||
resolution: {integrity: sha512-GaqWWShW4kv/G9IEucWScBx9G1/vsFZZJUO+tD26M8J8z3Kw5RDQjaoZe03YAClgeS/SWPOcb4nkFBTEi5DUEA==}
|
||||
dev: false
|
||||
|
||||
/mdurl/1.0.1:
|
||||
resolution: {integrity: sha512-/sKlQJCBYVY9Ers9hqzKou4H6V5UWc/M59TH2dvkt+84itfnq7uFOMLpOiOS4ujvHP4etln18fmIxA5R5fll0g==}
|
||||
dev: true
|
||||
|
||||
/merge-stream/2.0.0:
|
||||
resolution: {integrity: sha512-abv/qOcuPfk3URPfDzmZU1LKmuw8kT+0nIHvKrKgFrwifol/doWcdA4ZqsWQ8ENrFKkd67Mfpo/LovbIUsbt3w==}
|
||||
dev: false
|
||||
@@ -5293,6 +5320,10 @@ packages:
|
||||
hasBin: true
|
||||
dev: false
|
||||
|
||||
/uc.micro/1.0.6:
|
||||
resolution: {integrity: sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==}
|
||||
dev: true
|
||||
|
||||
/unherit/3.0.1:
|
||||
resolution: {integrity: sha512-akOOQ/Yln8a2sgcLj4U0Jmx0R5jpIg2IUyRrWOzmEbjBtGzBdHtSeFKgoEcoH4KYIG/Pb8GQ/BwtYm0GCq1Sqg==}
|
||||
dev: false
|
||||
|
||||
1
public/jsons/checklists/frontend-performance.json
Normal file
1
public/jsons/checklists/frontend-performance.json
Normal file
File diff suppressed because one or more lines are too long
@@ -1,3 +1,3 @@
|
||||
<div class='text-sm sm:text-base leading-relaxed text-left p-2 sm:p-4 text-md text-gray-800 border-t border-t-gray-300 bg-gray-100 rounded-bl-md rounded-br-md'>
|
||||
<div class='text-sm sm:text-base leading-relaxed text-left p-2 sm:p-4 text-md text-gray-800 border-t border-t-gray-300 bg-gray-100 rounded-bl-md rounded-br-md [&>p:not(:last-child)]:mb-3 [&>p>a]:underline [&>p>a]:text-blue-500'>
|
||||
<slot />
|
||||
</div>
|
||||
@@ -1,4 +1,5 @@
|
||||
---
|
||||
import { markdownToHtml } from '../../lib/markdown';
|
||||
import Answer from './Answer.astro';
|
||||
import Question from './Question.astro';
|
||||
|
||||
@@ -29,8 +30,8 @@ if (faqs.length === 0) {
|
||||
faqs.map((faq, questionIndex) => (
|
||||
<Question isActive={questionIndex === 0} question={faq.question}>
|
||||
<Answer>
|
||||
{faq.answer.map((answer, index) => (
|
||||
<p class:list={{ 'mb-3': index !== faq.answer.length - 1 }}>{answer}</p>
|
||||
{faq.answer.map((answer) => (
|
||||
<p set:html={markdownToHtml(answer)} />
|
||||
))}
|
||||
</Answer>
|
||||
</Question>
|
||||
|
||||
@@ -1,26 +1,21 @@
|
||||
---
|
||||
import Icon from './Icon.astro';
|
||||
import ResourcesAlert from './ResourcesAlert.astro';
|
||||
import RoadmapNote from './RoadmapNote.astro';
|
||||
import TopicSearch from './TopicSearch/TopicSearch.astro';
|
||||
import YouTubeAlert from './YouTubeAlert.astro';
|
||||
|
||||
export interface Props {
|
||||
title: string;
|
||||
description: string;
|
||||
note?: string;
|
||||
roadmapId: string;
|
||||
isUpcoming?: boolean;
|
||||
hasSearch?: boolean;
|
||||
hasTopics?: boolean;
|
||||
}
|
||||
|
||||
const {
|
||||
title,
|
||||
description,
|
||||
roadmapId,
|
||||
isUpcoming = false,
|
||||
hasSearch = false,
|
||||
hasTopics = false,
|
||||
} = Astro.props;
|
||||
const { title, description, roadmapId, isUpcoming = false, hasSearch = false, note, hasTopics = false } = Astro.props;
|
||||
|
||||
const isRoadmapReady = !isUpcoming;
|
||||
---
|
||||
@@ -114,3 +109,5 @@ const isRoadmapReady = !isUpcoming;
|
||||
{hasSearch && <TopicSearch />}
|
||||
</div>
|
||||
</div>
|
||||
|
||||
{note && <RoadmapNote text={note} />}
|
||||
|
||||
19
src/components/RoadmapNote.astro
Normal file
19
src/components/RoadmapNote.astro
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
import { Debug } from 'astro/components';
|
||||
import { markdownToHtml } from '../lib/markdown';
|
||||
|
||||
export interface Props {
|
||||
text: string;
|
||||
}
|
||||
|
||||
const { text } = Astro.props;
|
||||
---
|
||||
|
||||
<div class='bg-gray-50'>
|
||||
<div class='container pt-1'>
|
||||
<p
|
||||
class='text-sm bg-yellow-100 text-yellow-900 p-2 rounded-md mt-2 sm:mt-5 mb-0 sm:-mb-6 z-10 relative [&>a]:underline'
|
||||
set:html={markdownToHtml(text.trim())}
|
||||
/>
|
||||
</div>
|
||||
</div>
|
||||
8
src/lib/markdown.ts
Normal file
8
src/lib/markdown.ts
Normal file
@@ -0,0 +1,8 @@
|
||||
// @ts-ignore
|
||||
import MarkdownIt from 'markdown-it';
|
||||
|
||||
export function markdownToHtml(markdown: string): string {
|
||||
const md = new MarkdownIt();
|
||||
|
||||
return md.renderInline(markdown);
|
||||
}
|
||||
@@ -12,6 +12,7 @@ export interface RoadmapFrontmatter {
|
||||
hasTopics: boolean;
|
||||
isNew: boolean;
|
||||
isUpcoming: boolean;
|
||||
note?: string;
|
||||
dimensions?: {
|
||||
width: number;
|
||||
height: number;
|
||||
|
||||
@@ -57,8 +57,9 @@ if (roadmapFAQs.length) {
|
||||
jsonLd={jsonLdSchema}
|
||||
>
|
||||
<RoadmapHeader
|
||||
description={roadmapData.description}
|
||||
title={roadmapData.title}
|
||||
description={roadmapData.description}
|
||||
note={roadmapData.note}
|
||||
roadmapId={roadmapId}
|
||||
hasTopics={roadmapData.hasTopics}
|
||||
isUpcoming={roadmapData.isUpcoming}
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
# jsonUrl: "/jsons/android.json"
|
||||
# jsonUrl: "/jsons/roadmaps/android.json"
|
||||
pdfUrl: "/pdfs/android.pdf"
|
||||
order: 4
|
||||
featuredTitle: "Android"
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
jsonUrl: "/jsons/angular.json"
|
||||
jsonUrl: "/jsons/roadmaps/angular.json"
|
||||
pdfUrl: "/pdfs/angular.pdf"
|
||||
order: 3
|
||||
featuredTitle: "Angular"
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
jsonUrl: "/jsons/aspnet-core.json"
|
||||
jsonUrl: "/jsons/roadmaps/aspnet-core.json"
|
||||
pdfUrl: "/pdfs/aspnet-core.pdf"
|
||||
order: 9
|
||||
featuredTitle: "ASP.NET Core"
|
||||
featuredDescription: "Step by step guide to becoming an ASP.NET Core Developer in 2023"
|
||||
title: "ASP.NET Core Developer"
|
||||
description: "Step by step guide to becoming an ASP.NET core developer in 2023"
|
||||
isNew: true
|
||||
isNew: false
|
||||
hasTopics: true
|
||||
dimensions:
|
||||
width: 968
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
jsonUrl: "/jsons/backend.json"
|
||||
jsonUrl: "/jsons/roadmaps/backend.json"
|
||||
pdfUrl: "/pdfs/backend.pdf"
|
||||
order: 2
|
||||
featuredTitle: "Backend"
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
jsonUrl: "/jsons/blockchain.json"
|
||||
jsonUrl: "/jsons/roadmaps/blockchain.json"
|
||||
pdfUrl: "/pdfs/blockchain.pdf"
|
||||
order: 6
|
||||
featuredTitle: "Blockchain"
|
||||
featuredDescription: "Step by step guide to becoming a blockchain developer in 2023"
|
||||
title: "Blockchain Developer"
|
||||
description: "Step by step guide to becoming a blockchain developer in 2023."
|
||||
isNew: true
|
||||
isNew: false
|
||||
hasTopics: true
|
||||
dimensions:
|
||||
width: 968
|
||||
|
||||
@@ -5,3 +5,5 @@ Zero-knowledge rollups (ZK-rollups) are layer 2 scaling solutions that increase
|
||||
Visit the following resources to learn more:
|
||||
|
||||
- [Zero-Knowledge Rollups - Ethereum](https://ethereum.org/en/developers/docs/scaling/zk-rollups)
|
||||
- [Why and How zk-SNARK Works](https://medium.com/@imolfar/why-and-how-zk-snark-works-1-introduction-the-medium-of-a-proof-d946e931160)
|
||||
- [Introduction to zk-SNARKs](https://vitalik.ca/general/2021/01/26/snarks.html)
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
jsonUrl: "/jsons/computer-science.json"
|
||||
jsonUrl: "/jsons/roadmaps/computer-science.json"
|
||||
pdfUrl: "/pdfs/computer-science.pdf"
|
||||
order: 1
|
||||
featuredTitle: "Computer Science"
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
---
|
||||
jsonUrl: "/jsons/design-system.json"
|
||||
jsonUrl: "/jsons/roadmaps/design-system.json"
|
||||
pdfUrl: "/pdfs/design-system.pdf"
|
||||
order: 13
|
||||
featuredTitle: "Design System"
|
||||
featuredDescription: "Step by step guide to building a modern Design System"
|
||||
title: "Design System"
|
||||
description: "Learn how to create a design system with this step by step guide"
|
||||
isNew: true
|
||||
isNew: false
|
||||
hasTopics: true
|
||||
note: "**Note:** System Design is a different topic, visit [System Design roadmap](/system-design) for that."
|
||||
dimensions:
|
||||
width: 968
|
||||
height: 2309.7
|
||||
@@ -16,7 +17,7 @@ schema:
|
||||
description: "Learn how to create a Design System with this interactive step by step guide in 2023. We also have resources and short descriptions attached to the roadmap items so you can get everything you want to learn in one place."
|
||||
imageUrl: "https://roadmap.sh/roadmaps/design-system.png"
|
||||
datePublished: "2023-01-05"
|
||||
dateModified: "2023-01-20"
|
||||
dateModified: "2023-01-19"
|
||||
seo:
|
||||
title: "How to Create a Design System"
|
||||
description: "Learn how to create a design system or become a design system engineer with this step by step guide with resources."
|
||||
@@ -54,5 +55,4 @@ tags:
|
||||
- "roadmap"
|
||||
- "main-sitemap"
|
||||
- "skill-roadmap"
|
||||
---
|
||||
|
||||
---
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
jsonUrl: "/jsons/devops.json"
|
||||
jsonUrl: "/jsons/roadmaps/devops.json"
|
||||
pdfUrl: "/pdfs/devops.pdf"
|
||||
order: 3
|
||||
featuredTitle: "DevOps"
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
jsonUrl: "/jsons/flutter.json"
|
||||
jsonUrl: "/jsons/roadmaps/flutter.json"
|
||||
pdfUrl: "/pdfs/flutter.pdf"
|
||||
order: 10
|
||||
featuredTitle: "Flutter"
|
||||
|
||||
@@ -5,7 +5,7 @@ export const faqs: FAQType[] = [
|
||||
{
|
||||
question: 'What is Frontend Development?',
|
||||
answer: [
|
||||
"Front-end development is the development of visual and interactive elements of a website that users interact with directly. It's a combination of HTML, CSS and JavaScript, where HTML provides the structure, CSS the styling and layout, and JavaScript the dynamic behaviour and interactivity.",
|
||||
"Front-end development is the development of visual and interactive elements of a website that users interact with directly. It's a combination of HTML, CSS and [JavaScript](/javascript), where HTML provides the structure, CSS the styling and layout, and JavaScript the dynamic behaviour and interactivity.",
|
||||
"As a front-end developer, you'll be responsible for creating the user interface of a website, to ensure it looks good and is easy to use, with great focus on design principles and user experience. You'll be working closely with designers, back-end developers, and project managers to make sure the final product meets the client's needs and provides the best possible experience for the end-users.",
|
||||
],
|
||||
},
|
||||
@@ -19,7 +19,7 @@ export const faqs: FAQType[] = [
|
||||
{
|
||||
question: 'How to become a Frontend Developer?',
|
||||
answer: [
|
||||
"Start with learning HTML and CSS; don't wait to fully master these and start building simple projects as soon as possible. You could try rebuilding the frontend of your favorite websites using HTML and CSS to start with. Do as many of these projects as possible as you keep learning. Once you are somewhat comfortable with HTML and CSS, start learning some basic JavaScript (DOM manipulation, making AJAX calls etc) and learn how to add interactivity to your websites. While you are at it learn some basics of Git and GitHub. At this point you should be able to get an entry level frontend development job. Keep revisiting this roadmap and try to fill the gaps in your knowledge.",
|
||||
"Start with learning HTML and CSS; don't wait to fully master these and start building simple projects as soon as possible. You could try rebuilding the frontend of your favorite websites using HTML and CSS to start with. Do as many of these projects as possible as you keep learning. Once you are somewhat comfortable with HTML and CSS, start [learning some basic JavaScript](/javascript) (DOM manipulation, making AJAX calls etc) and learn how to add interactivity to your websites. While you are at it learn some basics of Git and GitHub. At this point you should be able to get an entry level frontend development job. Keep revisiting this roadmap and try to fill the gaps in your knowledge.",
|
||||
],
|
||||
},
|
||||
{
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
jsonUrl: "/jsons/frontend.json"
|
||||
jsonUrl: "/jsons/roadmaps/frontend.json"
|
||||
pdfUrl: "/pdfs/frontend.pdf"
|
||||
order: 1
|
||||
featuredTitle: "Frontend"
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
jsonUrl: "/jsons/golang.json"
|
||||
jsonUrl: "/jsons/roadmaps/golang.json"
|
||||
pdfUrl: "/pdfs/golang.pdf"
|
||||
order: 8
|
||||
order: 11
|
||||
featuredTitle: "Go"
|
||||
featuredDescription: "Step by step guide to becoming a Go developer in 2023"
|
||||
title: "Go Developer"
|
||||
|
||||
@@ -1 +1,10 @@
|
||||
# What is graphql
|
||||
# What is GraphQL
|
||||
|
||||
GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data.
|
||||
|
||||
A GraphQL service is created by defining types and fields on those types, then providing functions for each field on each type.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Introduction to graphQL](https://graphql.org/learn/)
|
||||
- [Tutorial - What is graphQL?](https://www.howtographql.com/basics/0-introduction/)
|
||||
@@ -1 +1,11 @@
|
||||
# Problems graphql solves
|
||||
# Problems GraphQL Solves
|
||||
|
||||
GraphQL solves several problems commonly faced when building APIs, including:
|
||||
|
||||
- **Over-fetching:** With REST APIs, the client often receives more data than it needs, resulting in wasted bandwidth and slow performance. GraphQL allows the client to specify exactly the data it needs, reducing over-fetching.
|
||||
|
||||
- **Under-fetching:** With REST, the client often has to make multiple requests to different endpoints to gather all the data it needs, resulting in additional latency and complexity. GraphQL allows the client to request all the necessary data in a single request.
|
||||
|
||||
- **Inefficient versioning:** With REST, creating a new endpoint for each version of an API can quickly become cumbersome and hard to maintain. GraphQL allows for seamless versioning by adding new fields and types, rather than creating new endpoints.
|
||||
|
||||
- **Lack of flexibility:** REST APIs are typically fixed, meaning that the client has to work with the data structure provided by the API. GraphQL allows the client to request exactly the data it needs and receive it in a predictable format, increasing flexibility.
|
||||
@@ -1 +1,9 @@
|
||||
# Thinking in graphs
|
||||
# Thinking in Graphs
|
||||
|
||||
"Thinking in Graphs" is a mindset or approach when working with GraphQL. It refers to the way that data is organized and queried in GraphQL, which is based on the concept of a graph.
|
||||
|
||||
In GraphQL, data is represented as a graph, where nodes represent objects and edges represent relationships between them. This allows for a more flexible and intuitive way of querying data, as the client can specify exactly the data it needs by following the relationships between nodes in the graph.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [GraphQL - Thinking in Graphs](https://graphql.org/learn/thinking-in-graphs/)
|
||||
@@ -1 +1,11 @@
|
||||
# Graphql on the frontend
|
||||
# GraphQL on the Frontend
|
||||
|
||||
In GraphQL, the frontend refers to the client-side of the application, typically the web or mobile app that the end-user interacts with.
|
||||
|
||||
When using GraphQL on the frontend, developers can use a GraphQL client library, such as Apollo Client or Relay, to interact with the GraphQL server. These libraries provide a way to easily send GraphQL queries and mutations to the server and handle the response.
|
||||
|
||||
By using GraphQL on the frontend, developers can benefit from the flexibility and efficiency of GraphQL when querying data. Instead of having to make multiple REST API calls or hardcode data into the frontend, the client can specify exactly the data it needs in a single request, and the server will return it in a predictable format.
|
||||
|
||||
Learn more from following links:
|
||||
|
||||
- [Get started with GraphQL on the frontend](https://www.howtographql.com/react-apollo/0-introduction/)
|
||||
@@ -1 +1,11 @@
|
||||
# Graphql on the backend
|
||||
# GraphQL on the Backend
|
||||
|
||||
In GraphQL, the backend refers to the server-side of the application, where the data is stored and processed.
|
||||
|
||||
When using GraphQL on the backend, developers can create a GraphQL server that handles the incoming GraphQL queries and mutations from the frontend. This can be implemented using a GraphQL library or framework, such as Apollo Server, Express-GraphQL, or GraphQL-Java.
|
||||
|
||||
The GraphQL server is responsible for handling the incoming queries and mutations, validating them against a schema, and executing them by fetching data from the database or other data sources. The server then returns the requested data to the client in a predictable format, as defined by the schema.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [How to use GraphQL in Backend?](https://www.howtographql.com/)
|
||||
@@ -1 +1,12 @@
|
||||
# Graphql introduction
|
||||
# GraphQL Introduction
|
||||
|
||||
GraphQL is a query language and runtime for APIs. It is used to build and consume web service APIs.
|
||||
|
||||
GraphQL allows clients to make a single API call to request exactly the data they need, in a predictable format. This allows for more efficient and flexible data retrieval, compared to traditional REST APIs where the client has to make multiple API calls to different endpoints, and may receive more data than it needs.
|
||||
|
||||
With GraphQL, the client defines the structure of the data it needs, by sending a query to the server. The server then returns the requested data in the same structure, as defined by the query. The client can also make mutations to update or create data on the server.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Introduction to GraphQL](https://graphql.org/learn/)
|
||||
- [Getting started with GraphQL](https://graphql.org/)
|
||||
@@ -1 +1,7 @@
|
||||
# What are queries
|
||||
# What are Queries
|
||||
|
||||
In GraphQL, a query is a request made by the client to the server to retrieve data. Queries are used to fetch data from the server and are structured as a hierarchical tree of fields, which correspond to the properties of the data being requested.
|
||||
|
||||
Learn more from following links:
|
||||
|
||||
- [Introduction of GraphQL - Query](https://graphql.org/learn/queries/)
|
||||
@@ -1 +1,9 @@
|
||||
# Fields
|
||||
# Fields
|
||||
|
||||
In GraphQL, fields are the individual pieces of data that can be queried or modified. They represent the properties of the data being requested or modified, and are the building blocks of queries and mutations.
|
||||
|
||||
Fields are defined in the GraphQL schema, which is a blueprint of the data that can be queried and modified. The schema defines the types of data that can be queried, and the fields that are available for each type.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [GraphQL: Types and Fields](https://graphql.org/learn/queries/#fields)
|
||||
@@ -1 +1,7 @@
|
||||
# Aliases
|
||||
# Aliases
|
||||
|
||||
Aliases in GraphQL are a way to rename fields when they are requested in a query. They are useful in situations where a field is requested multiple times, but with different arguments, or when the field has a name that is not suitable for the client's usage. They make it easy to distinguish and work with fields in the response and make the query more readable.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [What are GraphQL Aliases?](https://graphql.org/learn/queries/#aliases)
|
||||
@@ -1 +1,7 @@
|
||||
# Arguments
|
||||
# Arguments
|
||||
|
||||
Arguments in GraphQL are pieces of information that are passed to a field or a directive to specify additional details about how the field should be executed. They can be used to filter, sort, or paginate data, or to specify additional options when creating, updating, or deleting data. They can be passed as key-value pairs, defined as variables, and can be optional or required.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [GraphQL - Arguments](https://graphql.org/learn/queries/#arguments)
|
||||
@@ -1 +1,7 @@
|
||||
# Directives
|
||||
# Directives
|
||||
|
||||
Directives in GraphQL are a way to modify the execution of a query or a field. They are used to add additional behavior or validation to a query or a field, and can be applied to fields, operations (queries and mutations) and fragments. Directives can take one or more arguments to configure their behavior, and can be defined by the developer or used one of the built-in directives provided by GraphQL.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Directives in GraphQL](https://graphql.org/learn/queries/#directives)
|
||||
@@ -1 +1,8 @@
|
||||
# Variables
|
||||
# Variables
|
||||
|
||||
Variables in GraphQL are a way to pass dynamic values to a query or a mutation. They allow the client to make a query more dynamic and flexible by passing in different values for the same argument. They are defined in the query or mutation using the **$** symbol followed by the variable name and a type, and their values must be passed in a separate JSON object. They also are type-safe, this means that variables must be passed values that are of the same type as defined in the query.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [GraphQL Variables](https://dgraph.io/docs/graphql/api/variables/)
|
||||
- [Intro to Variables in GraphQL](https://graphql.org/learn/queries/#variables)
|
||||
@@ -1 +1,7 @@
|
||||
# Fragments
|
||||
# Fragments
|
||||
|
||||
In GraphQL, a fragment is a reusable piece of a GraphQL query that can be used to retrieve specific fields from one or more types of data. A fragment is defined using the "fragment" keyword, followed by the name of the fragment and the type of data it is querying. The fields to be retrieved are then specified within curly braces.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Intro to Fragments in GraphQL](https://graphql.org/learn/queries/#fragments)
|
||||
@@ -1 +1,9 @@
|
||||
# Graphql queries
|
||||
# GraphQL Queries
|
||||
|
||||
GraphQL is a query language for APIs. It provides a simple and flexible syntax for making requests to a server to retrieve specific data. In GraphQL, a query is a request made to the server to fetch data. The query specifies the fields of the data that should be returned, and the server responds with the requested data.
|
||||
|
||||
A GraphQL query is structured as a single object, with a "query" or "mutation" field at the top level. The "query" field is used to retrieve data, while the "mutation" field is used to make changes to the data. The query is written in a specific format and is executed by the server to retrieve the requested data.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [What are GraphQL Queries?](https://graphql.org/learn/queries/)
|
||||
@@ -1 +1,9 @@
|
||||
# What are mutations
|
||||
# What are Mutations
|
||||
|
||||
In GraphQL, a mutation is a type of query used to make changes to data on the server. It is used to create, update, or delete data, and is structured similarly to a query, but with a "mutation" field at the top level instead of a "query" field.
|
||||
|
||||
A mutation typically includes fields that specify the data to be changed and the operation to be performed (e.g. "create", "update", or "delete"). It can also include arguments to specify the specific data to be affected.
|
||||
|
||||
Learn more from the following resources:
|
||||
|
||||
- [Get started with Mutations](https://graphql.org/learn/queries/#mutations)
|
||||
@@ -1 +1,7 @@
|
||||
# Multiple mutation fields
|
||||
# Multiple Mutation Fields
|
||||
|
||||
In GraphQL, it is possible to perform multiple mutations in a single query by including multiple "mutation" fields in the query. This is called "batching" or "chaining" mutations.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Guide to Multiple fields in mutations](https://graphql.org/learn/queries/#multiple-fields-in-mutations)
|
||||
@@ -1 +1,7 @@
|
||||
# Operation name
|
||||
# Operation Name
|
||||
|
||||
In GraphQL, an operation name is an optional identifier that can be used to uniquely identify a query or a mutation in a document containing multiple operations. It can be used to provide more meaningful names for operations, making it easier to understand the purpose of the operation and to identify it in the event of an error.
|
||||
|
||||
Learn more from the following resources:
|
||||
|
||||
- [Intro to Operation Name](https://graphql.org/learn/queries/#operation-name)
|
||||
@@ -1 +1,9 @@
|
||||
# Mutations
|
||||
# Mutations
|
||||
|
||||
In GraphQL, a mutation is a type of query used to make changes to the data on the server, such as creating, updating, or deleting data. A mutation is structured similarly to a query, but with a "mutation" field at the top level instead of a "query" field.
|
||||
|
||||
The mutation includes fields that specify the data to be changed, the operation to be performed (create, update or delete) and also can include arguments to specify the specific data to be affected.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Getting started with Mutations](https://graphql.org/learn/queries/#mutations)
|
||||
@@ -1 +1,9 @@
|
||||
# What are subscriptions
|
||||
# What are Subscriptions
|
||||
|
||||
In GraphQL, subscriptions are a way to push real-time updates to the client. They allow a client to subscribe to a specific event or data change on the server, and receive updates in real-time as soon as the event occurs or the data changes.
|
||||
|
||||
Subscriptions are defined on the server and are structured similar to queries and mutations. They have a "subscription" field at the top level, followed by the fields that define the event or data change to be subscribed to.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [How GraphQL Subscriptions Work?](https://the-guild.dev/blog/subscriptions-and-live-queries-real-time-with-graphql)
|
||||
@@ -1 +1,5 @@
|
||||
# Event based subscriptions
|
||||
# Event Based Subscriptions
|
||||
|
||||
Event-based subscriptions in GraphQL are a way to push real-time updates to the client based on specific events that occur on the server. These events can be triggered by external sources such as user actions, sensor data, or other systems, or by internal actions such as database updates.
|
||||
|
||||
With event-based subscriptions, the client can subscribe to a specific event or set of events and receive updates in real-time as soon as the event occurs. This allows the client to receive notifications about important changes in the system without the need to constantly poll the server for updates.
|
||||
@@ -1 +1,9 @@
|
||||
# Live queries
|
||||
# Live Queries
|
||||
|
||||
In GraphQL, live queries, also known as "real-time queries" or "subscriptions to queries", is a way to push real-time updates to the client, when the data that is being queried changes on the server. It allows the client to subscribe to a specific query and receive updates in real-time as soon as the data changes.
|
||||
|
||||
With live queries, the client can subscribe to a specific query and receive updates when the data that is being queried changes on the server. The client can also specify the fields and arguments of the query, and the server will only send updates for the fields that the client has requested.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [GraphQL Live Queries](https://the-guild.dev/blog/collecting-graphql-live-query-resource-identifier-with-graphql-tools)
|
||||
@@ -1 +1,9 @@
|
||||
# Defer stream directives
|
||||
# Defer Stream Directives
|
||||
|
||||
In GraphQL, the "defer" and "stream" directives are used to control the handling of fields and their associated data. These directives allow developers to control how data is fetched and sent over the network, and can be used to optimize the performance of a GraphQL API.
|
||||
|
||||
The "defer" directive is used to delay the fetching of a field's data until the data is actually needed by the client. This can be useful for improving the performance of an API by reducing the amount of data that needs to be fetched upfront.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Defer and Stream in GraphQL](https://the-guild.dev/graphql/yoga-server/docs/features/defer-stream)
|
||||
@@ -1 +1,9 @@
|
||||
# Subscriptions
|
||||
# Subscriptions
|
||||
|
||||
In GraphQL, subscriptions are a way to push real-time updates to the client. They allow a client to subscribe to specific events or data changes on the server, and receive updates in real-time as soon as the event occurs or the data changes. Subscriptions are defined on the server and are structured similarly to queries and mutations.
|
||||
|
||||
A subscription includes a "subscription" field at the top level, followed by the fields that define the event or data change to be subscribed to. The client can initiate the subscription by sending the subscription query to the server, and the server will keep the connection open, listening for new events or data changes. Once the event occurs, or the data changes, the server will send the updated data to the client through the open connection.
|
||||
|
||||
Learn more from following links:
|
||||
|
||||
- [Subscriptions and Live Queries - Real Time with GraphQL](https://the-guild.dev/blog/subscriptions-and-live-queries-real-time-with-graphql)
|
||||
@@ -1 +1,13 @@
|
||||
# Type system
|
||||
# Type System
|
||||
|
||||
GraphQL is a strongly typed language. Type System defines various data types that can be used in a GraphQL application. The type system helps to define the schema, which is a contract between client and server. The commonly used GraphQL data types are as follows:
|
||||
|
||||
- Scalar
|
||||
- Object
|
||||
- Query
|
||||
- Mutation
|
||||
- Enum
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Type system](https://graphql.org/learn/schema/#type-system)
|
||||
@@ -1 +1,9 @@
|
||||
# Fields
|
||||
# Fields
|
||||
|
||||
In GraphQL, a field is a unit of data that can be queried or manipulated in a request. Each field has a name, a type, and an optional description. Fields are defined within an object type in a GraphQL schema.
|
||||
|
||||
Each field in a GraphQL schema can return a scalar value (such as a string or an integer) or another object, allowing for the creation of complex, nested data structures. The fields can also take arguments, which allows to filter or modify the data being returned.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [GraphQL: Types and Fields](https://graphql.org/learn/queries/#fields)
|
||||
@@ -1 +1,17 @@
|
||||
# Scalars
|
||||
# Scalars
|
||||
|
||||
Scalars are “leaf” values in GraphQL. There are several built-in scalars, and you can define custom scalars, too. (Enums are also leaf values.) The built-in scalars are:
|
||||
|
||||
- **String**, like a JSON or Ruby string
|
||||
- **Int**, like a JSON or Ruby integer
|
||||
- **Float**, like a JSON or Ruby floating point decimal
|
||||
- **Boolean**, like a JSON or Ruby boolean (true or false)
|
||||
- **ID**, which a specialized String for representing unique object identifiers
|
||||
- **ISO8601DateTime**, an ISO 8601-encoded datetime
|
||||
- **ISO8601Date**, an ISO 8601-encoded date
|
||||
- **JSON**, This returns arbitrary JSON (Ruby hashes, arrays, strings, integers, floats, booleans and nils). Take care: by using this type, you completely lose all GraphQL type safety. Consider building object types for your data instead.
|
||||
- **BigInt**, a numeric value which may exceed the size of a 32-bit integer
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Scalars in GraphQL](https://graphql.org/learn/schema/#scalar-types)
|
||||
@@ -1 +1,10 @@
|
||||
# Enums
|
||||
# Enums
|
||||
|
||||
Enums also called as enumeration types are a special kind of scalar that is restricted to a particular set of allowed values. This allows you to:
|
||||
|
||||
- Validate that any arguments of this type are one of the allowed values
|
||||
- Communicate through the type system that a field will always be one of a finite set of values
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [What are Enums?](https://graphql.org/learn/schema/#enumeration-types)
|
||||
@@ -1 +1,8 @@
|
||||
# Objects
|
||||
# Objects
|
||||
|
||||
In GraphQL, an object is a type that represents a group of fields. Objects can be used to define the structure of a query or a mutation. Each field of an object can return a scalar value (such as a string or an integer) or another object, allowing for the creation of complex, nested data structures. In a GraphQL schema, objects are defined using the **type** keyword, followed by the object's name and a set of fields in curly braces.
|
||||
|
||||
To learn more, visit the following:
|
||||
|
||||
- [Object Types and Fields](https://graphql.org/learn/schema/#object-types-and-fields)
|
||||
- [Object Types](https://graphql.org/graphql-js/object-types/)
|
||||
@@ -1 +1,9 @@
|
||||
# Lists
|
||||
# Lists
|
||||
|
||||
In GraphQL, a list is a type that represents an ordered collection of items. Lists are defined using square brackets, with the type of the items inside.
|
||||
|
||||
Lists are used to represent an array of items in a GraphQL schema, and can be used as the return type for a field in an object type. Lists can contain any type of items, including scalars and other objects, and can also be nested within other lists.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Lists](https://graphql.org/learn/schema/#lists-and-non-null)
|
||||
@@ -1 +1,9 @@
|
||||
# Interfaces
|
||||
# Interfaces
|
||||
|
||||
In GraphQL, an interface is a type that defines a set of fields that a type must implement. Interfaces are defined using the interface keyword, and can be used to define common fields for multiple types.
|
||||
|
||||
In GraphQL, lists can also be used within interfaces to define the return type for fields.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Interfaces](https://graphql.org/learn/schema/#interfaces)
|
||||
@@ -1 +1,9 @@
|
||||
# Unions
|
||||
# Unions
|
||||
|
||||
Unions are useful in cases where a field can return multiple types and you want to handle those types differently in your client. They also allow for more flexibility in how you structure your schema, as you can group types together that share common fields.
|
||||
|
||||
Unions don't allow to specify a common set of fields to be queried across multiple types, but it allows to handle multiple types differently in your client.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Union in GraphQL](https://graphql.org/learn/schema/#union-types)
|
||||
@@ -1 +1,7 @@
|
||||
# Arguments
|
||||
# Arguments
|
||||
|
||||
In GraphQL, an argument is a value that is passed to a field in a query or mutation. Arguments allow you to filter or modify the data being returned by a field. Arguments are defined within a field in a GraphQL schema, and have a name, a type, and an optional default value.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Get started with Arguments in GraphQL](https://graphql.org/learn/schema/#arguments)
|
||||
@@ -1 +1,9 @@
|
||||
# Schema
|
||||
# Schema
|
||||
|
||||
In GraphQL, a schema is a blueprint that defines the types, fields, and operations (queries and mutations) that are available to clients. The schema is the contract between the client and the server, specifying what data can be requested and how it can be modified.
|
||||
|
||||
A GraphQL schema is defined using the GraphQL Schema Definition Language (SDL), which is a human-readable syntax for defining the structure of a GraphQL API. The SDL includes keywords such as **type**, **query**, **mutation**, **field**, and **argument** to define the different components of a schema.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Schema](https://graphql.org/learn/schema/)
|
||||
@@ -1 +1,7 @@
|
||||
# Validation
|
||||
# Validation
|
||||
|
||||
Validation in GraphQL refers to the process of checking whether a GraphQL query or mutation conforms to the rules and constraints defined in the GraphQL schema. This can include checking that the query or mutation includes the required fields, that the arguments passed to a field are of the correct type, and that the values passed to fields or arguments fall within the expected range.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get Started with Validation in GraphQL](https://graphql.org/learn/validation/)
|
||||
@@ -1 +1,12 @@
|
||||
# Root fields
|
||||
# Root Fields
|
||||
|
||||
In GraphQL, the root fields are the top-level fields that are available to clients in a query or mutation. They are defined in the schema and are the entry point for client requests. The root fields represent the operations that can be performed on the data, such as querying for data or modifying data.
|
||||
|
||||
There are two types of root fields in GraphQL:
|
||||
|
||||
- **Query:** defines the fields that can be queried to retrieve data from the server.
|
||||
- **Mutation:** defines the fields that can be used to create, update, or delete data on the server.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get Started with Root Feilds](https://graphql.org/learn/execution/#root-fields-resolvers)
|
||||
@@ -1 +1,5 @@
|
||||
# Synchronous
|
||||
# Synchronous
|
||||
|
||||
In GraphQL, a resolver is a function that is responsible for fetching the data for a field in a query or mutation. Resolvers are defined in the schema and are executed by the GraphQL server when a query or mutation is received.
|
||||
|
||||
A synchronous resolver is a type of resolver that runs and completes its execution before returning any value. It directly returns the result of the computation, without waiting for any external event such as a database query or a third-party API call.
|
||||
@@ -1 +1,9 @@
|
||||
# Asynchronous
|
||||
# Asynchronous
|
||||
|
||||
In GraphQL, a resolver is a function that is responsible for fetching the data for a field in a query or mutation. Resolvers are defined in the schema and are executed by the GraphQL server when a query or mutation is received.
|
||||
|
||||
An asynchronous resolver is a type of resolver that runs, but instead of returning the final value, it returns a promise that will be resolved with the final value. This allows the resolver to wait for an external event such as a database query or a third-party API call to complete before returning the result.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get Started with Asynchronous](https://graphql.org/learn/execution/#asynchronous-resolvers)
|
||||
@@ -1 +1,9 @@
|
||||
# Scalar coercion
|
||||
# Scalar Coercion
|
||||
|
||||
In GraphQL, scalar coercion is the process of converting a value from one type to another, as it flows through the resolvers. This is needed when the input value for a field does not match the expected type, but can still be successfully converted to the correct type.
|
||||
|
||||
Scalar coercion can be implemented in the resolvers by using the **GraphQLScalarType** constructor to define a custom scalar type and providing a **coerce** function that can convert the input value to the correct type.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Scalar coercion](https://graphql.org/learn/execution/#scalar-coercion)
|
||||
@@ -1 +1,9 @@
|
||||
# Lists
|
||||
# Lists
|
||||
|
||||
In GraphQL, a list is a type that represents an ordered collection of items. Lists can be used as the return type for a field in a query or mutation, and can contain any type of items, including scalars and objects.
|
||||
|
||||
The resolver function for a list field can retrieve the data from a database or a third-party API and return it as an array.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Lists and Non-Null](https://graphql.org/learn/schema/#lists-and-non-null)
|
||||
@@ -1 +1,9 @@
|
||||
# Resolvers
|
||||
# Resolvers
|
||||
|
||||
In GraphQL, a resolver is a function that is responsible for fetching the data for a field in a query or mutation. Resolvers are defined in the schema and are executed by the GraphQL server when a query or mutation is received.
|
||||
|
||||
Each field in a GraphQL schema has a corresponding resolver function that is responsible for returning the data for that field. The resolver function can retrieve the data from a database, a third-party API, or any other source, and return it to the client.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Guide to Resolver](https://the-guild.dev/blog/better-type-safety-for-resolvers-with-graphql-codegen)
|
||||
@@ -1 +1,9 @@
|
||||
# Validation
|
||||
# Validation
|
||||
|
||||
In GraphQL, validation refers to the process of ensuring that a query or mutation adheres to the rules defined in the schema. This includes verifying that the query or mutation only accesses fields and types that are defined in the schema, and that the input values for fields are of the correct type and within the specified constraints.
|
||||
|
||||
GraphQL servers perform validation on all incoming queries and mutations to ensure that they are valid before executing them. If a query or mutation is invalid, the server will return an error, indicating which parts of the query or mutation are invalid and why.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get Started with Validation in GraphQL](https://graphql.org/learn/validation/)
|
||||
@@ -1 +1,14 @@
|
||||
# Producing the result
|
||||
# Producing The Result
|
||||
|
||||
In GraphQL, producing the result refers to the process of generating the final response to a query or mutation. This includes executing the resolvers for the selected fields, gathering the data, and formatting the response according to the requirements of the query or mutation.
|
||||
|
||||
When a client sends a query or mutation to a GraphQL server, the server performs several steps to produce the result:
|
||||
|
||||
- Parsing: The query or mutation is parsed and converted into an abstract syntax tree (AST)
|
||||
- Validation: The query or mutation is validated against the schema to ensure that it is well-formed and adheres to the schema definition.
|
||||
- Execution: The resolvers for the selected fields are executed, and the data is retrieved from the data source.
|
||||
- Formatting: The data is formatted and organized into the final response, according to the requirements of the query or mutation.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get Started with GraphQL](https://graphql.org/learn/)
|
||||
@@ -1 +1,8 @@
|
||||
# Execution
|
||||
# Execution
|
||||
|
||||
In GraphQL, execution refers to the process of executing a query or mutation and returning the result to the client. The execution process includes several steps such as parsing, validation, and data retrieval, that are performed by the GraphQL engine to produce the final response to the client.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get Started with Execution in GraphQL](https://graphql.org/learn/execution/)
|
||||
- [Intro to Execution](https://graphql.org/graphql-js/execution/)
|
||||
@@ -1 +1,13 @@
|
||||
# Caching
|
||||
# Caching
|
||||
|
||||
Caching is a technique that is used to improve the performance of a GraphQL server by reducing the number of requests that need to be made to the data source. It works by storing a copy of the data that has been requested by a client in a cache, and then returning that data from the cache instead of the data source when the same data is requested again.
|
||||
|
||||
There are several types of caching that can be used in GraphQL:
|
||||
|
||||
- Client-side caching
|
||||
- Server-side caching
|
||||
- CDN caching
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get started with Caching](https://graphql.org/learn/caching/)
|
||||
@@ -1 +1,9 @@
|
||||
# Batching
|
||||
# Batching
|
||||
|
||||
Batching in GraphQL refers to the process of sending multiple queries or mutations in a single request. This allows the client to reduce the number of round trips to the server, and can improve the performance of the application.
|
||||
|
||||
There are several ways to implement batching in GraphQL:
|
||||
|
||||
- Using a batching library: This approach involves using a library such as apollo-link-batch-http, which provides a way to batch multiple queries or mutations into a single request.
|
||||
- Using a middleware: This approach involves using a middleware such as graphql-batch, which allows you to batch multiple queries or mutations into a single request.
|
||||
- Using a serverless function: This approach involves using a serverless function such as AWS Lambda, which allows you to batch multiple queries or mutations into a single request.
|
||||
@@ -1 +1,13 @@
|
||||
# Authorization
|
||||
# Authorization
|
||||
|
||||
Authorization in GraphQL refers to the process of controlling access to specific fields, types, or operations in a GraphQL schema based on user roles or permissions. It allows you to restrict access to certain data or functionality in your application based on the user's role or permissions.
|
||||
|
||||
There are several ways to implement authorization in GraphQL:
|
||||
|
||||
- Using middleware
|
||||
- Using schema directives
|
||||
- Using a data source layer
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Get Started with Authorization](https://graphql.org/learn/authorization/)
|
||||
@@ -1 +1,9 @@
|
||||
# Graphql over http
|
||||
# GraphQL over HTTP
|
||||
|
||||
GraphQL over HTTP refers to the ability to send GraphQL queries and mutations over the HTTP protocol. This allows clients to interact with a GraphQL server using the same standard HTTP methods and headers that are used for other types of web requests.
|
||||
|
||||
The most common way to send GraphQL queries and mutations over HTTP is by using the **POST** method, where the query or mutation is sent in the request body as a JSON payload. The server will then execute the query or mutation and return the result in the response body.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Serving over HTTP](https://graphql.org/learn/serving-over-http/)
|
||||
@@ -1 +1,7 @@
|
||||
# Real time
|
||||
# Real Time
|
||||
|
||||
Real-time in GraphQL refers to the ability to receive real-time updates from a GraphQL server. This allows clients to receive updates from the server as soon as they occur, rather than having to periodically poll the server for new data.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [Get Started with Real Time with GraphQL](https://the-guild.dev/blog/subscriptions-and-live-queries-real-time-with-graphql)
|
||||
@@ -1 +1,13 @@
|
||||
# Authorization
|
||||
# Authorization
|
||||
|
||||
Authorization in GraphQL refers to the process of controlling access to specific fields, types, or operations in a GraphQL schema based on user roles or permissions. It allows you to restrict access to certain data or functionality in your application based on the user's role or permissions.
|
||||
|
||||
There are several ways to implement authorization in GraphQL:
|
||||
|
||||
- Using middleware
|
||||
- Using schema directives
|
||||
- Using a data source layer
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Get Started with Authorization](https://graphql.org/learn/authorization/)
|
||||
@@ -1 +1,7 @@
|
||||
# Graphql over websockets
|
||||
# GraphQL Over Websockets
|
||||
|
||||
The WebSocket API is an advanced technology that makes it possible to open a two-way interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [GraphQL over WebSockets](https://the-guild.dev/blog/graphql-over-websockets)
|
||||
@@ -1 +1,13 @@
|
||||
# Authorization
|
||||
# Authorization
|
||||
|
||||
Authorization in GraphQL refers to the process of controlling access to specific fields, types, or operations in a GraphQL schema based on user roles or permissions. It allows you to restrict access to certain data or functionality in your application based on the user's role or permissions.
|
||||
|
||||
There are several ways to implement authorization in GraphQL:
|
||||
|
||||
- Using middleware
|
||||
- Using schema directives
|
||||
- Using a data source layer
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [Get Started with Authorization](https://graphql.org/learn/authorization/)
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user