#kivralabs

Hello, Internet! It's Kivra Labs.

We work with two types of customers at Kivra. The first is our partners who send in their content to communicate with their customers (end users) (like, Skatteverket) and the other are the end users themselves. Our success has been built on being able to understand both types, be able to solve problems for both, and know how to get them to like talking to each other. :)

The Use Case

A prevalent example is our partners wanting to redirect end-users from a content in their Kivra inbox, straight into the partners' system. An example is an insurance company wants to communicate something important to the end user and prompt them to check their current policy on their system.

The prompt is achieved by our Active Content in the Kivra product. The Active Content is our take on an embedded iframe that is included with the partner's content. So, when the end user logs into Kivra to read the communication from the partner, they will see the Active Content above the content item.

So, to summarize, our partner wants the user to log into Kivra, read the content item, click on the link in the Active Content, and then be able to look at their current policy on the insurance company's website.

In order for this to work, the authenticated user needs to be able to transferred to the sender's system, authenticated, and then logged into the system, without the user having to re-login or be asked to re-authenticate.

The authenticated user on Kivra clicks the button in the Active Content.

The user is sent automatically to the sender's system.

Their credentials are verified.

They are logged into the sender's system.

The process is seamless for the user. The real fun is under the hood, tinkering in the engine of the technical solution.

The Solution

We used SAML2 to implement the use case.

Final Thoughts

Apart from the usual teething problems and tweaks, this solution proved really successful for us. Our partners have seen its value and we're now getting more requests to implement this on a wider scale.

Hello, Internet! It’s Kivra Labs.

We're going to start to dig into some technology this week.

The frontend development team at Kivra is 8-person strong and has a really great mix of skills. Our work is driven by great, informal discussions (on Slack and IRL), commitment to understanding the needs that come from the product team, and then translating those needs into great features that we build. We believe in first make it work, then make it pretty, then make it fast.

We treat all our applications as a microcosm of microservices, designed to communicate with each other and remain as autonomous as possible. This makes for sleeker and easier management and maintenance.

Here's a quick run-through of our project and build architecture!

Most of our recent projects are built on Angular 1.4 or 1.5, some of our older ones were built on 1.2. We're porting slowly our architecture to a component-based one and trying to slurp up every last drop of the ES6 juice.

Like most JavaScript projects online today, modular dependencies are defined and managed with npm's package.json file.

We've used Grunt in older projects, newer ones Gulp, and most recently, we're going all-out 2017 by leveraging webpack.

Jasmine is our unit testing tool of choice.

GitHub is our source control system. Can there be any other?!

We have post-commit hooks wired into Slack so that our channels receive notifications of commits, new pull requests, or when comments are posted on GitHub.

A custom bash script lies in our repos that triggers an automated build on BuildKite upon a commit to an active branch and of course, the hallowed master branch.

We are heavy users of Docker images and containers. When changes are to deployed live, we run an Ansible playbook that runs a git pull on latest master and shoots it up to a Docker image on our production environment.

Finally, our projects are happily married to Sentry and PagerDuty to help us track, in real-time, errors and raise alarms for the person assigned to operations duty. (More about that in a future post!)

How do your frontend architectures look? Let us know on Twitter or here!