Overview

What is Gesso?

Our primary accelerator. An accelerator is a pre-built framework that gives us a mature foundation and architecture for rapidly building complex, websites and applications. You will hear accelerators being used more generically for anything kind of around business and operations: model templates, starting points, anything to accelerate you getting to whatever you're trying to build faster. Gesso specifically is built decoupled.

What is decoupled?

The Gesso framework is decoupled, meaning the main parts of the system are separate but work together to create the final product. See: this beautiful diagram here.

Is headless the same as decoupled?

No, but you often hear those terms used interchangeably. “Coupled” systems have a back end and front end that are intertwined. Decoupled systems can choose their front end, or “head.” If something is headless, the system has no head whatsoever: it would have to come from a different provider. In our case, with Drupal, Drupal does have a head but we're choosing not to use it. A headless provider would just be one (optional) part of a decoupled system.

See more: https://www.contentful.com/blog/difference-between-headless-decoupled-contentful/

Design System

What is a design system?

A design system is a set of standards to manage design at scale [using reusable components and patterns] by reducing redundancy while creating a shared language and visual consistency across different pages and channels.

It’s our single universal library. For design tokens: they're the smallest elements of design. So like colors typography, spacing, radii, shadows, etc. By themselves, these tokens don’t do anything. They're used to Build or construct components. Which is the next part of the a design system: it has these ready to use pre-built user interface components and tokens. Many of them are highly configurable, so, You know, we don't have just one button, we have a whole bunch of different options that you can toggle on and off (also called “properties” or “props”) to have all sorts of different looking buttons, different size buttons for different specific applications, etc. And one of the great things is everything's thoroughly tech tested. Everything's documented and we've got responsive elements built into them. They're accessible, etc. We're able to use the same components and tokens right within Figma to do started to do prototypes. So it gives us a really great consistent design language when we talk. Like, when we talk about, what things are called, what properties are called, they're the same across the board, whether you’re a designer a front end guy, or a software developer.

How is our design system built?

Figma + Storybook + React Front end

Figma

Figma is basically the source of where design system tokens live. It is a highly collaborative rapid prototyping and user interface design tool. Applications such as Adobe XD, or Sketch are similar tools. 

We chose Figma for a number of reasons. First was to find a tool that we could add to our design system pipeline allowing us to update ‘tokens’ in a design file that would be reflected in a live build of the project. Secondly, Figma is a powerful prototyping and design tool, allowing as much or as little team collaboration as needed. 

Read More: https://acromedia.atlassian.net/wiki/spaces/GESSO/pages/edit-v2/277446778#

Storybook

Storybook is a tool that allows Designers and try and developers and software guys to all go and look at the actual components and see the documentation and see all the configure configurations and props, etc.

Storybook is an open source tool for building UI components and pages. It streamlines UI development, testing, and documentation. It's a tool that allows both management and developers to see individual components within a design system and outlines clear documentation on how they are to be used.

Storybook is an open source tool for building UI components and partial layouts in isolation. It streamlines UI development, testing, and documentation.

Storybook is the ‘realization’ of the conversation between UI/UX and front end developers. Questions like “how does this work / behave?”, “In what kind of contexts will this be in?”, “how does it look / behave on mobile devices?” can all be answered and demonstrated by using Storybook.

A UX/UI designer will commonly have a ‘vision’ for interactivity and how something is planned to work. Storybook can help realize this vision, and solidify a component’s evolution from just a graphical representation to a piece of living, malleable piece of interactive software.

More here.

Middleware / APIs

A mediation layer primarily facilitates communication across different services. In other words, the mediation layer makes the services independent of each other so that even if a particular service is replaced or removed, the other services can seamlessly interact with new services. The mediation layer acts as an interpreter between different technologies and protocols.

Though we will be using as one of our back-end options, we are not locking in to Drupal in a decoupled system. So from a content or data perspective, everything stays the same, we're still using it as a CMS. It's still the back end where admins are going to interface, they're gonna add content, they're gonna control users, everything that they would do normally So it still has a UI. The only difference here is the UI is specifically for the admins customers or users of the website would not be interacting with the backend UI. In this case, All the data is exposed to APIs, so that's how the front end is going to be collecting its data to populate content, you know, authenticate users, that sort of thing. Like I said, it's not and User-facing. The customers are users would never see this part of the site. And we're using Drupal as the default platform though. Like I said, it could be swapped out for other APIs or part of it could use other APIs, that sort of thing. We're not tied to any specific platform.

Data fetching

Data fetching allows us to render content in different ways, depending on the application's use case. These include pre-rendering with server side rendering (SSR) or static generation (SSG), and updating or creating content at runtime with incremental static regeneration (ISR).

The content is up to date because it is fetched on the go.

The website loads quickly because the browser fetches content from the server before rendering it for the user.

Because the JavaScript is rendered server-side, the user’s device has little bearing on the loading time of the page, making for better performance.

Front End

The visual layer. This is the end user facing portion of the website. So this is what your customers are users, would interact with it. Implements the design system so your front end is built based on all the components pulled from the design system. There's sort of our building blocks to creating the front, end it connects to the backend via that API that I discussed earlier. So all the data that it needs is pulled from Drupal or the back end API. And our default technology for building this would be react.

Gesso Architecture

An overview of the Gesso Architecture can be found at architecture.gesso.acrocommerce.com or by clicking "Architecture" in the header right hand side.