fontseca.dev

---

Welcome to the source code of my personal website, fontseca.dev. This site is a dedicated portal where I share my work, experience, ideas, interests, and thoughts. The project represents the culmination of four years of strong desired to have a place of my own, and one year of devoted work to make it possible. The initial design was just a single info page about myself, but it eventually turned into a more complete and complex platform.

One of my favorite sections in the site is the archive. Before starting the web, I faced a dilemma: use an existing platform like Hugo, or create a blog manager myself from scratch. After some thinking, I chose to build my own blog manager—what I decided to call the archive. Here, I address subjects I find interesting and worth sharing. As other sections of the site, the archive is fully managed through an RPC-like API that powers the content, and constitutes one of the core parts of my website, alongside my playground. In this archive, I discuss certain topics that interest me.

As a back-end engineer, I encountered a problem most of us have suffered when we want to have a website to present our work. When we work on APIs, we often want to showcase some of our labor. We could talk about it in a detailed article, but most of the time we want to play around with the product. That is why I created the second cornerstone of my website—what I call the playground; which is, by the way, open source and available for integration into other projects.

Table of Contents

• Table of Contents
• The Archive
  • Articles Lifecycle
• The Playground
• API Reference
  • Errors
    • internal
    • missing_argument
    • unparseable_value
    • not_found
    • out_of_range
    • unmet_validation
    • duplicate_key
    • action_already_completed
    • action_refused
  • Me
    • me.get
    • me.set
    • me.set_photo
    • me.set_resume
    • me.set_hireable
  • Experience
    • me.experience.list
    • me.experience.hidden.list

The Archive

The archive is a blog managed entirely through an API, featuring various entities like:

• topics,
• tags,
• article drafts,
• published articles,
• and article patches.

Topics represent the main themes I write about, offering an organized way to group content by themes. On the other hand, tags are keywords or labels to help categorize and locate articles related to similar discussions.

Articles are finalized pieces of writing on a particular topic, with one or more tags that are inherent to the discussion of the articles and enhance their discoverability. Each article begins as an **article draft, or just draft **, which is a rough and initial version of the article that outlines its main facts and points. Drafts are improved by making revisions, and can be shared for feedback until they are ready for publishing as complete articles.

Once published, articles may need to be improved or amended; this is done through article patches, or just patches, which are temporary entities pointing to the original article, where updates and enhancements are stored. Patches allow continuous improvement without taking the article offline and can also be shared to get feedback. When the patch is coherent and complete, it can be merged into the article, making the changes live.

Each article can have only one active patch, both referenced by the same unique identifier. However, the patch is a completely different object that can be handled separately and privately. Since both entities share the same identifier, it becomes easy to access any patch that an article currently has.

Articles Lifecycle

Following is the workflow diagram of the articles lifecycle; as you can see, articles start as drafts, then they become real and published articles, once in that state, they can undergo updates or improvements through patches.

The Playground

Challenging in the beginning, this is the section that I find the most attractive on my website, not only because of its UI but also because of its functionality. Before I started this module, I didn't know how to integrate it into my website because I wanted this project to be separate and work as a plug-in to my website. I had two essential ideas: making it run in a different process using some sort of socket-based communication, or making it part of the same codebase as my website. However, the solution was simpler and intuitive.

The playground is a web-based HTTP client to test APIs I've worked on or any other third-party public API. The very basic idea of creating this section was to have a dedicated space to showcase my work as a back-end engineer, since most of the time we find ourselves working far from the unwary visitor, making it hard sometimes to actually show what we do. Another strong reason I had to build it was to experience the challenges the project presented.

For more details about the playground and