Showing posts with label URL. Show all posts
Showing posts with label URL. Show all posts

Your URL Is Your State

Mike's Notes

There were dozens of complex, hard problems that had to be solved before cracking the emergent problem of massive IT system failures. This took years. They often had to be solved in parallel because of their interwoven effects. URL patterns were one of them.

I have been thinking about URL structure patterns for a while. I finally solved this problem for Pipi 9 back in October 2025. It was one of the last problems to solve before it could successfully build the UI of enterprise-scale workspaces. The UI turned out to be a thin wrapper, which was a complete surprise.

The recent successful stress-test trial involved 15K web pages and directories in a rapidly built (days) web UI, and the URL pattern was perfect. It will now become possible for Pipi 9 to automatically generate much larger custom workspaces without error. and on demand.

This is a great article from Ahmad Alfy in Egypt. He is totally correct in what he writes, and he helped me see the problem and patterns much more clearly.

Thank you, Ahmad. I look forward to meeting you. Maybe you could be part of the team. 😊

Resources

References

  • Reference

Repository

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

Last Updated

03/12/2025

Your URL Is Your State

By: Ahmad Alfy
AlfyBlog: 31/10/2025

Blog about front-end development and the web.

Couple of weeks ago when I was publishing The Hidden Cost of URL Design I needed to add SQL syntax highlighting. I headed to PrismJS website trying to remember if it should be added as a plugin or what. I was overwhelmed with the amount of options in the download page so I headed back to my code. I checked the file for PrismJS and at the top of the file, I found a comment containing a URL:

/* https://prismjs.com/download.html#themes=prism&languages=markup+css+clike+javascript+bash+css-extras+markdown+scss+sql&plugins=line-highlight+line-numbers+autolinker */

I had completely forgotten about this. I clicked the URL, and it was the PrismJS download page with every checkbox, dropdown, and option pre-selected to match my exact configuration. Themes chosen. Languages selected. Plugins enabled. Everything, perfectly reconstructed from that single URL.

It was one of those moments where something you once knew suddenly clicks again with fresh significance. Here was a URL doing far more than just pointing to a page. It was storing state, encoding intent, and making my entire setup shareable and recoverable. No database. No cookies. No localStorage. Just a URL.

This got me thinking: how often do we, as frontend engineers, overlook the URL as a state management tool? We reach for all sorts of abstractions to manage state such as global stores, contexts, and caches while ignoring one of the web’s most elegant and oldest features: the humble URL.

In my previous article, I wrote about the hidden costs of bad URL design. Today, I want to flip that perspective and talk about the immense value of good URL design. Specifically, how URLs can be treated as first-class state containers in modern web applications.

The Overlooked Power of URLs

Scott Hanselman famously said “URLs are UI” and he’s absolutely right. URLs aren’t just technical addresses that browsers use to fetch resources. They’re interfaces. They’re part of the user experience.

But URLs are more than UI. They’re state containers. Every time you craft a URL, you’re making decisions about what information to preserve, what to make shareable, and what to make bookmarkable.

Think about what URLs give us for free:

  • Shareability: Send someone a link, and they see exactly what you see
  • Bookmarkability: Save a URL, and you’ve saved a moment in time
  • Browser history: The back button just works
  • Deep linking: Jump directly into a specific application state

URLs make web applications resilient and predictable. They’re the web’s original state management solution, and they’ve been working reliably since 1991. The question isn’t whether URLs can store state. It’s whether we’re using them to their full potential.

Before we dive into examples, let’s break down how URLs encode state. Here’s a typical stateful URL:

Anatomy of a URL
Source: What is a URL - MDN Web Docs

For many years, these were considered the only components of a URL. That changed with the introduction of Text Fragments, a feature that allows linking directly to a specific piece of text within a page. You can read more about it in my article Smarter than ‘Ctrl+F’: Linking Directly to Web Page Content.

Different parts of the URL encode different types of state:

  1. Path Segments (/path/to/myfile.html). Best used for hierarchical resource navigation:
    • /users/123/posts - User 123’s posts
    • /docs/api/authentication - Documentation structure
    • /dashboard/analytics - Application sections
  2. Query Parameters (?key1=value1&key2=value2). Perfect for filters, options, and configuration:
    • ?theme=dark&lang=en - UI preferences
    • ?page=2&limit=20 - Pagination
    • ?status=active&sort=date - Data filtering
    • ?from=2025-01-01&to=2025-12-31 - Date ranges
  3. Anchor Fragment (#SomewhereInTheDocument). Ideal for client-side navigation and page sections:
    • #L20-L35 - GitHub line highlighting
    • #features - Scroll to section
    • #/dashboard - Single-page app routing (though it’s rarely used these days)

Common Patterns That Work for Query Parameters

Multiple values with delimiters

Sometimes you’ll see multiple values packed into a single key using delimiters like commas or plus signs. It’s compact and human-readable, though it requires manual parsing on the server side.

?languages=javascript+typescript+python
?tags=frontend,react,hooks

Nested or structured data

Developers often encode complex filters or configuration objects into a single query string. A simple convention uses key–value pairs separated by commas, while others serialize JSON or even Base64-encode it for safety.

?filters=status:active,owner:me,priority:high
?config=eyJyaWNrIjoicm9sbCJ9==  (base64-encoded JSON)

Boolean flags

For flags or toggles, it’s common to pass booleans explicitly or to rely on the key’s presence as truthy. This keeps URLs shorter and makes toggling features easy.

?debug=true&analytics=false
?mobile  (presence = true)

Arrays (Bracket notation)

?tags[]=frontend&tags[]=react&tags[]=hooks

Another old pattern is bracket notation, which represents arrays in query parameters. It originated from early web frameworks like PHP where appending [] to a parameter name signals that multiple values should be grouped together.

?tags[]=frontend&tags[]=react&tags[]=hooks
?ids[0]=42&ids[1]=73

Many modern frameworks and parsers (like Node’s qs library or Express middleware) still recognize this pattern automatically. However, it’s not officially standardized in the URL specification, so behavior can vary depending on the server or client implementation. Notice how it even breaks the syntax highlighting on my website.

The key is consistency. Pick patterns that make sense for your application and stick with them.

State via URL Parameters

Let’s look at real-world examples of URLs as state containers:

PrismJS Configuration

https://prismjs.com/download.html#themes=prism&languages=markup+css+clike+javascript&plugins=line-numbers

The entire syntax highlighter configuration encoded in the URL. Change anything in the UI, and the URL updates. Share the URL, and someone else gets your exact setup. This one uses anchor and not query parameters, but the concept is the same.

GitHub Line Highlighting

https://github.com/zepouet/Xee-xCode-4.5/blob/master/XeePhotoshopLoader.m#L108-L136

It links to a specific file while highlighting lines 108 through 136. Click this link anywhere, and you’ll land on the exact code section being discussed.

Google Maps

https://www.google.com/maps/@22.443842,-74.220744,19z

Coordinates, zoom level, and map type all in the URL. Share this link, and anyone can see the exact same view of the map.

Figma and Design Tools

https://www.figma.com/file/abc123/MyDesign?node-id=123:456&viewport=100,200,0.5

Before shareable design links, finding an updated screen or component in a large file was a chore. Someone had to literally show you where it lived, scrolling and zooming across layers. Today, a Figma link carries all that context like canvas position, zoom level, selected element. Literally everything needed to drop you right into the workspace.

E-commerce Filters

https://store.com/laptops?brand=dell+hp&price=500-1500&rating=4&sort=price-asc

This is one of the most common real-world patterns you’ll encounter. Every filter, sort option, and price range preserved. Users can bookmark their exact search criteria and return to it anytime. Most importantly, they can come back to it after navigating away or refreshing the page.

Frontend Engineering Patterns

Before we discuss implementation details, we need to establish a clear guideline for what should go into the URL. Not all state belongs in URLs. Here’s a simple heuristic:

Good candidates for URL state:

  • Search queries and filters
  • Pagination and sorting
  • View modes (list/grid, dark/light)
  • Date ranges and time periods
  • Selected items or active tabs
  • UI configuration that affects content
  • Feature flags and A/B test variants

Poor candidates for URL state:

  • Sensitive information (passwords, tokens, PII)
  • Temporary UI states (modal open/closed, dropdown expanded)
  • Form input in progress (unsaved changes)
  • Extremely large or complex nested data
  • High-frequency transient states (mouse position, scroll position)

If you are not sure if a piece of state belongs in the URL, ask yourself: If someone else clicking this URL, should they see the same state? If so, it belongs in the URL. If not, use a different state management approach.

Implementation using Plain JavaScript

The modern URLSearchParams API makes URL state management straightforward:

// Reading URL parameters
const params = new URLSearchParams(window.location.search);
const view = params.get('view') || 'grid';
const page = params.get('page') || 1;
// Updating URL parameters
function updateFilters(filters) {
  const params = new URLSearchParams(window.location.search);
  // Update individual parameters
  params.set('status', filters.status);
  params.set('sort', filters.sort);
  // Update URL without page reload
  const newUrl = `${window.location.pathname}?${params.toString()}`;
  window.history.pushState({}, '', newUrl);
  // Now update your UI based on the new filters
  renderContent(filters);
}
// Handling back/forward buttons
window.addEventListener('popstate', () => {
  const params = new URLSearchParams(window.location.search);
  const filters = {
    status: params.get('status') || 'all',
    sort: params.get('sort') || 'date'
  };
  renderContent(filters);
});

The popstate event fires when the user navigates with the browser’s Back or Forward buttons. It lets you restore the UI to match the URL, which is essential for keeping your app’s state and history in sync. Usually, your framework’s router handles this for you, but it’s good to know how it works under the hood.

Implementation using React

React Router and Next.js provide hooks that make this even cleaner:


import { useSearchParams } from 'react-router-dom';
// or for Next.js 13+: import { useSearchParams } from 'next/navigation';
function ProductList() {
  const [searchParams, setSearchParams] = useSearchParams();
  // Read from URL (with defaults)
  const color = searchParams.get('color') || 'all';
  const sort = searchParams.get('sort') || 'price';
  // Update URL
  const handleColorChange = (newColor) => {
    setSearchParams(prev => {
      const params = new URLSearchParams(prev);
      params.set('color', newColor);
      return params;
    });
  };
  return (
    <div>
      <select value={color} onChange={e => handleColorChange(e.target.value)}>
        <option value="all">All Colors</option>
        <option value="silver">Silver</option>
        <option value="black">Black</option>
      </select>
      {/* Your filtered products render here */}
    </div>
  );
}

Best Practices for URL State Management

Now that we’ve seen how URLs can hold application state, let’s look at a few best practices that keep them clean, predictable, and user-friendly.

Handling Defaults Gracefully

Don’t pollute URLs with default values:

// Bad: URL gets cluttered with defaults
?theme=light&lang=en&page=1&sort=date
// Good: Only non-default values in URL
?theme=dark  // light is default, so omit it
Use defaults in your code when reading parameters:
function getTheme(params) {
  return params.get('theme') || 'light'; // Default handled in code
}

Debouncing URL Updates

For high-frequency updates (like search-as-you-type), debounce URL changes:

import { debounce } from 'lodash';
const updateSearchParam = debounce((value) => {
  const params = new URLSearchParams(window.location.search);
  if (value) {
    params.set('q', value);
  } else {
    params.delete('q');
  }
  window.history.replaceState({}, '', `?${params.toString()}`);
}, 300);
// Use replaceState instead of pushState to avoid flooding history

pushState vs. replaceState

When deciding between pushState and replaceState, think about how you want the browser history to behave. pushState creates a new history entry, which makes sense for distinct navigation actions like changing filters, pagination, or navigating to a new view — users can then use the Back button to return to the previous state. On the other hand, replaceState updates the current entry without adding a new one, making it ideal for refinements such as search-as-you-type or minor UI adjustments where you don’t want to flood the history with every keystroke.

URLs as Contracts

When designed thoughtfully, URLs become more than just state containers. They become contracts between your application and its consumers. A good URL defines expectations for humans, developers, and machines alike

Clear Boundaries

A well-structured URL draws the line between what’s public and what’s private, client and server, shareable and session-specific. It clarifies where state lives and how it should behave. Developers know what’s safe to persist, users know what they can bookmark, and machines know whats worth indexing.

URLs, in that sense, act as interfaces: visible, predictable, and stable.

Communicating Meaning

Readable URLs explain themselves. Consider the difference between the two URLs below.

https://example.com/p?id=x7f2k&v=3
https://example.com/products/laptop?color=silver&sort=price

The first one hides intent. The second tells a story. A human can read it and understand what they’re looking at. A machine can parse it and extract meaningful structure.

Jim Nielsen calls these “examples of great URLs”. URLs that explain themselves.

Caching and Performance

URLs are cache keys. Well-designed URLs enable better caching strategies:

  • Same URL = same resource = cache hit
  • Query params define cache variations
  • CDNs can cache intelligently based on URL patterns

You can even visualize a user’s journey without any extra tracking code:

/products => selects category => /products?category=laptops => adds price filter => products?category=laptops&price=500-1000

Your analytics tools can track this flow without additional instrumentation. Every URL parameter becomes a dimension you can analyze.

Versioning and Evolution

URLs can communicate API versions, feature flags, and experiments:

  • ?v=2                   // API version
  • ?beta=true             // Beta features
  • ?experiment=new-ui     // A/B test variant

This makes gradual rollouts and backwards compatibility much more manageable.

Anti-Patterns to Avoid

Even with the best intentions, it’s easy to misuse URL state. Here are common pitfalls:

“State Only in Memory” SPAs

The classic single-page app mistake:

// User hits refresh and loses everything
const [filters, setFilters] = useState({});

If your app forgets its state on refresh, you’re breaking one of the web’s fundamental features. Users expect URLs to preserve context. I remember a viral video from years ago where a Reddit user vented about an e-commerce site: every time she hit “Back,” all her filters disappeared. Her frustration summed it up perfectly. If users lose context, they lose patience.

Sensitive Data in URLs

This one seems obvious, but it’s worth repeating:

// NEVER DO THIS
?password=secret123

URLs are logged everywhere: browser history, server logs, analytics, referrer headers. Treat them as public.

Inconsistent or Opaque Naming

// Unclear and inconsistent
?foo=true&bar=2&x=dark
// Self-documenting and consistent
?mobile=true&page=2&theme=dark

Choose parameter names that make sense. Future you (and your team) will thank you.

Overloading URLs with Complex State

?config=eyJtZXNzYWdlIjoiZGlkIHlvdSByZWFsbHkgdHJpZWQgdG8gZGVjb2RlIHRoYXQ_IiwiZmlsdGVycyI6eyJzdGF0dXMiOlsiYWN0aXZlIiwicGVuZGluZyJdLCJwcmlvcml0eSI6WyJoaWdoIiwibWVkaXVtIl0sInRhZ3MiOlsiZnJvbnRlbmQiLCJyZWFjdCIsImhvb2tzIl0sInJhbmdlIjp7ImZyb20iOiIyMDI0LTAxLTAxIiwidG8iOiIyMDI0LTEyLTMxIn19LCJzb3J0Ijp7ImZpZWxkIjoiY3JlYXRlZEF0Iiwib3JkZXIiOiJkZXNjIn0sInBhZ2luYXRpb24iOnsicGFnZSI6MSwibGltaXQiOjIwfX0==

If you need to base64-encode a massive JSON object, the URL probably isn’t the right place for that state.

URL Length Limits

Browsers and servers impose practical limits on URL length (usually between 2,000 and 8,000 characters) but the reality is more nuanced. As this detailed Stack Overflow answer explains, limits come from a mix of browser behavior, server configurations, CDNs, and even search engine constraints. If you’re bumping against them, it’s a sign you need to rethink your approach.

Breaking the Back Button

// Replacing state incorrectly
history.replaceState({}, '', newUrl); // Used when pushState was needed

Respect browser history. If a user action should be “undoable” via the back button, use pushState. If it’s a refinement, use replaceState.

Closing Thought

That PrismJS URL reminded me of something important: good URLs don’t just point to content. They describe a conversation between the user and the application. They capture intent, preserve context, and enable sharing in ways that no other state management solution can match.

We’ve built increasingly sophisticated state management libraries like Redux, MobX, Zustand, Recoil and others. They all have their place but sometimes the best solution is the one that’s been there all along.

In my previous article, I wrote about the hidden costs of bad URL design. Today, we’ve explored the flip side: the immense value of good URL design. URLs aren’t just addresses. They’re state containers, user interfaces, and contracts all rolled into one.

If your app forgets its state when you hit refresh, you’re missing one of the web’s oldest and most elegant features.

Workspace URL naming pattern decision

Mike's Notes

I was able to decide on the workspace URL naming pattern after conducting some experiments over the last week.

Resources

References

  • Reference

Repository

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

Last Updated

25/10/2025

Workspace URL naming pattern decision

By: Mike Peters
On a Sandy Beach: 06/10/2025

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

Over the last week, I have been experimenting with different URL naming patterns. I had to devise patterns for Pipi to use when it automatically generates SaaS applications with User Interfaces (UI).

Note: The URLs below don't link to anything.

Learning from others

I looked at how common and very popular cloud products use URL naming patterns, including;

  • Google Workspace
  • MuleSoft
  • Odoo
  • Salesforce
  • ServiceNow
  • Zoho

Conclusion

I started with the simplicity of Google and ended with the richness of ServiceNow. The pattern simply needs to be predictable and consistently effective. The URLs after the  i18n codename need to be in the local language, eg French.

Components

The Pipi-generated URLs will be made up of the following parts;

  • User account, eg demo
  • Device/screen specific, eg mobile m , braille b , kiosk k , VR v
  • Platform, eg cloud.ajabbi.com
  • i18n code, eg eng-UK
  • Major version, eg 9
  • Account type, eg e for enterprise
  • Account subtype, eg a for app, s for settings
  • Industry name, eg rail
  • One or more nested industry objects, eg rolling stock
  • CRUD verbs, eg patient-new
  • Multi instances directory, eg email/e/
  • ID etc can be masked as a UUID, eg durmdis7d3kbp
  • Workflow specific, eg page/administer/ui-builder/concept

Pattern examples

  • demo.cloud.ajabbi.com/eng/9/e/a/screen/location/l/adytenm.html
  • demo.m.cloud.ajabbi.com/fra/9/e/a/écran/emplacement/e/adytenm.html

URL masking and pattern configuration

It should be straightforward for a User Account holder to mask these URLs and modify other pattern configurations.

  • m.rail.example.com/en-au/rolling-stock/rolling-stock-new/
  • m.en-au.example.com/rail/rolling-stock/new/
  • en-au.bigrail.com/rolling-stock/r/2945/history/
  • k.en-au.app.bigrail.com/rolling-stock/r/2945/history/

Industry names

Third draft revision of the Pipi 6 industry names used for English i18n URLs. This has been imported into Pipi 9 for testing purposes. The nouns are singular.

  • Agriculture: agriculture/
  • Art: art/
  • Aviation: aviation/
  • Conservation: conservation/
  • Construction: construction/
  • Drainage: drainage/
  • Electricity Supply: electricity-supply/
  • Forestry: forestry/
  • GLAM (Galleries-Libraries-Archives-Museums): glam/
  • Health: health/
  • Horticulture: horticulture/
  • Learning: learning/
  • Port: port/
  • Rail: rail/
  • Research: research/
  • Road: road/
  • Screen (was Film): screen/
  • Sewer: sewer/
  • Transport: transport/
  • Water Supply: water-supply/
  • Website: website/
  • Zoo: zoo/

Next steps

  • Begin creating full-page mockups for community testing.
  • Adjust as necessary

Domain Model Templates

Mike's Notes

This is my first attempt to define a Domain Model Template.

Resources

References

  • Reference

Repository

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

Last Updated

03/10/2025

Domain Model Templates

By: Mike Peters
On a Sandy Beach: 03/10/2025

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

An industry application, as defined by Pipi, can be filtered and constrained by a Domain Model Template. This creates a custom model with workflows, properties, and i18n for a specific use. A bit like different Lego models built out of the same bricks.

Examples

The screen industry application includes these templates

  • Feature Film
  • Short Film
  • Documentary
  • Live Broadcast
  • Film Studio

The health industry application consists of these templates

  • Family Doctor
  • Hospital
  • Public Health
  • Allied Health
  • Personal Health

Industry object

For the same Industry application, Domain Model Templates may use different collections of industry objects. The UI control menus can differ. Workspace URLs are not always changed by these templates, but can be.

Pipi digital twin

The underlying industry digital twin, Pipi, captures the entire picture, using a world model, regardless of the specific Domain Model Templates in use.

User Accounts

A User Account using a Domain Model Template sees only part of the whole. The account pays only for the actual usage of that part of the digital twin.

User account types and workspace URLs

Mike's Notes

My notes to make explicit how workspace URLs work with different user account types. I tend to make these sorts of decisions as late as possible, when the correct choice becomes very obvious.

Resources

References

  • Reference

Repository

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

Last Updated

08/11/2025

User account types and workspace URLs

By: Mike Peters
On a Sandy Beach: 02/10/2025

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

My work this week has been focused on determining the naming pattern for workspace URLs. The pattern can differ by user account type.

User Account Types

  • Agent
  • Developer
  • Enterprise
  • Personal
  • Research
  • SME
  • Temp

Agent Account

  • Always in credit and paid by usage.
  • For Pipi to self-manage.
  • Utilises a swarm of Pipi hosts operating within an ecosystem.
  • i18n English-UK URLs.
  • "a" prefix.
  • Uses agent-tenanted workspaces.
  • Uses raw codename patterns in the workspace URL naming.
  • It is a digital twin.
  • Permanent.

Developer Account

  • Always in credit and paid by usage.
  • For developers to support enterprise accounts.
  • Uses a dedicated Pipi host.
  • i18n URLs available.
  • "d" prefix.
  • Uses sole-tenanted workspaces.
  • Uses selectable patterns in the workspace URL naming.
  • No digital twin. Works with customer digital twins.
  • Permanent.

Enterprise Account

  • Always in credit and paid by usage.
  • For large organisations with huge systems.
  • Uses dedicated Pipi hosts.
  • i18n URLs available.
  • "e" prefix.
  • Uses sole-tenanted workspaces.
  • Uses customised patterns in the workspace URL naming.
  • Dedicated digital twin.
  • Permanent.

Personal Account

  • Free.
  • Everyone who gets a username and password.
  • Shares a common Pipi host.
  • i18n URLs available.
  • "p" prefix.
  • Uses a multi-tenanted workspace.
  • Uses standard patterns in the workspace URL naming.
  • Shared digital twin.
  • Permanent.

Research Account

  • Always in credit and paid by usage.
  • For researchers to train Pipi.
  • Uses a dedicated Pipi host.
  • i18n URLs available.
  • "r" prefix.
  • Uses sole-tenanted workspaces.
  • Uses raw codename patterns in the workspace URL naming.
  • Dedicated digital twin.
  • Permanent.

SME Account

  • Always in credit and paid by plan.
  • For small organisations or businesses that want to use simple apps.
  • Shares a common Pipi host.
  • i18n URLs available.
  • "s" prefix.
  • Uses multi-tenanted workspaces.
  • Uses standard patterns in the workspace URL naming.
  • Shared digital twin.
  • Permanent.

Temp Account

  • Free.
  • For temporary users who need to do something without creating an account.
  • No Pipi host.
  • i18n URLs available.
  • "t" prefix.
  • Uses a multi-tenanted workspace.
  • Uses standard patterns in the workspace URL naming.
  • No digital twin.
  • Temporary.

Workspace URL examples

Mike's Notes

Today, I'm diving deep into the existing configuration settings for industry domain-based applications. They were done for Pipi 6 and 7, which is a while ago. They now need to be edited and migrated into Pipi 9. Work on creating the workspace UI can then begin. Eventually, Pipi 9 will no longer be headless.

Resources

References

  • Reference

Repository

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

Last Updated

25/10/2025

Workspace URL examples

By: Mike Peters
On a Sandy Beach: 01/10/2025

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

This is a working draft and subject to change as I experiment. I need to test this across multiple diverse industries to ensure it works automatically and reliably.

Note: The URLs below don't link to anything.

General Notes

  • Industry object names can be aliased to conform to industry-specific terms, depending on the parent industry name. Hence, Stock in a Plant Nursery has a different meaning than Rolling Stock in Rail.
  • Applying i18n will change the URLs. However, the underlying ASCI code names remain the same.
  • Unique ASCI code names to avoid namespace collisions.
  • These URLs are for logged-in users.
  • Style Guide: Use plural or singular names? Are they all nouns?
  • Each of these industry names has a corresponding three-letter code. They could also be used for the URLs. eg, cst/ for construction, but not very user-friendly.
  • Ajabbi subdomain name options: workspace, app, cloud, or wsp. I think I will go with "cloud". It is shorter than "workspace". The term workspace can be used as a noun to describe what cloud.ajabbi.com is.

Industry names

Second draft revision of the Pipi 6 industry names used for English i18n URLs. The final revision will be imported into Pipi 9 for testing purposes. The nouns are singular.

  • Agriculture: agriculture/
  • Art: art/
  • Aviation: aviation/
  • Conservation: conservation/
  • Construction: construction/
  • Drainage: drainage/
  • Electricity Supply: electricity-supply/
  • Forestry: forestry/
  • GLAM (Galleries-Libraries-Archives-Museums): glam/
  • Learning: learn/
  • Health: health/
  • Horticulture: horticulture/
  • Port: port/
  • Rail: rail/
  • Research: research/
  • Road: road/
  • Screen (was Film): screen/
  • Sewer: sewer/
  • Transport: transport/
  • Water Supply: water-supply/
  • Website: website/
  • Zoo: zoo/

Industry objects

First draft revision of the Pipi 7 industry names used for URLs. Industry domains can be combined with industry objects, provided that this is allowed by schema constraints. Final revision will be imported into Pipi 9.

  • Task: task/
  • Settings: settings/
  • Person: person/
  • Script: script/
  • Storyboard: storyboard/
  • Shot list: shot/
  • Shooting schedule: schedule/
  • Prop: prop/
  • Location: location/
  • Location: location/l/
  • Set: set/
  • Crew: crew/
  • Wardrobe: wardrobe/
  • Rolling Stock: rolling-stock/
  • Budget: budget/
  • Loan: loan/
  • Mail: email/
  • Mail: email/inbox/
  • Mail: email/inbox/i/
  • Patient: patient/

Default Enterprise "e" deployment examples

The URL pattern is /e/industry name/industry object/

  • demo.cloud.ajabbi.com/eng/9/e/aviation/aircraft/
  • demo.cloud.ajabbi.com/eng/9/e/aviation/airport/
  • demo.cloud.ajabbi.com/eng/9/e/aviation/airspace/
  • demo.cloud.ajabbi.com/eng/9/e/aviation/cargo/
  • demo.cloud.ajabbi.com/eng/9/e/aviation/flight/
  • demo.cloud.ajabbi.com/eng/9/e/aviation/passenger/
  • demo.cloud.ajabbi.com/eng/9/e/glam/collection/
  • demo.cloud.ajabbi.com/eng/9/e/glam/loan/
  • demo.cloud.ajabbi.com/eng/9/e/glam/9/event/
  • demo.cloud.ajabbi.com/eng/9/e/rail/booking/
  • demo.cloud.ajabbi.com/eng/9/e/rail/freight/
  • demo.cloud.ajabbi.com/eng/9/e/rail/rolling-stock/new/
  • demo.cloud.ajabbi.com/eng/9/e/rail/track/
  • demo.cloud.ajabbi.com/eng/9/e/screen/budget/
  • demo.cloud.ajabbi.com/eng/9/e/screen/location/
  • demo.cloud.ajabbi.com/eng/9/e/screen/scritp/
  • demo.cloud.ajabbi.com/eng/9/e/sewer/network/
  • demo.cloud.ajabbi.com/eng/9/e/website/wiki/page-edit/

    Additional examples

    Use more levels if required.

    • demo.cloud.ajabbi.com/eng/9/e/health/email/inbox/
    • demo.cloud.ajabbi.com/eng/9/e/health/email/inbox/i/

    Workspace URL naming pattern

    Mike's Notes

    I'm working out a pattern to use for naming workspace URLs. This is part of the current build roadmap.

    Resources

    References

    • Reference

    Repository

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

    Last Updated

    21/11/2025

    Workspace URL naming pattern

    By: Mike Peters
    On a Sandy Beach: 30/09/2025

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

    Logged-in Ajabbi users will be able to use web-based applications called a workspace. Each application requires a URL that follows a predefined pattern.

    Again, this is a work in progress and is likely to change, especially as it addresses performance, usability, security, and privacy issues.

    Here are examples used by other companies.

    Google Workspace example URLs

    • https://calendar.google.com/calendar/u/0/r/week
    • https://calendar.google.com/calendar/u/0/r/month
    • https://mail.google.com/mail/u/0/#inbox
    • https://mail.google.com/mail/u/0/#sent
    • https://draft.blogger.com/blog/posts/jsdksjdksJK;Sjk;SJDKsjd/
    • https://draft.blogger.com/blog/post/edit/hhddfddfd/
    • https://docs.google.com/document/d/5fd8f5/
    • https://contacts.google.com/directory
    • https://contacts.google.com/person/123456789/
    • https://groups.google.com/all-groups
    • https://groups.google.com/g/ontolog-forum
    • https://groups.google.com/g/ontolog-forum/c/coj8JqR6nzw

    Zoho Office Suite example URLs

    • https://www.zoho.com/mail/
    • https://accounts.zoho.com.au/signin?

    Service Now example URLs

    • <instance>.service-now.com/now/cmdb/relationship-health-dashboard/
    • https://www.servicenow.com/docs/bundle/zurich-healthcare-life-sciences/page/product/healthcare-life-sciences/concept/hcls-cto-care-team-portal.html
    • <instance>.service-now.com/now/servicenow-studio/home
    • https://www.servicenow.com/docs/bundle/zurich-application-development/page/administer/ui-builder/concept/ui-builder-overview.html

    MuleSoft example URLs

    • https://docs.mulesoft.com/exchange/to-describe-an-asset

    Note: The URLs below don't link to anything.

    Ajabbi workspace domain

    Note: workspace. or app. or cloud. or wsp/ ? I have decided on cloud.

    The default naked domain URL is

    • https;//cloud.ajabbi.com/

    The user account code name will be added as a URL before the domain.

    • https;//example.cloud.ajabbi.com/

    Domain redirection enables

    • https://cloud.example.com/

    Ajabbi Workspace proposed available URL patterns

    A lot of customisation will be possible for user accounts.

    • https://cloud.ajabbi.com/eng/9/e/calendar/
    • https://example.cloud.ajabbi.com/eng/9/e/calendar/
    • https://example.com/cloud/eng/9/e/calendar/
    • https://example.com/eng-uk/cloud/9/e/calendar/
    • https://app.example.com/eng-uk/e/calendar/
    • https://calendar.example.com/eng-uk/
    • https://en.example.com/workspace/e/calendar/
    • https://fr.example.com/espace/e/calendrier/

    Workspace application directories

    Each application has directories associated with different tasks.

    Mail

    • inbox/
    • draft/
    • sent/

    Some simple examples using mail.

    • https://cloud.ajabbi.com/eng/9/e/email/inbox/
    • https://cloud.ajabbi.com/eng/9/e/email/draft/12345678/

    Security concerns

    Long, meaningless code will be used to name endpoints similar to those used by Google.

      • https;//cloud.ajabbi.com/eng/9/e/email/draft/hnjsdhtrhxn79snrfusni9c5/

      To do next

      1. Define the code names to use with all the workspace applications
      2. Build some static web-based workspace mockups
      3. Make some examples in other languages and scripts
      4. Share with volunteer testers
      5. Reiterate till people are happy
      6. Build a working demo at
        • https://demo.cloud.ajabbi.com/
      7. Provide a Template Engine template for the Pipi Render Engine to render on demand from the Pipi Deployment Engine.
      8. Automate the deployment of workspaces for logged-in users.

      i18n URL

      Mike's Notes

      Ajabbi will be in multiple languages. What URL structure should be used to organise material in different languages on a website? What do others do?

      Resources

      • Resource

      References

      • Reference

      Repository

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

      Last Updated

      18/05/2025

      i18n URL

      By: Mike Peters
      On a Sandy Beach: 04/08/2024

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

      wikipedia.org

      • https://en.wikipedia.com/wiki/ccs/

      Mozilla MDN

      • https://developer.mozilla.org/en-us/ccs/

      ajabbi.com

      • https://ajabbi.com/eng/ccs/

      example.com

      • https://en.developer.example.com/ccs/

      Options

      Subdomains can easily be hosted on separate hosts.