TLDR: The web team created a new ui component library. The previous one used a tool called Storybook, which got slow overtime. New one is called Ui Components and it’s blazing fast! Work with receipts is going well, and we’re still working out how the BFF (which is the backbone of receipts for the web) should work. If you just want to see some demo of receipts, we got you covered below.

Table of contents:

1. We built our own component library solution – and saved minutes in build time!
   1. History
   2. Implementation
   3. Moving forward
2. BFF + Mockserver = Receipts on the web
   1. What is a BFF
   2. Mockserver
   3. How we built our BFF
   4. Receipts demo
   5. Future of BFF

We built our own component library solution – and saved minutes in build time!

History

The web team has a component library called react-components, a project for showcasing and testing our reusable components used in our web apps. By having separated components, it’s much easier for our different teams to reuse them, and we don’t have to re-write the same code in every project.

Implementation

The previous implementation of our ui component library was using a tool called Storybook. Storybook is a UI component explorer for frontend developers which helps devs with testing and showcasing components in isolation. So why did we move away from it and created our own?

Storybook is a great tool, used by many developers. But unfortunately, over time it became very slow. Starting the project locally could sometimes take minutes and build times were even worse. It was also very limiting when it came to functionality.

– We felt that this needed to change, since this project is such a central part of our daily work.

That’s why uicomponents.kivra.com was created. It essentially works just the same as with Storybook. But now we have more control over what we can do with it, and it only takes about a second to fire up. It has made our daily work tremendously faster, and we are very happy with how it turned out.

Moving forward

What’s next for uicomponents? We now have a good foundation to stand on moving forward, and some things we are planning to integrate into uicomponents in the future are:

🟢 Accessibility (a11y)

We are constantly improving our inclusiveness, and a11y has a big part in that. So we are discussing how to better inweave the showcasing of how every component is implemented with a11y. Regular do’s and don’ts help our developers think about it and make it a more natural and straightforward part of our daily work.

🖼️ Showcase component in a bigger scenario (not just isolated by itself)

Showcasing a component in a bigger scenario, would mean that we could for example, easily showcase how a button would look in a context other than with just a white background, for example: A button in the context of a form, or a button in the context of a menu.

BFF + Mockserver = Receipts on the web ❤️

While starting with (maybe) the biggest feature called receipts, we also decided to add some spice by introducing a little thing called Goomba, which is our new BFF.

What is a BFF?

So, what is a BFF? BFF stands for backend for frontend, which in simple terms means a service that helps the frontend. A thing that is very common for frontends is that they are using some sort of http-API, but the data retrieved needs some sort of transformation before reaching the end user.

The idea of the BFF is to sit between the frontends and the backend and prepare raw data to be used by the different frontends.

As it is today our different apps (iOS, Android and Web) all consume data directly from our backend. This means that if we want to do some sort of transformation of the data (which we almost always do) we need to write the same logic in three different places. Let’s also say that the requirement for the logic changes a couple of months later, then all three frontends need to make that change. If not… we’ll have different behaviors for the same feature depending on what client you’re on. (whoopsie)

So this leads us to one of the biggest pros of having a BFF, we’re able to move logic from the frontends to the BFF and that way make sure that we have a consistent behavior for all our clients.

And we’d only need to write that logic once.

Which means less hours spent writing the same code in different clients, and more time for shipping new great features.

We’ve chosen to use GraphQL as the query language that you use when asking the BFF for data. GraphQL is strongly typed, and we have to define exactly how the data that you ask for will look like.

# An example of a type in GraphQL

type ProductListItem implements BaseListItem {
  type: ListItemType!
  """
  Name of the product
  """
  name: String!
  """
  Cost of the product
  """
  cost: String!
  """
  Displays a string which gives information about the quantity (i.e. "2 st * 24 kr/st")
  """
  quantity: String
  """
  Cost modifiers gives information about added or subtracted costs on this item.
  For an example: If you buy 2 mozzarellas the store subtracts 10 SEK on the cost for them.
  """
  costModifiers: [ProductCostModifier!]!
  """
  Deposits like PANT
  """
  deposits: [ProductDeposit!]!
}

Hint: The exclamation mark means that the type is required, so you can count on it being there. For an example cost: String! means that the cost is a string (like 12,50 kr) and you can count on it always being there

This means some extra work for the people building the BFF since we really need to reason about how we want the data to look like, but there’s a lot of pros with this.

• When you’re using the BFF you can be sure how the data will look like.
• We can easily generate code in the clients that helps us with grabbing data, types and all that sweet stuff.
• And since we have a strict contract of how the data should look like when leaving the BFF, we can easily create mock data for testing and during development.

You can read more about the BFF project here: https://github.com/kivra/backend-for-frontend

There’s a new mock server in town!

As you may or may not know, there is an existing mock server where we are mocking Kivra Core and other external services like BankID, Tink, Creditsafe and more. This makes it possible to easily set up test scenarios and create automatically acceptance tests. And it has been a fantastic service that we still use every day. However, since we want it to act like Kivra Core we also need to implement some quirks that exist in Kivra Core and think of all edge cases.

With the BFF we only need to implement the static GraphQL schema that’s being used by the clients. In the new mock server, the data will no longer come from Kivra Core or any other BE service, but instead a local database in the BFF.

This means that it will be a lot easier to maintain and develop the new mock server for BFF than its predecessor where we had to try to imitate the behavior and data structures of Kivra Core.

The mock version is a completely different service so the code can/will never be used in production.

The frontend (iOS, Android, Web) has a contract with the BFF, and the BFF has a contract with underlying services. This means as long as the BFF fulfills the contract to the frontend, the frontend can use the mock version of the BFF to quickly set up test cases or use it in automated tests (it can run in a Github action).

So that’s what we did, we created a whole new mock server that you can add users, chains and stores as well as custom receipts with.

Although it’s very efficient to work with mocks during development, you should always test in sandbox and even production to make sure that things ACTUALLY work properly.

So… you want some insight on how we built the BFF?

The BFF (Goomba) is written in typescript, and running on Node.js. It will be hosted on GCP, in a cloud run.

It’s demo time!

Let’s look at what might be coming up…

• Get the last parts sorted with the BFF and the mock server, and then release receipts.
• For the web Inbox we’re hoping to move a lot of the business logic that currently reside in the Inbox project to the BFF. So, basically we’re hoping to move as much as possible to the BFF.
• In collaboration with the Discovery team, we’re gonna develop support for the new Home view in the BFF.
• We’re hoping to introduce other clients to our BFF.
• I heard a rumor that a chat bot may or may not be moving into the BFF.