thingsinjars

  • 3 Jun 2020

    Application Layers

    On recent web app projects in HERE Tracking, I've been using a layered component structure that fits particularly well with frontends that access and interact with JSON APIs.

    The primary reason for structuring our apps this way is that it gives us a lot of freedom in our workflow and still fits well within the larger HERE structure with horizontal design teams that align across the multiple products. This works as a way to enable parallel contributions from everybody across the engineering teams.

    The layers are:

    • Application
    • Library (JS library to access the API)
    • Logical (maps business objects to layout concepts)
    • Layout (renders layout components)
    • Components (low level elements and design)

    And, generally, these layers are within the areas of expertise of the Backend, Frontend and Design specialists.

    It shouldn't be necessary to say this but just to make sure I'm not misunderstood: it's important to note that none of these roles is limited to the scope below, this is just a general 'areas of expertise' guide. See my previous post about shared responsibilities.

    • Backend teams create the API and implement the JS library. If possible, also implement the basic logical component which performs whatever business logic is required.
    • Frontend teams build the application out of components, further maintain the logical components and the mapping between logical and layout components
    • Design teams implement the core web components and company-wide design system of UX, UI, mental models, etc. This layer can also be based upon an open-source design system such as Carbon or Material.

    Of course, the backend team can modify the web components if they have the inclination just as the design team couuld make improvements to the database if they are able to improve the product.

    Example

    NOTE: The example below is mostly Vue-like but this layered approach doesn't rely on any framework, language or coding style. It's a way to split and share responsibilities.

    Rubber Duck Inc. make GPS-enabled rubber ducks. They have a dashboard where customers can see the location of their ducks. The dashboard includes an overview list of ducks.

    Backend

    The Backend team extend the Duck definition (stored in their duck-ument database) to include a new 'icon' field then update the GET /ducks endpoint that allows you to receive a list of all the ducks you own.

    Sample response:

    {
      "data": [{
        "id": 123,
        "name": "Hugh",
        "colour": "hotpink,
        "icon": "star",
      }, [{
        "id": 321,
        "name": "Anthony",
        "colour": "yellow",
        "icon": "dot",
      }],
      "count": 2
    }
    

    They check to see if the JS library needs updating (if they are using automated code generation, this might already be done). It doesn't, it already returns the full data array of the response:

    fetch(`${api}/ducks`)
      .then(response => response.json)
      .then(json => json.data)
    

    The data is rendered in the web app using a logical web component

    <duck-list :ducks="ducks"/>

    The engineer digs one step deeper (into the 'logical' or 'application components' library) and sees that the duck-list component wraps the generic-list component but with a few modifications to the data structure.

    <template>
      <generic-list :items="items"/>
    </template>
    <script>
      :
      props: {
        ducks: Array,
      },
      data() {
        return {
          items: this.ducks.map(duck => ({
            title: duck.name,
            subtitle: `This duck is ${duck.colour}`,
          }))
        };
      },
      :
    </script>

    And then modifies it to also pass the icon into the generic-list so that each item looks like:

    {
      title: duck.name,
      subtitle: `This duck is ${duck.colour}`,
      icon: duck.icon
    }
    

    Frontend

    In a parallel task, the frontend specialist can be improving the generic-list component. This component doesn't do much except create a set of generic-list-item elements.

    <template>
      <ul>
        <generic-list-item for="item in items" :item="item">
      </ul>
    </template>

    Each generic-list-item is built from basic web components from the company's DuckDesign language:

    <template>
      <li>
        <rubber-duck-title>{{title}}</rubber-duck-title>
        <rubber-duck-subtitle>{{subtitle}}</rubber-duck-subtitle>
      </li>
    </template>

    Frontend can then improve this to take advantage of the new data structure. Handily, there's a rubber-duck-avatar component. That should work here:

    <template>
      <li>
        <rubber-duck-avatar if="icon">{{icon}}</rubber-duck-icon>
        <rubber-duck-title>{{title}}</rubber-duck-title>
        <rubber-duck-subtitle>{{subtitle}}</rubber-duck-subtitle>
      </li>
    </template>

    Design

    So close, except the alignment's not quite right... Frontend has a chat with design and they decide that, while this could be solved in the generic-list-item component (or even in the duck-list or the application layer), having an icon next to a title is a more generic requirement so it should be solved in the lowest design component layer:

    rubber-duck-avatar + rubber-duck-title {
      margin-left: 0;
    }
    

    Design tweaks the alignment of the rubber-duck-avatar component and deploys it company-wide to all product teams. Every team benefits from the shared library, the DuckDashboard team gets to show off their new duck icons, everybody helped complete the product story and nobody got hurt.

    Conclusion

    Admittedly, this does lead to having multiple individual repositories for a single application

    • dashboard-app
    • duck-api.js
    • dashboard-components
    • layout-components
    • duck-design-web-components

    But it does give each team the flexibility to contribute beyond their core area and not be blocked by other teams.

    Let me know what you think or how you'd improve it. Do you already use an approach like this?

    Development, Opinion

  • 7 May 2020

    One product, many owners

    or: "What you are is not what you do"

    Imagine you're on a bank heist. You're literally right in the middle of the job. Your expert team consists of some very talented criminals. There's The Hacker, The Driver, The Money Man, The Explosives Expert, You.

    Heist

    While The Hacker is rewriting the safe door control circuit's firmware to speed up the clock and release the time-lock, you find the computer controlling the security cameras. Do you make a note on a ToDo list?

    • Remind the Hacker to delete the security footage [ ]

    Or do you grab the mouse and select File > Delete Security Footage?

    (Yes, it is that easy, you specifically chose this bank to hit because it has terrible security)

    Once you leave the building, there's a bit of confusion and The Explosives Expert ends up in the driving seat. The Driver is in the back! The police are one block away. Do you all get out, rearrange, let the driver get in the front? Or do you just start driving? The Explosives Expert may not know the exact route but, remember, The Driver is right there, able to give directions.

    And that is literally exactly what developing a software product is like.


    Product

    The role of the Product Owner is fairly well known, well defined and ubiquitous across agile teams. But we know that everybody in the team is responsible for the product. The PO might be an expert in certain areas of understanding the customers' mindset or prioritisation but everyone is responsible for the product. Everyone owns the product but, in this instance, there is one person with the title Product Owner.

    Quality

    In the same way, everyone working on a product is responsible for the quality. If you're working on the database and you find that the drop-down menu occasionally disappears, there are multiple ways you could deal with it.

    • You could just ignore it. It's not the databases's fault, after all.
    • You could file a ticket in the system for someone else to pick up.
    • You could figure out a reproducible test-case.
    • You could pop open the web inspector and check the console, poke around a bit.
    • You could check out the code and fix it.

    There are a lot of ways you could do this, depending on your abilities and your available time but whatever you do – as long as it's not just ignoring the problem – you are taking a step to improve the quality of the product.

    The QA might be an expert in writing test cases or have the kind of brain that would think of using a base64-encoded png as a username but that doesn't mean quality begins and ends with them. They are the Quality Owner. Everyone is responsible for quality, but it's the Quality Owner's priority.

    Architecture

    And so we come to the Architecture Owner. Even now, a couple of decades after the Agile Manifesto with repeated swings for and against it, Agile and Architecture have an uneasy relationship or, at least, a poorly-defined one.

    The image of The Architect as the keeper of the book, the writer of the specification still triggers rebellion in the minds of those who zealously misunderstand agile practices. Of course, there can't be a predestined development plan when the destination is unknown. But that doesn't mean you blindly run headlong into every problem. You look around, you keep aware of your surroundings, of other projects. If nothing else, you stay aware of your situation to know if you're doing something you've done before. If you are, you can look at how you solved this in the past and do the same or better this time round. This is everyone's responsibility but it's also Architecture.

    "The last time I did a job in this town, the bank had a silent alarm system. You might want to cut the wires on this one before it's triggered this time."

    Agile architecture is about looking a little bit forward and a little bit back. How will this work next year? How did we solve it last year? Is another team working on the same thing? Did they? Will they? Any prototyping done to figure out the next step of the journey is architecture.

    Just as development, quality, product, design, business are all essential parts of any project, so is architecture. The Architecture Owner doesn't only do architecture and isn't the only person to do architecture tasks. It is merely their priority. They may have additional expertise or experience, they may be faster at building prototypes or drawing boxes-and-arrows but they are as integral a part of the product development team as anyone else.

    To be effectively agile, everyone should care ultimately about creating the product.


    Practicality

    This is all good in theory. What does this actually mean? Is 'Architecture Owner' a full-time job? Does an architect architect all day long?

    Well, is Product Owner a full-time job? QA? Explosives Expert? For a lot of teams, it is. But not all. A particularly small team might have an Engineer who acts as part-time PO. A larger team will have a dedicated person for each role. What you are is not what you do. The whole point of this is that being the owner of a domain doesn't make you solely and exclusively responsible.

    In many cases, the person who assumes the AO role will be a strong engineer who can jump on any part of the codebase and be effective quickly (because in addition to being experienced engineers, they understand the architecture and the motivations behind the architecture) and who coaches others to think more architecturally and be effective quickly.


    Notes

    In the decade or so since I first wrote this, the role of architecture in agile has come and gone and come back a couple of times. I find myself directing people to the same articles repeatedly so I figured it was time to update and publish this.

    There are many other articles on agile architecture, most of which are written much more seriously than this.

    • https://www.ben-morris.com/relax-theres-no-conflict-between-architecture-and-agile/
    • https://www.adventureswithagile.com/2015/01/19/architecting-an-agile-solution-with-help-from-dad/
    • http://www.agilemodeling.com/essays/architectureOwner.htm
    • https://en.wikipedia.org/wiki/Agile_Architecture

    Geek, Development, Opinion

  • 23 Oct 2013

    High-definition CSS Testing!

    Well, kinda. Before giving my Automated CSS Testing talk at CSS Summit in July, I recorded a video of it as a backup. If everything fell apart during my presentation, Ari could seamlessly switch over the One I Made Earlier. Fortunately, the Internet did what it does best and just worked fine.

    That means I have an Automated CSS Testing video all ready and waiting that nobody's seen!

    Yes, it does get progressively darker as you watch. That's not your eyes playing tricks on you, that's me sitting on my balcony recording as the sun went down.

    CSS, Opinion, Development

  • 2 Oct 2012

    How App.net became useful

    After Twitter started announcing changes to its API usage and people started to get worried about the future of the developer eco-system, App.net appeared. It provides a streaming data-platform in much the same way Amazon provides a web hosting platform. The reason for the Twitter comparison is that one of the things you can make with it is a Twitter-like public short message system. This was, in fact, the first thing the App.net developers made to showcase the platform: Alpha although that example seems to have convinced many people that the whole point was to build a Twitter-clone instead of a service whose purpose is to stream small, discrete blocks of meta-tagged data. The community-developed API spec is an important aspect of App.net as well although feature discussions can devolve into musings on Computer Science theory a bit too easily.

    For the first couple of weeks, it was fun to just hack around with the APIs, post a bit, build a little test app (disabled now that more App.net clients have push notifications). It all became much more interesting, however, when two new features were added to the platform – Machine-only posts and Well-known Annotations.

    Machine-only posts

    Pretty much exactly what they sound like. These are posts that are not intended to be viewed in any human-read conversation stream. They still get pushed around the network exactly the same as all other posts but to see them, you must explicitly say 'include machine-only posts' in your API calls. For developers who have been building silly toys on Twitter for a couple of years, this is fantastic. You don't need to create a separate account purely for data transfer. This can be part of your main account's data stream. I have quite a few Twitter accounts that I just use for outputs from various applications. I have one, in fact, that does nothing but list the tracks I listen to that I created for this side-project.

    By classifying these as 'machine-only', they can stay associated with the user and subject to whatever privacy controls they have set in general. This makes it far easier for the user to keep control of their data and easier for the service to track accurate usage. For devs, it also means you can hack away at stuff, even if it is to be public eventually, without worrying too much about polluting the global stream with nonsense.

    Well-known Annotations

    Annotations were part of the spec from the beginning but only implemented at the end of August. Annotation is just another word for per-post meta-data – each post has a small object attached which provides extra information. That's it.

    The annotations can be up to 8192 bytes of valid JSON which is quite a lot of meta-data. Even with this, however, the usefulness is limited to per application use-cases until some standards start to appear. There's nothing to stop a popular application being the one to set the standard but for the more general cases, it is most fitting to continue with the community-led development model. This is where Well-known Annotations come in.

    Well-known annotations are those attributes which are defined within the API spec. This means that the community can define a standard for 'geolocation', for example, and everyone who wants to use geolocation can use the standard to make their application's posts compatible with everybody else's.

    Obviously, I'm quite into my geolocated data. I love a bit of map-based visualisation, I do. Here's a sample of jQuery that will create a post with a standard geolocation annotation:

    $.ajax({
      contentType: 'application/json',
      data: JSON.stringify({
        "annotations": [{
          "type": "net.app.core.geolocation",
          "value": {
            "latitude": 52.5,
            "longitude": 13.3,
            "altitude": 0,
            "horizontal_accuracy": 100,
            "vertical_accuracy": 100
          }
        }],
        machine_only: true
      }),
      dataType: 'json',
      success: function(data) {
        console.log("Non-text message posted");
      },
      error: function() {
        console.log("Non-text message failed");
      },
      processData: false,
      type: 'POST',
      url: 'https://alpha-api.app.net/stream/0/posts?access_token=USERS_OAUTH_TOKEN'
    });
    

    In the same way as the machine-only posts, these annotations aren't provided on a default API request, you have to specifically ask for them to be included in the returned data. This is to make sure that the majority of use cases (public streaming, human-readable conversation) don't have to download up to 8KB of unnecessary data.

    Retrieving both

    This is an API call to retrieve posts marked machine-only and with annotations

    Potential use cases

    You might have noticed, the API call above had the machine-only attribute as well as the well-known geo annotation. If I wanted to create an app that would run on my phone and track my routes throughout the day, all I would need to do would be to run that $.ajax call periodically with my current geolocation. The data would be saved, distributed, streamed and could be rendered onto a map or into a KML at the end of the day. I could record hiking trails or museum tours, or share my location with someone I'm supposed to be meeting so they can find out where I'm coming from and why I'm late. That's just a couple of the single-user cases. Having a shared standard means that the potential for geo-tagged posts opens up to at least equal that of Twitter's. Heatmap-density diagrams showing areas of the most activity; global and local trends; location-based gaming. Add a 'news' annotation to geotagged posts and suddenly you've got a real-time local-news feed. Add 'traffic' and you've got community-created traffic reports.

    There are so many clever things you can do with location-tagged data. I hope others are just as enthused about the possibilities as I am.

    Opinion, Geek, Ideas

  • older posts

Categories

Toys, Guides, Opinion, Geek, Non-geek, Development, Design, CSS, JS, Open-source Ideas, Cartoons, Photos

Shop

Colourful clothes for colourful kids

I'm currently reading

Projects

  • Awsm Street – Kid's clothing
  • Stickture
  • Explanating
  • Open Source Snacks
  • My life in sans-serif
  • My life in monospace
Simon Madine (thingsinjars)

@thingsinjars.com

Hi, I’m Simon Madine and I make music, write books and code.

I’m the Engineering Lead for komment.

© 2025 Simon Madine