Imagine if you could easily communicate with anyone in the world, even if you didn´t share a common language! From a web development point of view, that is one of the problems Web APIs aim to solve.


An API acts as an interpreter between two different systems or applications, for example a website and a server. What if you needed some complex work done, let´s say an advanced electronics installation. In general, it is usually much quicker and easier to simply pick up the phone and call an electrician, rather than to get the education you would need to do the work yourself.

That is another thing APIs do; they let you make that phone call (request) to the electrician (server), who then do that complex work they are trained (programmed) to do and finally responds back to you when the work is done. As with the case of the electrician, it is often quicker and/or safer to let the servers code handle some logic and functionality. Especially since such resources, if located on a server, can be shared between multiple websites and applications. But remember, you most likely wouldn´t call an electrician to change a broken light bulb.

Another example would be if you walked into a restaurant and, instead of a menu, you were handed a list of all the ingredients the kitchen had to offer. And you would have to specify which ingredients the chef should use and exactly how to prepare them. This is yet another problem an API solves; it takes a lot of ingredients (functions and content) and packages them in a way that is easy to use – like a menu of the functionality the server provides. You don’t have to know exactly what is there and how it works, you only need to know how to ask for what you want. In more general terms an API (acronym for Application Programming Interface) is used to let one system, application or website communicate with another system, without really knowing – or caring – how that other system works. A Web API is an API used by a server to make it easy for websites to talk to the server.

A practical example

So, now when we have a rough idea of what an API is, let's see how we can use it in an application.

Let´s say you are building a website and want to add some information or functionality that would be quite time consuming to add on your own. Or maybe you want to save some information in a way which lets you get it again from some other place or device. That is when you would use an API.

Instead of having to manually add a lot of information that is already available somewhere else or figuring out complex logic or functionality that someone else has already written, you can reuse those existing resources.

You do this by making a request to an API. Which API to use and what resources you want from it is specified with an URL, just like when you are navigating to a web page. (Sometimes you will also have to send data with your request, for example when you want to save some information to a server. But for now, let us focus on the URL.)

The API receives your request, asks the server for the information you requested and then responds back to you with that information packaged in a somewhat readable way

In our example code we use an open API (open APIs are free for anyone to use, it is good to know that many APIs are not publicly available) found at, which is the first part in our request URL. We then specify what resources we want the API to respond with by adding to that URL. Here we are asking the API for /people and we also specify that we want a single, specific entry from the list of people (that is our random number). So, our full request URL could be, change the number 3 to another number to get another entry. Once we have sent our request to the API, we wait for it to respond back with the requested data. And upon receiving the APIs response we process that data and display it in a readable way on our webpage.

Check out the full example and try it on CodePen.

What more can you do with an API?

So now you can also go ahead and try to fetch other data from the Star Wars API. You can use the following URLs to fetch:

  • Planets: get all or one number 1-61)
  • Starships: get all or one number 1-37)
  • Films: all or one number 1-7)

There are other famous API’s that you can use to fetch data for your projects. Here are just some of them:


Makes requests to Twitter for specific data, e.g. the users home timeline or their own statuses, or a request to post a tweet for a specific user. Example: One use would be to show tweets and notifications in real time in your application.


There are a few Facebook API but the Graph API is primary way for apps to read and write from/to Facebook. With this API you can access pages, users, posts, groups, events and more. Example: Write to your own Facebook wall or list your Facebook friends from within you application.

Google Maps

A basic use case of the Google Maps API is plotting places, such as local search results, as markers on a map. You might also add paths for multiple points. More advanced usage creates interactions between frontend code and the map – for example, click a search result and highlight the place on the map. Example: Render a simple google map in your application


You can use the YouTube API to retrieve and manipulate YouTube resources like videos, channels, and playlists. Example: Let the users watch YouTube videos in your application.


NASAs API provides some incredible data, including its spectacular imagery, data about near asteroids, images made by the Rover vehicle. Example: Display NASAs photo of the day on your website or application.

Yahoo weather

Returns basic weather information such as current conditions, current temperature and forecasts. Example: A simple weather app that fetches daily weather forecast


In most cases you will be asked to perform authorisation or authentication before you can use the API. First, a short definition of terms:

  •  Authentication: Proving correct identity 
  • API Key: A long string that you include in the request as a way to identify yourself (authenticating you to use the API)
  • Authorisation: Allowing a certain action (ex. allowing you to fetch the data)

Authentication and authorisation is used mainly for security reasons, but also to keep track who is using the API. The owners of the API need to make sure that:

  • Users can not make unlimited amounts of API calls without any kind of registration
  • The wrong person could intercept or access private information and steal it
  • Track who is making the requests, and for what purpose are the APIs used

Always check the APIs documentation for the authorisation process. APIs have usually good step by step instructions.


APIs It is also important to know that some APIs can be free of charge or you will need to pay for their usage. Most common cases is where the API creators provides a freemium version with limited usage (for ex. number of API calls in a period of time) and a premium plan with unlimited usage and possibilities for developers to access more functionalities.

Bodil, Sandra & Frida



dotCSS and dotJS in Paris

Last week a couple of us took a trip to Paris for a few days to visit the annual dotCSS and dotJS conferences.We took an early flight from Visby to Arlanda. After an hour or two and a good chat it was time for our next flight that took us to Charles De Gaulle (one of the largest airports in Europe).After we finally arrived at the hotel we went out to find some food and see the city, and WOW, what an amazing city it is! People everywhere still sitting outside, enjoying a glass of champagne or wine. We took an early night to prepare ourselves for our next day which would be full of energy and of course CSS!


Many of the talks were good. We got to hear much about CSS Grid; a new technique to layout your web app with just semantic elements and no (less) need of wrapping container elements.

We also got to talk to Google representatives and they helped us perform a Lighthouse test off our site ( Basically Lighthouse is a tool for developers which is used to see what improvements could be made on a website to improve performance, accessibility and loads of more (Side note: we had a pretty good score!).


The next (and last) day of the conference, it was time for a full day of just JavaScript. Lovely! The hype was up and we had big expectations.

Wes Bos (teacher) was the first speaker out and he did a really great talk on async/await and the different ways to handle errors. We especially liked the clean way he proposed to handle errors with higher order functions.

Several other great talks were made that day, but to mention a few there was Adrian Holovaty (Co-creator of Django), who held a talk of how exhaustive it can be to maintain an open source framework, the less need of frameworks and how we need to start thinking for ourselves again.

We also got to listen to Brendan Eich, the inventor of JavaScript. Now how cool isn’t that? He was the final speaker of the conference and mentioned some key points of JavaScripts history and what’s coming to the language.

The conference ended with an party where we got to drink some locally produced beer, mingle with other attendees, speakers and staff.

To sum these day up; it was a great trip, we learned a lot and we met a lot of interesting people.

Mathias & Timmy

Hackathon team two

Planning and startup
Team two was off to a slow start because the team was in disarray due to an unexpected loss and subsequent addition of a new team member. But the addition of Johan added much needed inspiration and the team got of to a late but quick start when the team gathered on Wednesday for a brainstorming. We decided on making some kind of physical interaction with an online gaming experience. Since no-one came up with a really good idea we could unite about we left with a set goal that we should each think about it overnight. A couple of hours later Åman exited the team as abruptly as he entered, but not before he purchased the necessary equipment during the evening.

Purchased hardware

Late in the evening Mats built a frame for the range sensors with some leftover pieces of wood from an old sauna.

Day One 
The remnants of the team gathered at Toftagården in the early hours of Thursday september eight in a room called Lilla salen(Small ward). Luckily the room did not live up to its name since it actually was quite spacious. During the first hour of the day we focused on getting the Arduino micro-controller working and setting up the development tools which was easier than expected. Meanwhile we discussed what we should do with the Arduino. We settled on making an physical interaction with the Triss product using distance sensors connected to the Arduino. Mats and Kristofer worked on getting the range sensors working with the Arduino and getting the measured values to the computer via serial communication. Meanwhile Bodil worked on the ability to interact with the scratch-code in the triss from an external data source. Philip and Andreas began writing their own implementation of the Triss as a backup if the original triss code was deemed to complicated to interact with.

Since the sensors did only have a 15 degree measuring angle we could not use the wooden frame since the virtual scratch-area would have been less than a square of 8 by 8 centimeters. So instead we mounted the sensors opposite each other so we could control x-axis and y-axis with a hand on each side of the controller.

Day one evening 

Kristofer got the code working to send data from the Arduino via node.js to a webpage using He also added a LED to each range sensor so we could visualise the interaction with the range sensor. Bodil got interaction with the triss working and the Philip-Andreas triss was also up and running. There was a serious incident with a beer bottle and the Arduino late in the evening, but luck was with us and disaster was avoided in the last micro-second.

Day two 
Kristofer continued with his audio-visualisation by adding an audio component to the range sensors for improved WOW-effect. Many R2-D2-like sounds were heard in the room while he tweaked the audio with relentless vigour. There were mixed feelings from some other teams and there was actually a WTF exclaimed by a competitor. Bodil worked on getting data from Kristofers socket server with mixed results. The communication was not as stable as we would have liked.

One of the last problems we had was getting values in the correct range for matching the triss scratch-area. The range sensors didn´t seem to be calibrated so first we had to compensate for the differences. The sensors sometimes delivered values that were not realistic so we had to filter those out to. When we got all the values for the original triss, we continued to get it working for the 30, 40, 90, dubbel and mini variations of triss with the possibility for more variations with four lines of code each. In the nick of time we also got the scratch-tool working by some heroic last effort coding by Bodil.

Watch a Demo

It was quite fun to build something physical and in the end watch the result as a scratching of the Triss online.

/Team 2

WOW! …what ARE we going to do? How to create a WOW-feeling in two days? That was our mission!

We were six developers who started thinking about the task ahead. Ended up being five implementing it. We tried to meet up for a short while every day to come up with some cool and fun ideas. There was no lack of ideas. We were all agreeing on that we would like do something that had to do with Svenska Spel. One of the ideas was to enhance the experience of revealing the numbers of a Triss-board.

Another idea was to “gamificate” the Svenska Spel website with achievements and badges that one could earn by playing a game, reading a news post or by verifying one’s email address, to name a few.

However, we ended up mixing two of our favorite ideas. One about a labyrinth-game (tilting a board with a marble into holes). The other one to change the Huxflux-feature of Lotto (random shuffle of numbers).  The result of these ideas put together was a kind of pool table with 35 balls and when a ball hit the edge of the screen it exploded until only seven remained.

Day 1

We started by delegating tasks to everyone so that we knew what we would do. It was decided before we started that we were going to use the ThreeJS rendering library and CannonJS physics engine. And for the base framework we used create-react-app which helps you get started with building a React application.

Maria and David started with creating the actual board in HTML/CSS and their goal was to make it look like a regular Lotto board. Anthon was tasked with setting up the base framework. Ragnar experimented with ThreeJS rendering and Johan looked into the physics mechanism of the Lotto balls.

Day 2

The second and last day of the Hackathon we had already laid a good foundation so we made the look and feel better in many ways.

Thanks to Johan we got sounds to work in our application. The last thing we managed to add was an animation to lay out all the balls in a row and sort them from lowest to highest.


Device orientation problem

One of the challenges we stumbled upon was the change in orientation of the device so that the balls could roll around on the screen. First, we tried changing the rotation of the actual 3D plane so that the balls would use the gravity to roll down the plane.

However, the problem with this method is that if the user is changing the orientation of the device really fast, the plane could knock the ball out of vision since we worked in 3D space due to changing the planes rotation.

Instead we came up with a method of only changing the gravitation and not the actual plane. This method worked better than the previous one. However, the balls could still roll on top of each other because there was nothing that stopped them, so we added an invisible roof high enough to make the balls able to roll in between the planes.

Sound problem on mobile devices

When we worked on the sound, we noticed that it wasn’t playing on mobile devices, but it worked great on desktop. We learned that this is because mobile devices need user interaction before sound can be played.


ThreeJS comes with a lot of features, including lights and shadows. We aimed for having each ball cast a shadow on the bottom plane from a directional light source. Unfortunately, we could not get it to work so we had to give it up.

/Team 6
Ragnar Petterson, Maria Öberg, David Hansson, Johan Sundberg, Anthon Fredriksson


hackaton team1

Having in mind the ‘WOW’ criteria for this year’s hackathon we immediately went for AR as our main technology. On the few brainstorm meetings we decided to work with the TRISS product and improve the users experience by adding more excitement, involvement and eventually engage the user (who bought a physical ticket) in an online experience.

The idea is pretty simple. After you scratch your physical Triss ticket, you’ll be able to scan a QR-code with an URL that launches the AR-experience. The AR-experience offers an extra chance to win something. Through you mobile or tablet will see a 3D box floating above the TRISS ticket and inside the box is the price. Very exciting, right!

Day 1

We start the day by breaking down the idea to smaller tasks. Setting up environment and start to play with some AR frameworks. A big challenge that takes up a lot of our time is trying to create a custom marker (trigger for the AR experience) for the Triss ticket. There’s a lot of try and error here. We are using three.js which is a 3D library to create the experience. We are starting to build the Svenska Spel logo in 3D. The idea is that it should pop up from the box. We are also adding listeners that listen for a click to launch sequences in the animation so that the box opens when clicking on it.

Day 2

The work with 3D animations continues. Spending a lot of time to get textures on the models. We are realising that we don’t have enough time to get the animation of the logo in place. Quick solution is to put the price on the bottom of the box. By tilting the phone, you are able to see the price you have won.


We’re all feeling a little disappointed that we didn’t manage to do a better and more amazing winning animation but are all satisfied that we managed to get it fully functional for the demo.

We had a lot of fun, experimenting with new frameworks, techniques and just hanging out together as a team.

Team 1: Sandra K, Magnus K, Timmy Y, Tony N, Håkan F, Johan M

Hackathon - Team Dashboard

We arrive at Tofta early in the morning. The sun is shining and the winds are gusting. Perfect weather for a Hackathon event! We step into our designated team room, close the curtains and for two days the entire room is flickering from the blue lights of our computer screens.

Although our team was decimated from six to four members even before the event started, our vision of what to achieve remained the same. To create something that would be functional and useful right of the bat. Something usable by ourselves, the development teams: A multi-screen solution for our soon to be team rooms.

An outward facing display where the visitors can get information about the team and its members, what the team is working on and maybe even leave as message?
Inside each room one or more displays for relevant statistics, system monitoring, team backlog, Kanban board for morning stand-ups and so on.

Each display is operated through a web based control client accessible from any device such as a mobile or computer. Just scan the QR code in the upper righthand corner and use the interface to toggle between different informational views, or to leave us a message.

The outward facing display can be operated using an adjacent 7 inch touch screen powered by a Raspberry Pi. The touch screen runs the same web based control interface mentioned above. A motion sensor detects when anyone is close to the display and sends a Wake command, lighting up the 7 inch control panel.

To "geek things up" even more we added LED-stripes for indicating Welcome/Do not disturb status for visitors and notifying the team of new messages. Any new messages is automatically read up by the inside monitor using the Web Speech Synthesis API. In Swedish of course ;)

Summing upp Hackathon 2017 for our team; Good food, lots of fun. 

Oh, and one more thing..
When the dust settled and the votes were counted, we were proclaimed the winning team!

/Team 5
Reine "10pm refactor master", Mats "the drone pilot", Jimmie "the pixel pusher" and Kotte "the mascot".

After two planning meetings before the hackathon we had September 7-8, we decided to build a web based correcting experience, in AR (Augmented Reality), for our customers who are betting at Lotto at our agents.

To be able to make a correcting experience from a Lotto receipt, we need to scan the receipt’s barcode and have some sort of marker attached to the receipt for our AR animation.
We decided to use quaggaJS as our scanning engine, AR.js with A-FRAME for our AR-experience and jQuery, Node.js and Express.js as base.
No one in our team had any experience with AR on the web so the learning curve was quite steep in the beginning to make the AR experience fit our needs. On a Hackathon, the implementation does not need to be perfect, so some creative programming is allowed and was used.
At Thursday evening, the scanning software was working as expected and AR-animation started to fit our needs. The Friday work was to optimize the complete experience, from scanning the receipt to the big final with the jackpot experience.
To summarize, we are quite happy with our results during the two days and with the WOW-factor we created. The solution is generic and could be used with lots of our games.
The technic we were using is getting mature and it is an enabler to make awesome AR-experience on the web.


Late to work and all stressed up? Rest assured with "Parkify" you would not need to spend your time finding a free parking lot, the web-based app will notify you of where there are free spaces and leave you focused on the driving.

The idea sprung out of a actual need we have at Svenska Spel, the amount of employees have steadily been growing over the last years but the parking lots have not. Around 09:00 all spaces could be occupied, especially on rainy days and during winter. An application signaling where the free spaces are located, if any, could relieve stress and rush traffic during the mornings, an ecological aspect with reduced pollution also comes to mind. As an additional feature, is case all parking lots are occupied and you had to park elsewhere, there is the possibility to get a notification message sent to your mobile phone when a free parking lot becomes available.

The teams approach to solve the problem at hand was to rely on cameras mounted on the rooftop of the building, giving a "bird's-eye view" of the parking lots and the cars. The de facto standard library for image recognition and processing, OpenCV, was used and trained to recognize cars on our parking lot. A Node.js application was then developed that interfaced with OpenCV and analyzing the pictures taken by the camera, all detected cars were then matched with a grid representing the parking lots. The Node.js application also serves a web-based app visualizing the interpreted picture from the cameras and the status of each parking lot, text-to-speech is built into the web app and aids the user with a verbal indication of the number of free lots.

We got everything up and running, except the notification feature which requires a SSL certificate to work. All in all we had a fun time writing this application and for the chance of learning something new.

Team 3: Jonas K, Vladimir K, Henrik Ö, Emil Ö, Issac P, Josip U

mingel på Nordic.js 2016

För tredje året i rad så hölls JavaScript-konferensen Nordic.js i Stockholm den 8-9 September. Denna gång hölls konferensen på Münchenbryggeriet och några av oss på Svenska Spel var givetvis på plats

Årets tema var Wingdings (eller var det katter?) vilket tydligt kunde ses på bl.a. hemsidan,  planscher, och i presentationer, mm. Eventet i sin helhet var välorganiserat och konferenciern Lydia Winters, brand director på Mojang, gjorde ett mycket bra jobb. Alla föredrag strömmades via Viaplay och finns även tillgängliga på YouTube.

Några höjdpunkter som vi tog med oss från konferensen:

Jeremy Keith (Clearleft) - "Resilience: Tried and tested approaches to building robust, flexible, and resilient web experiences."

Jeremy talade om att istället för att gnälla över begränsningar i äldre webbläsare så kan man bygga grundläggande funktionalitet och lägga till features för modernare webbläsare. Att lösa sådant med hjälp av Javascript är alltid riskabelt. Rätt sätt är att utnyttja att HTML och CSS är konstruerade för att vara bakåtkompatibla.

Frans Rosén (Detectify) - "The Smörgåsbord of Web App Hacking"

Frans talade om bug bounties, dvs när företag erbjuder kodare och hackare en belöning för att hitta svagheter i deras tjänster. Det bjöds på härliga historier om svindlande säkerhetshål i välkända tjänster samt dekadenta hackerhelger i Las Vegas där både kod och bubbel flödade.

Ashley Williams (NPM) - "A brief history and mishistory of modularity"

Ashley jobbar på NPM och hjälper utvecklare med frågor som bland annat berör paketering och distribution av moduler till Node.js. Under detta föredrag fokuserade hon kring frågorna, Vad är en modul? Hur stor eller liten bör en modul vara? Vem tjänar på stora/små moduler? Olika fördelar och nackdelar ventileras och varvas med både historia och filosofi, klart värd att se för oss Node.js utvecklare.

Evan You (Vue.js) - "Demystifying Frontend Framework Performance"

Som är grundaren av Vue.js pratade om benchmarking av frontend-ramverk och att det inte alltid är det enklaste. Utan man måste själv prototypa sig fram och bilda sig en egen uppfattning.

Vitaly Friedman (Smashing Magazine) - "Cutting-Edge Responsive Web Design"

Vitalys talk handlade om några små (men användbara!) knep för att bl.a. designa responsiva email, eller hur man på ett smidigt sätt kan skala en fontstorleken utan media-queries!

Lin Clark (Mozilla) - "A Cartoon Guide to Performance in React"

Lin driver hemsidan Code-Cartoons som med enkla streckgubbar illustrerar och förklarar olika ämnen som kan förbrylla den moderna webbutvecklaren. Försöker du ännu förstå hur Redux eller Facebook Flux fungerar? Besök hennes hemsida och se ovanstående Youtube-klipp!

Mattias Petter Johansson (Spotify) - "If you know map, I will teach you monads"

Mattias ledde oss genom functors, map och flatMap mot målet att förklara vad monads är för någonting. På vägen dit fick han även med hur elegant funktionell programmering kan vara,  när man i koden berättar vad man vill göra, inte hur man skall göra det.

Jem Young (Netflix) - "Embracing The Future"

Konferensens sista speaker (och kanske även en av dom bästa). Några av oss missade honom tyvärr då vi var tvungna att åka till Bromma för att ta flyget tillbaka till Visby. Jem höll i alla fall ett riktigt bra talk om JavaScripts framtid och hur man redan idag kan använda den nya tekniken för att bygga grymma applikationer.

David Björklund ( - "Pragmatic performance patterns"

Ögonöppnande och mycket användbart. David berättade om sitt arbetsflöde med benchmarking och varför han vill få in det så tidigt i processen som möjligt. Du kan aldrig veta säkert vad som blir resurs tungt i din kod. ”Prepare to be surprised”.


/Henrik Östman, Daniel Färnbo, Mats Karlsson, Mathias Sandberg, Pim Lindahl

Svenska Spels styleguide

Svenska Spels styleguide hjälper oss att utveckla snabbare och få en mer enhetlig design över flera olika plattformar.

På vår tidigare sajt hade vi inget bra sätt att dela design och klientkod mellan olika sidor och tjänster. Vilket ledde till att för varje ny tjänst som utvecklades så togs det fram ny design och utvecklarna fick bygga allt från grunden varje gång och la mycket tid på att tolka och översätta design till kod. En annan nackdel var också att sajten fick en väldigt inkonsekvent design och kunde skilja sig mycket från sida till sida.

Nya plattformen

När vi skulle ta fram vår nya tekniska plattform ville vi att det skulle vara enkelt att återanvända funktionalitet och design tvärs över hela sajten. För att det skall vara görbart är det viktigt att det finns en tydlig dokumentation om vilka funktioner som finns tillgängliga, hur de ser ut och fungerar.

Vår lösning blev att ta fram en styleguide där vi kan samla alla återanvändbara komponenter samt dokumentation om hur, när och var de skall användas.
Där hittar man t.ex. knappar, logotyper, ikoner, färger, modaler, menyer och många andra komponenter som vi använder över hela sajten.
Alla komponenter och även färger, ikoner mm har fått egna namn så alla roller i teamen pratar om samma saker för att minimera missförstånd. Istället för att hela tiden kolla i Photoshop vilken färg det skall vara kan vi enkelt berätta att det skall vara färgen stryktipset-500 eller grey-400 så blir det automatiskt rätt färg.

Det är lätt att dokumentation snabbt blir inaktuell om den inte hålls uppdaterad. Därför har vi valt att dokumentation är en del av varje komponent så kod och dokumentation är samlat på samma ställe. Sedan sammanställer vi alla komponenters dokumentation som tillsammans bildar vår styleguide. Eftersom dokumentationen är en del av plattformen så kan komponenterna köras live i styleguiden precis som på sajten. På så sätt går det alltid att se exakt hur en komponent ser ut och fungerar från styleguiden vilket vi har upplevt som en stor fördel när vi utvecklar nya och gör justeringar i komponenter.

I styleguiden går det också att ladda ner alla logotyper, typsnitt, ikoner och övriga spritemaps så dom enkelt kan användas på andra plattformar såsom iOS och Android.

Just nu är vår styleguide endast tillgänglig internt men målet är att öppna upp den publikt så våra partners som utvecklar sidor åt oss också kan ta del av alla våra komponenter och designriktlinjer.

/Emil Öhman

Om Tech

Tech-bloggen har vi satt upp för att visa vad vi gör på teknik-sidan inom Svenska Spel. Du kommer att kunna läsa inlägg skrivna av oss som brinner för utveckling, arkitektur och DevOps.  

Mer om bloggen och oss som skriver

Senaste inläggen