About

Introduction

We really love the web. We enjoy creating, testing and experimenting with applications in all forms. We truly believe that in a not so distant future, the browser will play a huge role in how people use the internet - and we want to be a part of shaping that future.

We firmly stand by the idea of an open and secure internet that should benefit anyone interested in using it. Lobbying, surveillance, tracking, censorship and "fast lanes" are something we absolutely despise and are actively working against such online practices;

  • We are actively engaging in the latest encryption technologies to secure all traffic and stored data that can be connected to a users' private information.
  • Our choices of datacenter & ISPs for our server infrastructure align closely with our own opinions and beliefs, and they as well are actively working against above listed practices.
  • We propse different business models supposed to rival these online Ad solutions that practice user tracking & metadata collection.
  • Central points is always a candidate for failures, which is why we try to apply peer-to-peer technologies for applications that either should use or need to use peer-to-peer technologies.

Customers

Throughout our years in Web Development we've worked together with ABB, Coca-Cola, Fotografiska, LIDL, Viking Line, JM and many more.

Technical Overview

Below you can read more in-depth about our technology and stacks.

Single Page Applications (SPAs)

We are almost always building SPAs as they are not only very resource efficient but also very performant. We use different frameworks depending on focus. A SPA isn't always what it sounds like, you can still have multiple pages and routes but a SPA will always have the client render the views. Having the server render every view is resource intensive and you will not be able to support the same amount of traffic on the same hardware as you would with a SPA.The server should however render the first request to decrease loading times.

SPAs are also great for mobile users as the frameworks usually offer a very close native app feeling to a web app, and in this era of mobile users this feature is something greatly appreciated.

Real-time applications

In conjunction with SPAs, we are always aiming to make every dynamic piece of data synchronized in real-time for all users across all devices. In this era there's technology in place to make efficient and performant real-time applications - unfortunately they are still rare to stumple across.

This is something we feel like an important transition into the future of the internet. Should a user really need to refresh in order to recieve updates? We think not - which is why we are pushing it as far as we can when it comes to what data is real-time.

Admin updates prices for a product? Synchronize to all users viewing that product. User liked a post? Synchronize the total like count to all users.

Node.js

Node lets us write Javascript and run it on the server. It is insanely fast at handling I/O and concurrency and is asynchronous just like normal Javascript is. Using Node allows us to write Isomorphic code which means that we can run the exact same code both in the browser and on the server - exactly like Meteor does. Node runs on Google's V8 engine and if you didn't know already, V8 is insanely fast. This makes Javascript - which is a dynamically typed, runtime interpreted language - able to rival compiled languages such as Golang in terms of performance. The best part is that it's only going to get better now that there's a huge community actively contributing to Node.js and V8.

Git

Git is a version control tool that allows for some really nice collaboration on a project.

Do we use Git? Well of course we do. Git is our best buddy that keeps our developers from slicing eachothers throats after one developer accidentally overwrote 2000 lines of another developers code. He's great, probably saved the life of millions of developers already. NaNaNaNaN Gitman!

SASS/SCSS/LESS/Stylus

We use all of these to preprocess our CSS. This allows us to rapidly style our applications and save a lot of time and headaches from vendor prefixes. Our go-to choice is Stylus (with jeet & rupture), but we have worked extensively with all of them. SASS/SCSS takes too long to compile in comparison to Stylus or LESS - unfortunately SASS/SCSS has the biggest community.

Jade

Jade is a HTML templating engine. Although we only use it to rapidly speed up our markup writing process and compile it to HTML before deployment. We don't actually need the engine features of Jade as we already use Angular or Aurelia as our engines.

Grunt/Gulp/Yeoman

We use Grunt and Gulp to speed up our development process and Yeoman to quickly get started by scaffolding our application. These tools drastically decrease the time it takes for us to develop an application.

Vagrant

Vagrant allows us to spin up virtual dev machines that provides us with the required libraries, databases, etc for an application. Vagrant is great as you do not need to install any tools or databases on your dev machine that always starts when you boot it up - keepin' it clean! There are lots of other powerful features to Vagrant but we do however not use it for anything else.

MongoDB

Even though we have extensive experience with SQL-driven RDBMS's, we often use MongoDB. MongoDB is a NoSQL document store that stores data in a schema-less BSON format. These documents looks very much alike an Object in Javascript. The power of MongoDB is that it is very fast, but it is also closely coupled with the language Javascript and its developers. Unfortunately MongoDB had a rough start and you should always choose a database depending on the application, but since the WiredTiger Storage Engine was implemented things have only been getting better and better.

Another great feature of MongoDB is its GridFS filesystem implementation. For example you can save a 100,000 lines long Excel-file to GridFS. If you then need to get the first 2,000 items in the file you can read the first few chunks of the file and only process that. This allows for some great efficiency and performance tweaking. GridFS also takes away all the hassles of scaling a filesystem as MongoDB takes care of that for you. MongoDB also has support for Geographical data, which is a neat feature if you want to make a Tinder clone.

Graph databases

Graph databases are the successors of tranditional RDBMS's like MySQL or PostgreSQL. They are built to handle massive relations between data without it adding any overhead to the requests. Whether your data has 5 relations or 5000 relations, the time for response scales linearly, while JOINs in SQL adds a lot of extra overhead to the request for each additional JOIN you make. If you find yourself doing many JOINs, you should start looking into graph databases. We like ArangoDB as it's a hybrid graph database.

Redis

In terms of performance, Redis would be a hypernova - wait no, scrap that, it would be the Big Bang itself. I'm not joking, Redis is disgustingly fast and can handle hundreds of thousands of writes per second and its response time is in the microseconds range. It's hard to grasp just how fast Redis really is. Every single piece of real-time updates happening on Stackoverflow is backed by a single Redis instance and they're not even close to having to scale yet. That in itself shows just how powerful Redis really is.

Redis is an in-memory key:value store offering pub/sub capabilities. This means that Redis stores all its data directly in the RAM of its host and can notify any and every connected client that any data has changed in real-time. Redis is primarily used for messaging, caching and real-time communications and the only downside it has is that the data you want to store must be able to fit in memory.