TinaCMS content update

Co-authored-by: Landon Maxwell <[email protected]>

content/blog/using-graphql-with-the-filesystem.mdx

@@ -1,5 +1,10 @@
 ---
 draft: true
+seo:
+  title: Using GraphQL with the Filesystem | TinaCMS Blog
+  description: >-
+    Learn how to integrate GraphQL with the filesystem in TinaCMS, enabling
+    efficient content querying and management for your file-based projects.
 title: Supercharging file-based content with GraphQL
 date: '2021-04-29T10:00:00.000Z'
 last_edited: '2021-04-29T15:31:22.309Z'
@@ -22,14 +27,14 @@ We're going to use the [Next.js blog starter](https://github.com/vercel/next.js/
 
 This app sources its content from Markdown files in a folder called `_posts`:
 
-- \_posts
-  - dynamic-routing.md
-  - hello-world.md
-  - preview\.md
-- pages
-  - index.js # lists the blog posts
-  - posts
-    - \[slug].js # dynamically shows the appropriate blog post
+* \_posts
+  * dynamic-routing.md
+  * hello-world.md
+  * preview\.md
+* pages
+  * index.js # lists the blog posts
+  * posts
+    * \[slug].js # dynamically shows the appropriate blog post
 
 On the home page we get each post from the `_posts` directory and sort them by date before showing them with our `getAllPosts` function:
 
@@ -48,7 +53,6 @@ And the result:
 
 ![](/img/blog/using-graphql-with-the-filesystem/next-demo-home_kcnyv5.png)
 
-
 > Demo: ➡️ [Start following along](https://github.com/tinacms/next-blog-starter-graphql/tree/start)
 
 #### File-based content is simple
@@ -106,7 +110,7 @@ export function getAllPosts(fields = []) {
 }
 ```
 
-Let's add a new post to test this out, this one _won't_ be featured:
+Let's add a new post to test this out, this one *won't* be featured:
 
 ```markdown
 ---
@@ -139,7 +143,7 @@ If we had been using a CMS this probably wouldn't have happened. Most of them re
 
 Let's look at the data from our new blog post again:
 
----
+***
 
 title: "Why Tina is Great"
 excerpt: "Lorem ..."
@@ -152,25 +156,25 @@ ogImage:
 url: "/assets/blog/dynamic-routing/cover.jpg"
 featured: "false"
 
----
+***
 
 Lorem ipsum dolor sit amet…
 
-The `author` content is the same over in the "Dynamic Routing and Static Generation" post. If JJ wanted to change his `picture` he will need to update it on every post he's written. Sounds like something a CMS would solve with a content _relationship_, JJ should ideally be an author who _has many_ posts. To solve this with our file-based content we could split the author data into its own file and place a reference to that author's filename in the `post` structure:
+The `author` content is the same over in the "Dynamic Routing and Static Generation" post. If JJ wanted to change his `picture` he will need to update it on every post he's written. Sounds like something a CMS would solve with a content *relationship*, JJ should ideally be an author who *has many* posts. To solve this with our file-based content we could split the author data into its own file and place a reference to that author's filename in the `post` structure:
 
 author: \_authors/jj.md
 
-But now we have to update our data-fetching logic so that whenever it comes across the `author` field in a post it knows to make an additional request for _that_ data. This is pretty cumbersome, and again — as complexity grows this type of logic quickly becomes untenable. With a CMS SDK or GraphQL API we'd be able to do this sort of thing easily, and we'd have confidence that a document can't be deleted if it's being referenced from another document.
+But now we have to update our data-fetching logic so that whenever it comes across the `author` field in a post it knows to make an additional request for *that* data. This is pretty cumbersome, and again — as complexity grows this type of logic quickly becomes untenable. With a CMS SDK or GraphQL API we'd be able to do this sort of thing easily, and we'd have confidence that a document can't be deleted if it's being referenced from another document.
 
 > Demo: [Check out the diff](https://github.com/tinacms/next-blog-starter-graphql/compare/featured-tag-mistake..split-author-data) to see how we're awkwardly making use of a separate `author` file.
 
 ### Content Management Systems: Reliable? Yes. Portable? No.
 
 Headless CMSs are a great way to maintain full control over your frontend code while offloading issues like those mentioned above to a more robust content layer. But when you hand your content over to a CMS you lose the power of Git that comes built-in with file-based content.
 
-With a CMS, when you make a change to the shape of your content you also need to _coordinate_ that new shape with your code, and you need to make sure that all of your existing content has been updated accordingly.
+With a CMS, when you make a change to the shape of your content you also need to *coordinate* that new shape with your code, and you need to make sure that all of your existing content has been updated accordingly.
 
-Most CMSs have come up with various ways to help with this: separate sandbox environments, preview APIs, and migration SDK scripts — all of which carry their own set of headaches. None of this is necessary with file-based content, _everything moves and changes together_. So what if we could bring the robust features of a headless CMS to your local filesystem? What might that look like?
+Most CMSs have come up with various ways to help with this: separate sandbox environments, preview APIs, and migration SDK scripts — all of which carry their own set of headaches. None of this is necessary with file-based content, *everything moves and changes together*. So what if we could bring the robust features of a headless CMS to your local filesystem? What might that look like?
 
 ## Meet Tina Content API