Personal site for author Christopher Zombik
The site's frontend is built with a framework called Astro. Astro is what people would typically call a Static Site Generator, which is a tool that runs once against a directory of content (think Markdown, images, CSS files, HTML, etc.) and generates a static folder of HTML content that people then see when they go to your website. If the folder has a file at the route /blog/post-name.md, the corresponding URL for that post would be chriszombik.com/blog/post-name - you can almost think of it like the user is browsing a file directory in Finder through your website. Astro does this by following a set of rules and templates that are configured by me, applying different templates to different content.
The files are laid out according to this rough structure. In general, you shouldn't need to concern yourself with any of this, but note that src/ is where the "source" files are all stored, and is where edits will most frequently be made. Anything in public/ is just copied over into the built version of your site with no changes. So, if I put a PDF in there called ChrisZombikResume.pdf and someone went to chriszombik.com/ChrisZombikResume.pdf , they'd see the PDF. Similarly, if the file were in say public/files/resume/ChrisZombik.pdf, you'd go to chriszombik.com/files/resume/ChrisZombik.pdf to access it.
componentscontains various "components", which can be thought of as snippets of HTML/content. These allow for repeatable functionality. For instance,recent-posts.astro(link here) displays a bulleted list of the most recent blog posts. It is used on the homepage, but it may be used elsewhere in the future so it makes sense to encapsulate as a componentcontentis where static text (e.g. Markdown) representing blog posts, recent works, etc. lives. Astro is aware that the text here forms "collections" which can be queried and populated into templates. There is one template for all blog posts, for instance, and the title, date, text, etc. are all slotted in. This is all populated by Tina CMS, although files can be added manually provided they conform with the Tina schema (probably you should not do this)imagescontains images used on the sitelayoutscontains theBaseLayout.astro(link here), which forms the structure of every page. You can see that it applies common elements like the<Header />and<Footer />which we want to render on every pagepagescontains each page (or route) in the site. If we madefoo.astroinside thepagesfolder, going tochriszombik.com/foowould load up whatever content we included in that file. An easy example to see is theaboutpage (link here)
The site's styling is done using Tailwind.css, which is an extremely popular framework that provides "utility classes" for CSS. You'll notice that there are no CSS files I've defined in the project. Everything comes from Tailwind, and basically each style I wish to apply gets its own class. This is a controversial approach, but for single-developer projects like this it makes a lot of sense, and Tailwind is a widely used tool with rich support that will be around for a long time.
This is handled by a free + open source tool called Tina CMS , which is partially local and partially cloud-based. The "database" for Tina is just Git/GitHub (this very repo!). The stuff in /src/content/ is what Tina is aware of, and it will see files there and files created through Tina's UI will live there.
The site's source code is stored on GitHub in this repository (aka "repo") - a repo is just like a folder of stuff that Git knows about, it is the "top level" folder of the project. The repo is public, meaning anyone can see it on my GitHub account. That said, it is protected from random people making edits/changes to it.
The GitHub repo is connected to a hosting provider called Vercel - Vercel is very much the "hot" provider for this sort of thing among frontend developers, and while they have lots of powerful enterprise features where they make money, their core features for hobbyist sites and small projects are free, which has made them so popular among developers (who then get their companies to pay for the fancy enterprise stuff). Using Vercel's tooling, it is connected to the GitHub repo. Whenever anyone makes changes to the main branch in GitHub (this is what we'd think of as the canonical/production version of the site, as opposed to any number of "feature" branches where I build new things), Vercel will be alerted to the change, pull in that new version from main, build the static folder of HTML pages, and then make it available at the domain.
The site's domain name is registered on Hover.