Getting Started with API development using TypeLevel Stack

People always talked about beautiful apps, be it web or mobile. Create a crazy number of frameworks to make your frontend work as fast as possible. But they mostly forget about the backend part, called the server-side application.

TypeLevel stack provides wonderful sets of purely functional libraries to write backend code. A backend can be a simple monolith server or micro-service styled multi-server application. TypeLevel stack allows you to write your server code with less error and more confidence. TypeLevel stack has libraries for almost everything from doing Http to database access.

In this talk, I will tell you why anyone should TypeLevel stack to build a backend application. I will also share little bit controversial opinionated way to arrange things. It will also showcase how composability of functional programming helps to write the scalable application.


Outline/Structure of the Tutorial

  • Introduction to Cats and TypeLevel ecosystem
  • How to get started with http4s, doobie, tsec like libraries
  • How I like to arrange code and compose application for better scalability
  • Also, try to give answer why TypeLevel stack and what are benefits of having it compare to other options.

Learning Outcome

I did faced quite a good amount of issues when I wanted to create simple Scala REST api application. There are too many options and I did get lost couple of times. This talk hopefully helps attendee to get started with Type Level stack, and get going more smoothly for their future functional web application.

Target Audience

People who are getting into functional programming or like to create web application using purely functional JVM system.

Prerequisites for Attendees

  • Knowledge of Web Programming
  • Basic knowledge of Scala
  • Interest in purely functional web development
schedule Submitted 1 year ago

  • Harald Schult Ulriksen

    Harald Schult Ulriksen - From C# monolith to functional actors with Orleans and F#

    45 Mins

    This is an experience talk from my work with NRK, the

    Norwegian Broadcasting Company, Norway's public broadcaster.

    Over the last 3-4 years we've taken the TV and radio streaming sites from a monolith to multiple

    domain based services. We'll look at how we've transitioned the from a pure object oriented development team to a function friendly organzation, how gorwing the organization forced us to work with Conways law, as well as a deep dive into the bounded context of personalization.

    Keeping track of user progress and favorite shows is the responsibility of Personalization domain, with high performance requirements and surprisingly

    complex business rules. With new business rules and changing architecture, Personalization was in dire need of work. Combining FSharp and its typesystem and immutability with Orleans, an open source Virtual Actor platform for distributed high-scale computing applications, provided us with functional programming with OO principles in a fast and scalable platform. I'll show why we chose this path, the benefits we gained going from C# to F# and some of the lessons learned building on an actor model.