Web releases
The latest and greatest on the web
The latest and greatest on the web
16 Dec 2021
TLDR: We want to improve the developer experience, more platforms should use the BFF, testing should be fast and fun, users should be able to download multiple files, and responsive content should be responsive!
Table of contents:

A week ago, we at the web team received the great news that Android had come pretty far with the work on the new home view… but with a twist.
They were using the old Kivra core endpoints.
So a meeting was scheduled, and we decided that we’d try to get the BFF up in a hosted testing environment so that Android could swap out the data fetching from Kivra core to the new BFF. Said and done, after doing some changes to the schema of the home view, we had a small sync and after that, the BFF was (kind of) live.
Joel and Björn did a great job switching out the code in order for getting the home view to fetch data from the BFF. We learned things, and some of which means that we’ll reiterate pain points or concerns about the current BFF. This will help us with our goal to deliver both a great developer experience but also future proofing (code wise) as much as possible.
The home view is no where near done, we still have things to implement on the BFF, we still need to introduce the iOS app to it. But the way forward is trying, failing, learning and fixing.
This way we will keep our momentum and also be able to release the best possible solution to our end users.
So we have introduced Kevin and Kasper (from Post) to the BFF, which they use to serve data for the sender pages. This is super exciting for us, since one of the goals of the BFF is to enable other teams to add the logic they need.
But, the BFF is still in it’s early days which means it has rough spots, and developer experience can for sure be improved in places. So we believe that we can absorb some learnings from their experiences working with the project.
But we have a few action points already in regards to the developer experience.
Thanks for asking. It is going good.
We still have some work to do, but now we are really starting to see light in the end of the tunnel. There are still some hurdles we need to get past though.
One major part that is left is the deployment pipeline which we are getting help from Christoffer from Infra in order to solve. This week we got an introduction to how we can be able to work with Terraform to get our deployments out there in different environments.
Terraform seems to be simplifying this process a lot, and we are looking forward to getting the last bits and pieces together in order to have this task moved to done in JIRA.
Otherwise, we are also looking into adding some more functionality to the BFF before the release, having a large design review, manual testing and all that.
We have been trying out a new testing library called Playwright in the inbox. We currently use a library called Cypress, we have however been feeling for quite some time now, that we need to try something new.
At the moment we have around 100 Cypress tests in the inbox. These have been helping us a lot, catching errors and giving us a sense of safety when developing new stuff. Unfortunately, running these 100 Cypress tests is very time consuming, since we cannot run them in parallel with each other. Since we are now developing receipts on the web, we felt that this is a great opportunity to start over and try something else.
This sprint, we have been writing tests for the receipts in the inbox with Playwright. So far, we are liking it a lot, Playwright gives us the opportunity to run tests in parallel, improving the speed tremendously. It also has great support for typescript, and it ships with a great debugger tool which helps a lot during the development of tests. It feels great to be starting fresh, and over time we are thinking about replacing all of our Cypress tests with Playwright.
Playwright also make it possible to run our test in browsers on a completely separate machine, meaning we can execute the test locally but in a browser on a remote server. This will give us more predictable test cases. The future is bright.
So, what was the issue?
If a content contained multiple files, only the first one was made available for download/print. This resulted in numerous questions to support from confused users wondering about missing files.
To remedy the situation for our users and better align with iOS and Android behaviour we decided to bring back the files dialog. When a content contains more than one file, the user will now be given the option to pick which files to be downloaded.
And what about printing?
When printing files, just like download, only the first file was picked. This behaviour has now changed to always include all files when printing, with a small caveat (applies to both download and print):
If the content has at least one pdf file, we will make all occurrences of pdf:s available for download/print and hide all other files.
If there are no pdf files we will pick all other files
Response content is great! This makes it possible for senders to have more response content than pdfs. But we only support one language and one theme. That is not really responsive, is it? And it is not very accessible.
We have now looked into supporting more themes and languages. This is still work in progress, but it looks great.
And then there is the holidays coming up.
See you next year.