OntoUML/UFO Catalog

Mike's Notes

Alex told me about OntoML. Another great resource that can be used in future. Pipi uses Ontologies as constraints.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

31/12/2025

OntoUML/UFO Catalog

By: 
GitHub: 31/12/2025

OntoUML Meta Model

The FAIR Model Catalog for Ontology-Driven Conceptual Modeling Research, commonly referred to as OntoUML/UFO Catalog, is a structured and open-source catalog that contains OntoUML and UFO ontology models. It was conceived to allow collaborative work and to be easily accessible to all its users.

The goal of the OntoUML/UFO Catalog is to support empirical research in OntoUML and UFO, as well as for the general conceptual modeling area, by providing high-quality curated, structured, and machine-processable data on why, where, and how different modeling approaches are used.

The catalog offers a diverse collection of models, created by modelers with varying modeling skills, for a range of domains and different purposes. The models are available in machine-readable formats (JSON and Turtle) and are accessible via permanent identifiers.

The catalog has two data services through which we store and publish its content: this Git repository for data storage, and a FAIR Data Point (FDP) for data discovery. While we outline the FDP in this document, the focus of this documentation is on the catalog’s repository.

An overview of the catalog is provided by a dashboard at the persistent URL http://w3id.org/ontouml-models/dashboard.

Table of Contents

  • OntoUML/UFO Catalog
    • Table of Contents
    • Catalog’s Content
      • Data Organization
      • Catalog Releases
      • Data Schemas
        • OntoUML Metamodel
        • OntoUML Schema
        • Models in Linked Data
      • Metadata
      • FAIR Data Point: The Data Discovery Service
    • Catalog's Persistent URLs
    • How to Contribute
      • Contribute by Submitting an Ontology
      • Other Ways to Contribute
    • Relevant Associated Works
    • Catalog administration
    • How to Cite this Catalog
    • Acknowledgements
    • License disclaimer

Catalog’s Content

Data Organization

This repository contains OntoUML and UFO models and all their distributions, serving as our de facto data storage service. We describe below the catalog's repository structure and the files it contains:

/ontouml-models
|--- catalog.ttl
+--- /models
|     +--- /"model-directory-1"
|          |--- ontology.vpp
|          |--- ontology.json
|          |--- ontology.ttl
|          +--- /original-diagrams
|          |    |--- "diagram-1".png
|          +--- /new diagrams
|          |    |--- "diagram-1".png
|          |--- metadata.ttl
|          |--- metadata-vpp.ttl
|          |--- metadata-json.ttl
|          |--- metadata-turtle.ttl
|          |--- metadata-png-o-"diagram-1".ttl
|          |--- metadata-png-n-"diagram-1".ttl
+--- /shapes
     |--- Resource-shape.ttl
     |--- Dataset-shape.ttl
     |--- Catalog-shape.ttl
     |--- SemanticArtefact-shape.ttl
     |--- Distribution-shape.ttl

  • catalog.ttl: the Turtle file that contains all metadata about the catalog in linked data format.
  • /models: the directory containing all cataloged models.
  • /"model-directory-1": a directory containing a single model and distributions that materialize it. Most model directories' names are composed of information about the model itself, such as the name of the first author, the year of publication, or the name of the model.
  • ontology.*: the file generated by the modeling tool used to create or reproduce the model. The modeling tool in question must be able to serialize the model in JSON format in conformance with the Ontouml Schema (e.g., the Visual Paradigm UML CASE, .vpp extension, with the OntoUML Plugin for Visual Paradigm).
  • ontology.json: the JSON serialization of the model in conformance with the Ontouml Schema.
  • ontology.ttl: the Turtle serialization of the model in linked data format described with the OntoUML Vocabulary. This file is automatically generated after the JSON serialization.
  • /original-diagrams: the directory containing all diagrams of the model in PNG format. These diagrams are either (i) created from the original file generated by the modeling used, or (ii) extracted from the source where the model was published (e.g., screenshots from the original publication).
  • /new-diagrams: the directory containing all diagrams of the model in PNG format.
  • metadata.ttl: the Turtle file that contains all metadata about the model in linked data format.
  • metadata-vpp.ttl: the Turtle file that contains all metadata about the model file, the ontology.vpp distribution, in linked data format. This file is automatically generated.
  • metadata-json.ttl: the Turtle file that contains all metadata about the model's JSON serialization file, the ontology.json distribution, in linked data format. This file is automatically generated.
  • metadata-turtle.ttl: the Turtle file that contains all metadata about the model's Turtle serialization file, the ontology.ttl distribution, in linked data format. This file is automatically generated.
  • metadata-png-o-"diagram-1".ttl: a Turtle file that contains all metadata about one of the model's original diagrams, a /original-diagrams/"diagram-1".png distribution, in linked data format. A file is automatically generated for each original diagram.
  • metadata-png-n-"diagram-1".ttl: a Turtle file that contains all metadata about one of the model's new diagrams, a /new-diagrams/"diagram-1".png distribution, in linked data format. A file is automatically generated for each new diagram.
  • /shapes: the directory containing the SHACL shapes used in the validation of metadata schemas.
  • Resource-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type dcat:Resource.
  • Dataset-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type dcat:Dataset.
  • Catalog-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type dcat:Catalog.
  • SemanticArtefact-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type mod:SemanticArtefact.
  • Distribution-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type dcat:Distribution.

Catalog Releases

The catalog also offers releases comprising all its data and metadata compiled into a single Turtle file. Releases are tagged after the following nomenclature <YYYY><MM><DD> and can be accessed via the permanent identifier https://w3id.org/ontouml-models/release/<release_tag>.

Data Schemas

The cataloged OntoUML and UFO models are documented in two different formats, referred to as data schemas: the OntoUML Schema and the OntoUML Vocabulary. Both formats are build upon an implementation-independent metamodel, the OntoUML Metamodel, and are equivalent in terms of the content being represented and are automatically generated by software, but tailored for their individual use cases.

OntoUML Metamodel

The OntoUML Metamodel allows its specialization on implementation-specific metamodels to be used as manipulation and exchange of OntoUML models by software agents focused on the UML features relevant to OntoUML. It covers several features of the UML metamodel related to its class diagram language, however, simplified to meet the needs of OntoUML.

OntoUML Schema

Designed to support the development of model intelligence services in OntoUML, the Ontouml Schema specializes the OntoUML Metamodel to specify how to serialize OntoUML models in JSON. In this format, OntoUML can be easily exchanged between clients and servers communicating over HTTP, with extensive support from all major tech stacks, including easy processing within browser applications.

The JSON is a format better suited for manipulation within software code than linked data formats. It supports the exchange of models between modeling tools and the OntoUML server, providing model intelligent services (e.g., model verification and transformation).

Models in Linked Data

While JSON offers a suitable solution for exchanging and manipulating models with software, the ability to query models is extremely useful for analyzing them. This is even more pronounced in the context of a catalog of models, where the significant size of the catalog enables, for example, the generation of statistical reports and the detection of recurrent patterns. The serialization of OntoUML models in a linked data format allows us to feed them to a knowledge graph and perform complex analysis using the SPARQL querying language, all with no need for additional software.

Metadata

metadata-schema

The catalog’s schema, depicted in the image above, reuses classes and properties from the following RDF/OWL vocabularies:

  • Data Catalog Vocabulary (DCAT): The central vocabulary in our metadata schema, DCAT was “designed to facilitate interoperability between data catalogs published on the Web”.
  • Dublin Core Terms (DCT): A vocabulary that defines properties to describe basic metadata of resources on the web.
  • Friend of a Friend (FOAF): A vocabulary that offers terms to describe people, groups, companies, and other types of agents.
  • Metadata for Ontology Description and Publication (MOD): A vocabulary that defines properties to describe the metadata of ontologies and other semantic artefacts.
  • Simple Knowledge Organization System (SKOS): A vocabulary for representing and linking knowledge organization systems.
  • vCard: A vocabulary to describe contact information (e.g., email, phone number).

As we could not satisfy the metadata needs of our stakeholders using the existing vocabularies alone, we complemented them with one of our own authorship, the OntoUML/UFO Catalog Metadata Vocabulary.

The OntoUML/UFO Catalog Metadata Vocabulary was created to satisfy the metadata needs of the OntoUML/UFO Catalog, complementing the catalog's schema with properties to improve the findability and reusability of the catalog and its models. The vocabulary's content can be accessed thgrough the following links:

  • Vocabulary's complete textual specification
  • Vocabulary's GitHub repository
  • Vocabulary's formal specification in Turtle syntax

The OntoUML/UFO Catalog Metamodel Vocabulary's elements are identified below by the prefix ocmv.

FAIR Data Point: The Data Discovery Service

The OntoUML FAIR Data Point is a deployment of the FAIR Data Point (FDP) reference implementation, which is a FAIR-compliant platform designed to expose semantically rich metadata of FAIR digital objects. Deployed as a web server, the FDP provides important features to the catalog, including the generation of global unique IDs, the generation of webpages for each resource in the catalog based on their semantic annotations, and the search of resources based on textual information or user-defined SPARQL queries. The FDP is automatically synchronized with the data storage, service serving as the data discovery service for the catalog.

Catalog's Persistent URLs

  • We created persistent URLs for the following resources:
  • FDP Catalog page: https://w3id.org/ontouml-models
  • GitHub repository: https://w3id.org/ontouml-models/git
  • OntoUML vocabulary: https://w3id.org/ontouml

Catalog's releases:

  • Latest release: https://w3id.org/ontouml-models/release
  • Specific release: https://w3id.org/ontouml-models/release/<release_tag>
  • <release_tag> must be substituted by a release tag string (e.g., '20230602')

Catalog Vocabulary TTL file: https://w3id.org/ontouml-models/vocabulary

Shape TTL files:

  • https://w3id.org/ontouml-models/shape/Catalog
  • https://w3id.org/ontouml-models/shape/Dataset
  • https://w3id.org/ontouml-models/shape/Distribution
  • https://w3id.org/ontouml-models/shape/Resource
  • https://w3id.org/ontouml-models/shape/SemanticArtefact

How to Contribute

Your contribution is fundamental to the catalog's success. We highly encourage authors to submit their models and tools to this catalog. With that, you will be supporting research in (ontology-driven) conceptual modeling, ontology engineering, software design, and several others.

We greatly appreciate your contribution to this project!

Contribute by Submitting an Ontology

The easiest way to contribute to this catalog is to simply send us the following:

  1. your ontology model project;
  2. the model's metadata information; and
  3. the model's associated bibliography (when available).

If you wish to contribute to this initiative by submitting your ontology, use the catalog's contribution form.

Note that anonymous ontologies are allowed in the catalog. So, if you do not want your name to be displayed in your ontology’s metadata, you just have to inform us and we will keep the model’s authorship anonymous. It is important that, in such case, you must be the owner of the ontology’s legal rights.

If you wish to contribute by submitting someone else's ontology, please chose one entry from the "Not Started" or "Started" sheets from the List of UFO and OntoUML Ontology Models. Ontologies in the Started sheet already have files available in a branch (informed in the spreadsheet), simplifying the collaboration process.

For providing high-quality data, submissions are required to comply with the defined rules to be accepted as part of the catalog. If you have any questions about submitting new models or reusing those available in this catalog, please create an issue.

Other Ways to Contribute

If you wish to contribute to this initiative by creating and reporting an application for the catalog, please inform us through the catalog's contribution form or create an issue.

If you find any problems in the repository or have ideas for its improvement, please let us know through the catalog's contribution form or by creating an issue.

Relevant Associated Works

The list of works that use the data provided by the OntoUML/UFO Catalog to test algorithms and perform other tasks grows over time. Instead of keeping a manual list in this document, we recommend you access its Google Scholar and ResearchGate citation lists to access an updated information.

Catalog administration

The OntoUML/UFO Catalog is maintained by the Semantics, Cybersecurity & Services (SCS) Group of the University of Twente, in The Netherlands. Its principal administrators are:

  • Pedro Paulo F. Barcelos [GitHub] [LinkedIn]
  • Tiago Prince Sales [GitHub] [LinkedIn]
  • Mattia Fummagali [GitHub] [LinkedIn]
  • Claudenir M. Fonseca [GitHub] [LinkedIn]

Feel free to get in contact with the administrators using the links provided. For questions, contributions, or to report any problem, you can open an issue at this repository.

How to Cite this Catalog

Please cite the OntoUML/UFO Catalog as:

  • Prince Sales, T., Barcelos, P. P. F., Fonseca, C. M., Souza, I. V., Romanenko, E., Bernabé, C. H., Bonino da Silva Santos, L. O., Fumagalli, M., Kritz, J., Almeida, J. P. A., & Guizzardi, G. (2023). A FAIR catalog of ontology-driven conceptual models. Data & Knowledge Engineering, 147, 102210. https://doi.org/10.1016/j.datak.2023.102210. Permanent URL: https://w3id.org/ontouml-models/.

For creating citations using different formats, refer to the webpage of the paper's publisher for getting the paper's complete information.

For obtaining the paper's complete BibTeX record, we recommend downloading this information on the same webpage or accessing it on the DBLP BibTeX record.

This paper reflects the state of the catalog as of June 2022.

Acknowledgements

We would like to thank all the contributors to the OntoUML/UFO Catalog, as well as all the modelers who shared their work and allowed us to include it here.

License disclaimer

The OntoUML/UFO Catalog is licensed under the Creative Commons Attribution-ShareAlike 4.0 International Public License.

Although the OntoUML/UFO Catalog is an open project with a permissive license, special attention must be given to the following licensing clauses:

  • The OntoUML/UFO Catalog is a noncommercial work created strictly for academic research purposes.
  • This license only applies to the catalog structure itself, not to the models included in the repository.
  • Information about licensing of individual ontologies included in the catalog can be found on their related metadata.yaml file.
  • The models included in the repository were obtained directly from the authors or academic sources using open or valid licensed access.
  • This license by no means overwrites the license of the models included in the repository, which maintain their original license.
  • All catalog ontologies that are without explicit licensing information on their associated metadata.yaml file must be interpreted as being private and having a restrictive license.
  • License holders sending their models to the OntoUML/UFO Catalog expressly agree that the sent content is going to be hosted and made available for other users in the terms of this license.
  • Whoever uses the OntoUML/UFO Catalog expressly understands and agrees with its licensing information.

Ontologies are going to be immediately removed from the catalog in case of a request by the original license holders. For content removal, please create an issue or report it through the catalog's contribution form.

Introducing Code Wiki: Accelerating your code understanding

Mike's Notes

"Documentation always was a cache, a proxy for the understanding of the code. A cache that could get stale. With AI most documentation can go away. If I want to know something about the code base, I ask Claude Code - which answers in a more direct, more applicable way to my problem than any documentation. Then there is Code Wiki: “Gemini-generated documentation, always up-to-date.” Code Wiki draws some nice graphs for code too!"

- Amazing CTO

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Handbook > 

Last Updated

30/12/2025

Introducing Code Wiki: Accelerating your code understanding

By: Fergus Hurley, Pedro Rodriguez, Rafael Marques. Omar Shams.
Google for Developers: 13/11/2025

Reading existing code is the one of the biggest, most expensive bottlenecks in software development.

To address this issue and improve your productivity, we're introducing Code Wiki, a platform that maintains a continuously updated, structured wiki for code repositories.

A new way to understand code

At Google, our mission is to organize the world's information and make it universally accessible and useful. For developers, that means unlocking the vital knowledge currently buried in complex source code.

We built a system that fulfills this mission by keeping documentation alive. Instead of static files, it maintains a continuously updated, structured wiki for every repository.

  1. Automated & always up-to-date: Code Wiki scans the full codebase and regenerates the documentation after each change. The docs evolve with the code.
  2. Intelligent & context-aware: The entire, always-current wiki serves as the knowledge base for an integrated chat. You’re not talking to a generic model, but to one that knows your repo end-to-end.
  3. Integrated & actionable: Every wiki section and chat answer is hyper-linked directly to the relevant code files and definitions. Reading and exploring merge into one workflow.

The Code Wiki website

Today, we're launching the Code Wiki website in public preview, our first product built on this new system. It ingests public repositories and generates, hosts, and maintains comprehensive and interactive documentation for each one.

Instead of reading static text, you can navigate interactively, jumping directly from high-level concept explanations to the exact code files, classes, and functions they reference. If you get stuck on a complex module, you can ask the Gemini-powered chat agent that uses the always-up-to-date wiki as context to answer highly specific questions about your repository, instantly bridging the gap between learning about the code and actually exploring it. For times when text isn't enough, Code Wiki automatically generates always-current architecture, class, and sequence diagrams, ensuring you can visualize complex relationships that match the exact current state of the code.

Gemini CLI Code Wiki v2

This AI-powered, automated, intelligent, and integrated approach is the key to solving this bottleneck. New contributors can make their first commit on Day 1, while senior developers can understand new libraries in minutes, not days.

Coming soon: the Code Wiki Gemini CLI extension

While the open-source ecosystem hosts massive repositories, it’s often our own private repos that are the hardest to document effectively. Especially in companies where the original code author might not even be available anymore, understanding legacy code is a massive hurdle. We see this technology as a game-changer for these internal environments, ensuring everyone has the ability to deeply understand the code they’re working on.

We’re building a Gemini CLI extension for Code Wiki so teams can run the same system locally and securely on internal repositories. Join the waitlist for the Gemini CLI extension.

The future of development is here

Developers should spend their time building, not deciphering. The era of manual, outdated documentation and endless code-reading is over. The future of development is about instant understanding.

Workspaces for Agents

Mike's Notes

This is where I will keep detailed working notes on creating Workspaces for Agents. Eventually, these will become permanent, better-written documentation stored elsewhere. Hopefully, someone will come up with a better name than this working title.

This replaces the coverage in Industry Workspace dated 13/10/2025.

Testing

The current online mockup is version 3 and will be updated frequently.If you are helping with testing, please remember to delete your browser cache so you see the daily changes. Eventually, a live demo version will be available for field trials.

Learning

(To come)

Why

(To come)

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

2/01/2026

Workspaces for Agents

By: Mike Peters
On a Sandy Beach: 29/12/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Open-source

This open-source SaaS cloud system will be shared on GitHub and GitLab.

Dedication

This workspace is dedicated to the life and work of ??.

Person

Source:

" - Wikipedia


Change Log

Ver 3 includes config and tools.

Existing products

Features

This is a basic comparison of features in alternative software.

[TABLE]

Data Model

words

Database Entities

  • Facility
  • Party
  • etc

Standards

The workspace must comply with all applicable international standards.

  • (To come)

Data Centre Variables

Source: Krobar.ai simulation model (beta)

Node Name Type Estimates / Formula
Potential Customers Input Variable discrete_normal distribution
Server density per rack Input Variable discrete_normal distribution
Agreement conversion rate Input Variable beta distribution
Racks per agreement Input Variable discrete_normal distribution
Customer provisions virtual servers Calculation Step binomial(round(max(0,average(Market demand,Potential Customers))),average(Provider evaluation rate,Evaluation Rate,Evaluation rate))
Total revenue Calculation Step Server lease cost
Networking revenue per server Input Variable Normal(μ=200.0, σ=60.790273556231)
Evaluation Rate Input Variable beta distribution
Agreement Conversion Rate Input Variable beta distribution
Average Servers per Rack Input Variable discrete_normal distribution
Racks per Agreement Input Variable discrete_normal distribution
Monitoring & support Calculation Step Servers installed * Monitoring hours per server
Lease agreement conversion rate Input Variable beta distribution
Networking cost per server Input Variable Normal(μ=65.0, σ=21.27659574468085)
Average Racks per Agreement Input Variable discrete_normal distribution
Market demand Input Variable Normal(μ=2750.0, σ=3335.8549916376046)
Servers per Rack Input Variable discrete_normal distribution
Power costs Calculation Step Servers installed * Power cost per server + Fixed power costs
Storage revenue per server Input Variable Normal(μ=175.0, σ=75.98784194528875)
Evaluation rate Input Variable beta distribution
Servers per rack Input Variable discrete_normal distribution
Space and power provisioned Calculation Step round(max(0, Lease agreement signed) * average(Racks per agreement,Average Racks per Agreement,Racks per Agreement))
Lease agreement signed Calculation Step binomial(round(max(0, Customer evaluates providers)), average(Lease agreement conversion rate,Agreement Conversion Rate,Agreement conversion rate))
Cooling costs Calculation Step Servers installed * Cooling cost per server + Fixed cooling costs
Provider evaluation rate Input Variable beta distribution
Storage cost per server Input Variable Normal(μ=70.0, σ=30.3951367781155)
Total operating cost Calculation Step Power costs+Cooling costs+Monitoring & support+Server lease cost
Customer evaluates providers Calculation Step binomial(round(max(0, average(Market demand,Potential Customers))), average(Provider evaluation rate,Evaluation Rate,Evaluation rate))
Networking revenue Calculation Step Customer provisions virtual servers*Networking revenue per server
Server lease cost Calculation Step Servers installed * Depreciation cost per server
Networking cost Calculation Step Customer provisions virtual servers*Networking cost per server
Profit (pre-tax) Calculation Step Total revenue-Total operating cost
Storage revenue Calculation Step Customer provisions virtual servers*Storage revenue per server
Storage cost Calculation Step Customer provisions virtual servers*Storage cost per server
Fixed power costs Input Variable Normal(μ=12500.0, σ=11119.516638792014)
Fixed cooling costs Input Variable Normal(μ=9000.0, σ=8895.613311033612)
Backup revenue per server Input Variable Normal(μ=175.0, σ=185.32527731320025)
Backup cost per server Input Variable Normal(μ=27.5, σ=33.35854991637604)
DR revenue per server Input Variable Normal(μ=350.0, σ=370.6505546264005)
DR cost per server Input Variable Normal(μ=85.0, σ=96.36914420286412)
Average Power Consumption per Server Input Variable Normal(μ=0.425, σ=0.2594553882384803)
Power Cost per kWh Input Variable Normal(μ=0.13, σ=0.07413011092528009)
Hours per Period Input Variable discrete_normal distribution
Average Cooling Cost per Server per Period Input Variable Normal(μ=25.0, σ=22.239033277584028)
Server Purchase Cost Input Variable Normal(μ=5000.0, σ=4447.806655516806)
Server Useful Life (Periods) Input Variable discrete_normal distribution
Monitoring Hours per Server per Period Input Variable Normal(μ=2.25, σ=2.5945538823848033)
Renewal Rate Input Variable beta distribution
Lease cost per server per period Input Variable Normal(μ=1250.0, σ=1111.9516638792015)
Depreciation cost per server Input Variable Normal(μ=1100.0, σ=1334.3419966550418)
Monitoring hours per server Input Variable Normal(μ=55.0, σ=66.71709983275208)
Renewal rate Input Variable beta distribution
Power cost per server Input Variable Normal(μ=1100.0, σ=1334.3419966550418)
Cooling cost per server Input Variable Normal(μ=550.0, σ=667.1709983275209)
Servers installed Input Variable discrete_normal distribution
Depreciation Cost per Server Input Variable Normal(μ=1900.0, σ=1630.862440356162)
Monitoring Hours per Server Input Variable Normal(μ=55.0, σ=66.71709983275208)
Power Cost per Server Input Variable Normal(μ=800.0, σ=593.0408874022407)
Fixed Power Costs Input Variable Normal(μ=30000.0, σ=29652.04437011204)
Cooling Cost per Server Input Variable Normal(μ=400.0, σ=296.52044370112037)
Fixed Cooling Costs Input Variable Normal(μ=17500.0, σ=18532.527731320024)
Backup revenue Calculation Step Customer provisions virtual servers*Backup revenue per server
Backup cost Calculation Step Customer provisions virtual servers*Backup cost per server
Disaster recovery revenue Calculation Step Customer provisions virtual servers*DR revenue per server
Disaster recovery cost Calculation Step Customer provisions virtual servers*DR cost per server
Review and renew/cancel Calculation Step binomial(round(max(0, Lease agreement signed)), Renewal rate)

Simulation notes


Support

(To come)

Workspace navigation menu

This default outline needs significant work. The outline can be easily customised by future users via drag-and-drop and tick boxes to toggle features on and off.

  • Agent Account
    • Applications
      • Agent
        • ajx
        • alg
        • api
        • apl
        • aui
        • bor
        • brs
        • cde
        • cfg
        • cgi
        • cmd
        • cms
        • cnd
        • cnf
        • cny
        • cor
        • cpt
        • cpx
        • css
        • cte
        • ctx
        • cui
        • dao
        • dmn
        • dob
        • doc
        • dom
        • dpl
        • dsg
        • dta
        • dvp
        • eml
        • eng
        • fac
        • ffg
        • fil
        • fld
        • fnt
        • ftp
        • fui
        • int
        • iot
        • ips
        • kwd
        • lng
        • lnk
        • lob
        • loc
        • log
        • lop
        • lui
        • mim
        • mle
        • mod
        • mpg
        • msg
        • mta
        • mtr
        • nde
        • nsp
        • nte
        • obj
        • ont
        • oop
        • par
        • pge
        • phl
        • pkg
        • pln
        • plt
        • plu
        • plw
        • prm
        • pub
        • pui
        • rbn
        • rgn
        • rle
        • rls
        • rnd
        • scl
        • scr
        • sgp
        • spt
        • ssn
        • sta
        • sys
        • tem
        • tra
        • trn
        • tsk
        • udt
        • usa
        • usi
        • usp
        • usr
        • var
        • vct
        • ver
        • vfy
        • wai
        • wbs
        • wfl
        • wki
        • wsp
      • As a Platform
        • Cloud Platform
          • Alibaba Cloud
          • AWS
          • Azure
          • Cloudflare
          • Container Hosting Service
          • Couchbase
          • DigitalOcean
          • Google Cloud
          • Hetzner Cloud
          • IBM Cloud
          • JFrog
          • Linode
          • Netlify
          • OpenShift
          • Oracle Cloud
          • OVHcloud
          • Render
          • Salesforce
          • Tencent Cloud
          • Vercel
          • Wasabi
          • Zeabur
      • Data Centre (v2)
        • Cooling
        • Fire
        • Power
          • Supply
          • UPS
        • Security
      • Mission Control
        • Status
    • Customer (v2)
      • Bookmarks
        • (To come)
      • Support
        • Contact
        • Forum
        • Live Chat
        • Office Hours
        • Requests
        • Tickets
      • (To come)
        • Feature Vote
        • Feedback
        • Surveys
      • Learning
        • Explanation
        • How to Guide
        • Reference
        • Tutorial
    • Settings (v3)
      • Account
      • Billing
      • Deployments
        • Workspaces
          • Modules
          • Plugins
          • Templates
            • Mission Control
            • Researcher
            • Librarian
            • Training
          • Users

21 Frontend System Design Concepts for Software Engineers

Mike's Notes

An excellent list of frontend system options.

Pipi generates a static frontend as a thin wrapper.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > System Design
  • Home > Handbook > 

Last Updated

28/12/2025

21 Frontend System Design Concepts for Software Engineers

By: Neo Kim & Shefali Jangid
System Design: 11/11/2025

Neo: I Teach You System Design

Shefali: I write about CSS, JavaScript, web dev resources, and solo projects.

If you’re coming from the backend, you probably think the frontend is just “HTML, CSS, maybe some JavaScript.” But honestly? Modern frontend engineering has grown into something much closer to backend system design.

Just like your APIs need to be fast, scalable, and reliable, frontend apps also have to handle millions of users, load content quickly, and stay observable and secure.

This newsletter is a quick introduction to frontend system design.

We’ll take concepts you already know from the backend, like caching, deployment pipelines, observability, and security, and see how they apply in the browser.

By the end, you’ll see that the frontend isn’t just about buttons and forms. It’s about building systems that run right in the user’s browser.

Onward.

I want to introduce Shefali Jangid as a guest author.

She’s a web developer, technical writer, and content creator with a love for frontend architecture and building things that scale.

Check out her work and socials:

  • Shefali.dev
  • GitHub
  • Twitter

You’ll often find her writing about web development, sharing UI tips, and building tools that make developers’ lives easier.

Rendering & Delivery Models

One of the first things to understand is how webpages reach your users.

The way you build and load them affects how fast, reliable, and smooth your site feels. You can pre-build pages, render them on the server, build them in the browser, or mix these approaches.

Building web pages works much like a server handles API responses. The trade-offs change depending on when and where the HTML gets generated.

Let’s start with pre-built pages and move to fully dynamic ones. We’ll see how each affects speed, scalability, and content freshness.

1 Static Site Generation (SSG)

Before SSG, websites worked in two fundamental ways. The server either built the page for every request, or the browser built it on the client side. That means:

  • Every request needed work to generate the page.
  • Pages could get slow if many people visit at once.
  • Caching was tricky, so scaling was hard.

SSG solves this by pre-building the HTML when you deploy your site. The system can fetch data during the build process, even for pages with dynamic content, which means all content is baked into static HTML files before any user visits them.

During the build process, the framework executes data-fetching code, queries your database, and generates complete HTML files for each route. The framework then uploads them to your CDN or hosting provider.

When users request a page, they receive a fully formed HTML document immediately, without waiting for server-side processing or client-side data fetching.

This makes SSG super fast for users because there’s no rendering delay. The trade-off is that if your content changes, you’ll need to rebuild and redeploy to update the static files, which is why SSG works best for content that doesn’t change frequently.

It’s like preparing API responses in advance; the hard work is done before anyone asks.

Why it matters:

  • Pages load super fast.
  • Easy to handle millions of users.
  • SEO is better because pages get fully rendered from the start.

Use case:

Documentation sites, marketing landing pages, or personal blogs where content updates happen through deployments, not user actions.

2 Incremental Static Regeneration (ISR)

Static Site Generation (SSG) is fast, but what if your content changes frequently? Rebuilding the whole site every time would be a pain.

That’s where Incremental Static Regeneration (ISR) comes in.

Pages are still pre-built, but they can update automatically without a full redeploy.

You just set a revalidation time; after that period, the next visitor triggers a background rebuild of that specific page on the server, not a full deployment. The old version loads instantly, so users don’t wait. After regeneration, the new version replaces the cached one. This occurs per page, not site-wide, allowing you to set different revalidation intervals for individual pages.

It’s like cached API responses with an expiry timer; users might glimpse an older version until it’s refreshed, but the update happens quietly behind the scenes.

Why it matters:

  • Just as fast as SSG, but the content stays fresh.
  • Perfect for dynamic websites like blogs or e-commerce sites.
  • Works with CDNs, so updates happen without downtime.

Use case:

E-commerce product pages where most content (e.g., descriptions or images) is static, but some parts, like prices or stock info, update occasionally.

ISR keeps the page fresh without full redeploys, while real-time data, such as live prices, can come from APIs.

3 Server-Side Rendering (SSR)

Server-Side Rendering (SSR) works the other way around: the server builds the page for each request. It fetches the data, generates the HTML, and sends it to the user.

Unlike Static Site Generation (SSG), which is great for mostly static pages, SSR is useful when content needs to stay fresh or personalised. For example, dashboards, user profiles, or live feeds. Because the system generates pages in real time, they always display the latest data instead of relying on pre-built files.

Think of it like a regular API endpoint; everything gets computed on demand.

Why it matters:

  • Keeps content fresh and easy to personalise.
  • Perfect for pages that need real-time data or personalised content.
Note: Under heavy traffic, SSR can slow down because it builds each page on demand, but caching can help balance load and speed.

Use case:

Social media feeds, admin dashboards, or user-specific pages where content varies by session.

4 Client-Side Rendering (CSR)

CSR means the browser does most of the work instead of the server. The server sends only a basic HTML page and some JavaScript. The browser then loads the data and builds the page on the fly.

This approach is useful when you need rich interactivity, real-time updates, or pages that change often based on user actions - things that static or server-rendered pages can’t handle easily.

Think of it like sending raw JSON and letting the client put it together.

Note: The first page load can be slower because the browser needs to download and run JavaScript before showing the content. Since pages get built in the browser, search engines might not see them immediately, so you might need extra setup like pre-rendering or server-side rendering for better SEO.

Why it matters:

  • Reduces pressure on the server.
  • Makes the app more interactive and responsive.
  • Works best for apps people use for a long time, like dashboards or editors.

Use case:

Complex apps like Figma, Notion, or Google Docs, where the app is highly interactive and users stay on the page for extended sessions.

5 Hybrid Rendering

Sometimes, one approach just isn’t enough.

Different parts of your app might have different needs. For example, some pages stay mostly the same, while others need fresh or personalised data. That’s where hybrid rendering comes in.

It mixes different strategies:

  • Server-side rendering (SSR) for pages that need live or personalised content,
  • Static site generation (SSG) for pages that rarely change,
  • And client-side rendering (CSR) for sections with lots of interactivity.

Think of it like combining pre-computed API responses with on-demand endpoints - all in the same system.

Why it matters:

  • You get the best of everything: speed, fresh content, and interactivity.
  • Allows you to choose the right approach for each page or component.
  • Reduces overloading the server while keeping content dynamic where needed.

Use case:

Large-scale apps like e-commerce platforms often combine different rendering strategies:

  • The homepage and category pages use static generation for speed.
  • Product pages use incremental static regeneration to keep content fresh.
  • User account pages use server-side rendering for personalised data.
  • The shopping cart uses client-side rendering for real-time updates without page reloads.

6 Content Delivery Networks (CDNs) & Edge Delivery

No matter which rendering method you choose, serving content efficiently is super important. CDNs keep copies of your static files on servers worldwide. This lets users download them from a nearby location instead of your main server.

This is especially useful for global audiences. For example, when someone in India visits a site hosted in the US, the CDN delivers the content from a local server, making it load much faster.

Edge rendering takes this idea a step further. Instead of just serving static files, it can actually run code or build pages at the edge, closer to the user, which reduces latency even more.

Think of it like having caches and compute nodes near your users, so requests go to a nearby server instead of your main database.

Why it matters:

  • Faster load times everywhere.
  • Easy to scale to millions of users.
  • Works perfectly with SSG, ISR, SSR, or hybrid setups.

Use case:

Any globally distributed application. Media sites like The New York Times use CDNs to serve articles instantly worldwide.

Performance & Optimisation

Now that you understand how your pages get rendered, the next obvious question is, “How quickly do they actually load?”

Even the most beautiful app can be frustrating if it takes too long to open or lags while being used. In frontend system design, speed really matters.

Let’s dive in!

7 Web Performance Metrics

To really understand your app’s speed, there are a few key metrics you should watch closely:

  • TTFB (Time to First Byte): The time it takes for your browser to get the first piece of data back from the server or CDN after making a request.
  • FCP (First Contentful Paint): The moment when something first appears on the screen, like text, an image, or a button, so the user knows the page is loading.
  • LCP (Largest Contentful Paint): The time it takes for the main part of the page, like a large image or headline, to fully appear on the screen.
  • CLS (Cumulative Layout Shift): It measures how much the page layout jumps around while loading, like when text or buttons suddenly shift because images or ads are still loading.

These are basically the frontend versions of response time, throughput, and latency in backend systems. It’s important to keep a close eye on them; users can notice even minor delays of a few hundred milliseconds.

Why it matters:

  • You can spot slow pages before users even notice.
  • Improves engagement and reduces bounce rates.
  • Helps guide your optimisations for a smoother experience.

Use case:

E-commerce sites must optimise for LCP (product images) and CLS (avoid layout shifts during checkout). News sites focus on FCP to show headlines quickly.

8 Lazy Loading

Of course, fast pages aren’t just about metrics; they’re also about smart resource management.

Not everything on a page needs to load immediately. Lazy loading means loading heavy assets, like images, videos, or big components, only when they’re actually needed.

This works by using techniques like the Intersection Observer API or conditional imports, which tell the browser to fetch those resources only when they come into view or are triggered by user interaction.

It’s like fetching extra data from an API only when the user asks for it.

Why it matters:

  • Cuts down the initial load time.
  • Makes the pages feel faster and smoother.
  • Saves bandwidth for users who don’t need everything immediately.

Use case:

Image-heavy sites like Pinterest or Instagram use lazy loading extensively; images below the fold don’t load until you scroll.

9 Service Workers & Caching

Once you’ve optimised loading, you can make your app faster and more reliable using service workers and caching.

Service workers are background scripts that run in a separate thread from your main web page. They can intercept network requests and cache important files or data, helping your app load faster and even work offline.

Think of them as a smart middle layer between the browser and the network; if something is already cached, it’s served instantly instead of being fetched again.

Why it matters:

  • Speeds up repeat visits.
  • Reduces the load on servers.
  • Keeps apps usable even with poor or no internet connection.

Use case:

Progressive Web Apps like Twitter Lite or Starbucks PWA, which cache core UI and recent content, so users can browse even on unstable mobile networks.

Data & State Management

Once your UI loads quickly, the next step is to think about the data behind it.

In real apps, this data (also called state) can come from different places:

  • Some live inside a single component (a reusable piece of the UI, like a button),
  • Some are shared across the app,
  • And others come from APIs.

How you manage this state can make or break your app’s speed, reliability, and scalability.

10 State Management (Local, Global, Server Cache)

  • Local state: data that lives inside a single component, used for things like toggles, forms, or small interactions. It’s simple to manage and doesn’t add much complexity.
  • Global state: data that’s shared across multiple components or pages, like user info or theme settings. Tools like Redux, Zustand, or React Context help manage it.
  • Server cache: stores frequently used API data on the client so the app doesn’t have to fetch it again and again, making it faster and reducing server load.

Think of it like database caching: by deciding where data should live, you can make your app more responsive, reliable, and easier to scale.

Why it matters:

  • Keeps your app responsive.
  • Reduces unnecessary API calls.
  • Makes scaling smoother as your app grows.

Use case:

Local state for a modal’s open/closed status. Global state for theme preference (dark mode) that affects every component. Server-side cache for user profile data displayed by multiple components.

11 API Caching with Expiration

Caching doesn’t stop at the component level. You can store API responses in memory, IndexedDB (a browser database for larger data), or localStorage (for smaller key-value data), and set expiration rules to make sure data stays fresh.

It’s like having a Redis cache server, but right in the browser instead of on your server.

Why it matters:

  • Keeps data up-to-date for users.
  • Reduces repeated server requests.
  • Makes your app feel faster.

Use case:

A news app might cache articles for a few minutes so users can read offline, while comments refresh more often to stay up to date. Similarly, a SaaS dashboard could cache chart data while the user is on the page, then refresh it when they come back later.

12 GraphQL vs REST (Reducing Over/Under-Fetching)

How you fetch data also affects performance.

  • REST: Can sometimes send too much data or not enough, making your app fetch extra information or require additional requests.
  • GraphQL: A query language for APIs that lets the client ask for exactly the data it needs, avoiding extra or missing information. This avoids over-fetching or under-fetching data and helps reduce unnecessary requests.

It’s like how you optimise database queries on the backend to make them faster and use less bandwidth, but this happens on the frontend.

GraphQL sits between the client and the server as one endpoint. The client asks for exactly the data it needs, and the server’s GraphQL layer collects that data from databases or other APIs, then sends back a clean, organised response.

This way, you make one flexible request instead of several REST calls, making it faster and more data-efficient.

Why it matters:

  • Saves bandwidth, especially on mobile networks.
  • Reduces unnecessary requests.
  • Simplifies client-side data handling.

Use case:

GraphQL works best for complex apps that need data from many places at once, like GitHub. One GraphQL query can get a pull request, comments, and author info in a single request instead of several REST calls. While REST is simpler and great for apps with stable data, like blogs or public APIs that rely on caching.

13 Pagination Strategies (Cursor vs Offset)

Loading large lists or tables all at once can be heavy. Pagination helps break the data into manageable chunks.

  • Offset pagination: Uses page numbers or record counts (like ?page=2 or ?offset=20) to fetch data. It’s simple and works well for lists that don’t change often. But the list order shifts if new items are added or old ones are removed. This can make the same offset return different items, leading to duplicates or missing entries.
  • Cursor pagination: Uses a pointer to mark where the last item ended, so the next request starts right after it. It’s more reliable for live or frequently updated data (social feeds or chat messages) because it keeps track of the exact position in the dataset. That means even if new items are added or removed while you’re scrolling, you won’t see duplicates or miss entries.

Why it matters:

  • Handles large datasets efficiently.
  • Prevents slowdowns and performance bottlenecks.
  • Keeps dynamic lists reliable and consistent.

Use case:

  • Offset pagination: best for data tables with stable data and clear page numbers, such as admin panels or product catalogs.
  • Cursor pagination: ideal for infinite scroll feeds like social media timelines, notification lists, or any real-time list where items are frequently added or removed.

14 Real-Time Data & Networking (WebSockets, SSE, Polling)

Finally, some apps need live updates, like chat apps, dashboards, or notifications. How you handle real-time data matters.

  • WebSockets: Let the client and server send messages to each other in real time, both ways, without constantly asking for updates.
  • Server-Sent Events (SSE): The server can push updates to the client in real time, but communication only goes one way, from server to client.
  • Polling: The client regularly asks the server for updates. It’s simple to set up, but it can put more load on the server.

It’s like building event-driven systems on the backend, but here it happens in the browser.

Why it matters:

  • Supports live dashboards, chat, and notifications.
  • Improves interactivity and user engagement.
  • Allows you to choose the right strategy for your app’s needs.

Use case:

  • WebSockets: chat apps (Slack), multiplayer games, collaborative editing (Google Docs).
  • SSE: live notifications, stock tickers, server logs streaming to a dashboard.
  • Polling: simple use cases like checking for new emails or status updates.

Architecture & Scalability

As your app grows, managing complexity becomes just as important as writing features. Frontend architecture isn’t just about code; it’s about building systems that are maintainable, scalable, and predictable.

15 Micro Frontends

When multiple teams work on the same app, things can get messy fast.

Micro frontends let each team build and deploy their part of the app separately. For example, one team handles the dashboard while another builds the settings page. Technically, the app is divided into smaller frontend projects that are combined at runtime to work as one seamless app.

A module federation feature (for example, in tools like Webpack) lets these separate projects share code (like components or utilities) directly in the browser, without rebuilding or duplicating code across projects.

Why it matters:

  • Teams can develop features faster and in parallel.
  • Reduces duplicated code across bundles.
  • Supports independent deployment cycles, so updates don’t block each other.

Use case:

Large enterprises with multiple teams working on different product areas. For example, big companies like Zalando, IKEA, DAZN, and Spotify use micro-frontends so each team can build and release their part of the app on their own.

16 Component-Based Architecture & Design Systems

Components are the building blocks of your app. A design system ensures these components stay consistent and reusable across teams and projects.

It’s like having reusable backend modules or libraries, but for your UI.

Why it matters:

  • Makes the UI predictable and easier to maintain.
  • Encourages code reuse across pages and projects.
  • Helps teams scale efficiently without creating chaos.

Use case:

  • Used by companies with many products or teams to keep design consistent, like Shopify’s Polaris or IBM’s Carbon, which are open-source design systems containing ready-to-use UI components, styles, and guidelines.
  • Even small startups benefit: a shared set of 10–20 components (like buttons and modals) helps teams build faster and keep the UI consistent.

17 Build & Deployment Pipelines (CI/CD for Frontend)

Frontend apps also benefit from CI/CD (Continuous Integration and Continuous Deployment) pipelines, just like backend services. These pipelines automatically handle steps like building the app, running tests, and deploying updates.

In simple terms, every time you push code, CI/CD tools check that nothing breaks and then safely release the latest version, making deployments faster, more reliable, and less manual.

Why it matters:

  • Minimises human errors during deployment.
  • Enables fast, reliable releases.
  • Makes scaling and frequent updates much smoother.

Use case:

Works for any app with regular updates, from small teams auto-deploying to Vercel to big companies like Netflix releasing thousands of times a day. It keeps updates fast, safe, and reliable.

User Experience & Reliability

Your users don’t care about your architectures or caching strategies; they just want the app to be fast, reliable, and easy to use.

18 Accessibility (a11y) & Mobile-First Design

Accessibility and mobile-first design aren’t just design principles; they’re system-level considerations. Accessibility ensures your app’s UI and code structure work for everyone, including people using assistive technologies.

Mobile-first design forces you to build efficient layouts, load lighter assets, and prioritize key features, all of which influence performance, scalability, and overall frontend architecture.

Why it matters:

  • Reaches more users.
  • Makes your app easier and more pleasant to use.
  • Ensures a consistent experience across devices.

Use case:

Government sites (accessibility is legally required in many countries), e-commerce, and content platforms. Mobile-first is essential for apps in developing markets where mobile is the main or only device.

19 Progressive Web Apps (PWAs) & Offline-First

Progressive Web Apps (PWAs) are web apps that behave like native apps. They can work offline, send notifications, and even be installed on a device.

They use a few key technologies:

  • Service workers run in the background to cache important files like HTML, CSS, and API responses.
  • A web app manifest defines how the app looks and behaves when installed.
  • And HTTPS keeps everything secure.

Together, these make the app fast, reliable, and installable.

Why it matters:

  • Users can access your app anywhere.
  • Reduces load on servers.
  • Improves reliability and user trust.

Use case:

Apps where offline access is valuable: Twitter Lite, Starbucks PWA, field service apps, and news apps.

20 Security Basics (XSS, CSRF, CSP, Authentication)

Speed means nothing without security. Frontend isn’t just about the UI; it’s also the first line of defence for your app.

  • XSS (Cross-Site Scripting): Stop attackers from injecting malicious scripts into your app.
  • CSRF (Cross-Site Request Forgery): Protect your forms and actions that change data from being triggered by attackers without the user’s consent.
  • CSP (Content Security Policy): A rule set that helps prevent malicious scripts from running in your app.
  • Authentication: Make sure user tokens and sessions are stored and handled securely in the browser.

Why it matters:

  • Protects your users and their data.
  • Prevents common attacks before they reach the backend.
  • Builds trust and helps with compliance.

Use case:

Any app handling sensitive data. Financial apps need strict CSP and token handling. Social platforms must prevent XSS to avoid account takeovers. E-commerce sites need CSRF protection on checkout to prevent unauthorised purchases.

21 Observability & Error Monitoring (Client-Side)

Even if everything works well, things can still break in production. That’s why observability is important.

Frontend errors are just like 500 errors in your backend; they happen. Monitoring tools like Sentry or LogRocket help you track:

  • JS exceptions: errors that happen in your JavaScript code while the app is running.
  • Performance bottlenecks: parts of your app that slow it down or make it lag.
  • User interactions leading to errors: actions by users that trigger bugs or crashes in your app.

These tools add a small script to your app. When something breaks, it collects information like the error message, what the user was doing, and browser details. Then it sends that data to the tool’s server, where you can see and fix the issue from your dashboard.

Why it matters:

  • Detects and resolves issues faster.
  • Keeps your app stable and performant.
  • Improves the overall user experience and trust.

Use case:

Used in production apps with real users. SaaS teams track errors right after deployment, e-commerce sites watch checkout issues, and session replay tools help support teams see what confused users without extra bug reports.

Conclusion

Frontend system design is basically backend system design, just happening in the user’s browser.

Every choice you make, like rendering method, caching strategy, state management, architecture, and security, affects speed, scalability, and reliability.

So next time you’re building a frontend, ask yourself:

  • Where should computation happen? On the server, in the client’s browser, or at the edge?
  • When does the data need to be up-to-date? Prebuilt, cached, or real-time?
  • How can we keep the app fast and reliable? Lazy loading, smart caching, or micro frontends?
  • How do we scale this? Can the architecture handle 10x traffic? 100x?
  • How do we maintain this? Will new developers understand the architecture? Can teams work independently?

Think of your frontend as a distributed system. Treat it that way, and your users will get an app that’s fast, smooth, and seamless, exactly what they expect.

👋 I’d like to thank Shefali for writing this newsletter!

Plus, don’t forget to check out her work and socials:

  • Shefali.dev
  • GitHub
  • Twitter

You’ll often find her writing about web development, sharing UI tips, and building tools that make developers’ lives easier.