Table of contents:

1. 💃🕺 Ongoing recruitment
2. ⚡️ BFF: Improving on our developer experience
3. 🏠 BFF: Short update on Home view from BFF side of things
4. 🚀 The BFF is ready to take of
5. 🪀 Toybox is now installable
6. ✨ Last but not least

💃🕺 Ongoing recruitment

We’re currently scouting for new frontend developers out there in the wild. And we’ve been trying out new formats on how we want to do it.

So we created a new mini project case for screening an applicant’s React knowledge. The project has built in bugs and intentionally bad code in places. Basically it’s a collection of Pokemons that you’re fetching from a backend server and that you can favorite/unfavorite.

The project also comes with three more or less realistic tasks that the applicant will have to solve:

• TICKET-01 (Bug): Nothing happens when a User presses “Add to favorite”.
• TICKET-02 (Feature): As a user I want to be able to filter by favorites.
• TICKET-03 (Potential bug): QA says if they double-click on “Add to favorite” it doesn’t really work well.

The project should not take more than a couple of hours to solve, and the applicant can freely change design or whatever they want which means that they have space to be inventive and showcase their skills in whatever way they see fit.

But that is the easy part, then have we prepared some tricky questions for which there is no single correct answer to. These questions give us a way to see how the candidate reasons about problems in general, and the ability to divide problems in order to conquer them.

⚡️ Improving on our developer experience

The BFF project is still pretty young and our developer experience is still improving. Back in the days (like a month ago or so) we had to write several commands to even get the server to run. It wasn’t uncommon to see this:

$ npm install
✅ Installed packages
$ npm run setup
✅ Fetched copy and generated types from GraphQL schema
$ npm run build
✅ Compiles the Typescript files into Javascript
$ npm run start

Not too shabby. But this was on a good day. And then lets say you made a change in the code.

Depending on what you changed you would have to run either the npm run setup or npm run build (or both, but in the correct order). And if you did npm run setup you would definitely need to run npm run build.

And if you forgot to run that extra npm run build, you’d be scratching your head as to why the server wasn’t behaving as it should 🤔.

And then imposter syndrome kicks in…

But it’s really the fault of the development setup.

These type of implicit rules shouldn’t be put on you as a developer, it should be well hidden from you, and you should be able to live in harmony.

To add some extra complexity to this, us devs really enjoy not having to rebuild and restart our servers while developing. So we wanted some watch mode for rebuilding and restarting the BFF as we’re making changes in the files.

One* command to rule them all 💍

So we started to look into how we could make this even simpler. And there are steps we really can’t get rid of.

• Installing dependencies with npm install
• Building the project with npm run build
• Starting the server with npm run start

So we ended up keeping these three commands. But what was previously done in npm run setup is now done in npm run build. This was made possible by having a rock solid build pipeline when running npm run build.

The build pipeline ensures that packages are being built in the correct order, so that what we had to do in setup before is built before the packages that depend on the setup. If that makes sense.

As for the watch mode that we talked about before. We’re able to bundle both npm run build and npm run start in that command, which is npm run watch:goomba.

The watch will automagically rebuild the package that consists of the file that you just changed. Then it will rebuild the packages that depends on the packages that was just rebuilt. And then it causes a chain reaction until everything is successfully built.

And then server is restarted.

To top things off, we added this cute little message instructing you on how to debug your application.

... previous build logs ⬆️ ...

[watch:goomba-server]
[watch:goomba-server] -------------------------------------------------------------------------------------
[watch:goomba-server] 🐞 Want to use a debugger? Attach it to PID: 85417
[watch:goomba-server]    Read more about it here: https://github.com/kivra/tf-web-goomba#-using-a-debugger
[watch:goomba-server] -------------------------------------------------------------------------------------
[watch:goomba-server]
[watch:goomba-server] {"level":30,"time":1642671612626,"pid":85417,"hostname":"some-nice-hostname","msg":"Server listening at http://0.0.0.0:3001"}
[watch:goomba-server] 🌎 http://localhost:3001/graphql

But why?

We really do believe that the less we need to use our heads to remember these tedious build steps and all that jazz 🎷, the more we can spend our energy and time where it matters 💚

🏠 Home sweet home view

We’re currently iterating the GraphQL schema with the Android team. Right now we’re supporting fetching user-specific senders, navigation and marketing communication cards.

During this sprint we tried going from fetching data with a view based approach:

{
  homeView {
    senders {
      # sender data
    }

    navigation {
      # navigation data
    }

    communicationCards {
      # card data
    }
  }
}

To this more normalized data centric way of structuring things.

{
  senders {
    # sender data
  }

  navigation {
    # navigation data
  }

  communicationCards {
    # card data
  }
}

This we are certain is more scalable, but comes with a cost compared to the view based approach. In the view based approach we were able to also include contextial copy such as titles. Whereas if we don’t know on what view something is used (approach just above), we cannot for certain provide copy since we don’t know for what context the data is fetched.

Our hope is to lock down the schema continue the work towards creating the home view.

But since it’s a new playing field with BFF:s and GraphQL we want to try and achieve the best possible solution.

🚀 The BFF is ready to take off

A big shout out to the infra team and especially Christoffer and Daniel who have been working hard on getting the infra-parts ready for the BFF 🙏🏻

It is now possible to deploy the BFF from github. For every new version that we produce (automatically through conventional commits) a new PR is automatically created and we can at any time deploy it to production from github. No other setup is needed 🎉

We have two pieces of the puzzle left:

1. Get OK on this KSM
2. Send our logs to Splunk

🪀 Toybox is now installable

Toybox is our custom made application to visualize our components. It is now possible to install that web application and use it in multiple places. You may ask why we want to do this? – uicomponents.kivra.com is our place for our shared components but we have also a lot of custom components in our different webb apps. For example, a qr-code component that is only used in accounts (the login portal) or Tink views that are only visible in the payment flow. It has been hard to develop these components in an isolated way. But not anymore with Toybox 🎉

✨ Last but not least

🎉 New features

• We now have more logs in the BFF, for example on slow requests and on retries.
• We now calculate the cost of GraphQL queries and block them if they are too expensive 💰. We also block deeply nested queries.
• We now get warnings for PR:s when making breaking changes on the GraphQL schema. We also get a detailed list of non-breaking changes.
• Working on removing all dependencies to Material UI (an external component library).

🐞 Bug fixes

• It is now possible to pay via a shared mailbox.
• Some users experienced issues when trying to print html content, that should be solved now.
• Search for receipts did not work for some time. It is now up and running again.
• Added a lot of payments methods for recipts.