Functional programming (FP) has invaded architectures. UIs are built with reactive patterns, servers are stateless, DBs are append-only, and big-data / machine learning patterns are function graphs. This talk surveys FP architecture ideas, shows how they work, and why they are increasingly popular.

A few decades ago when the first architecture books were being written, today’s large-scale web systems were an oddity but now they are mainstream. Our architecture pattern languages have changed as have our development, deployment, and operating procedures (DevOps).

During this transition, one source of ideas has been the functional programming community. Functional programming itself mostly happens within a module and indeed many software architects treat it as an implementation choice, unrelated to architecture. But it turns out that some ideas from the FP community are helpful in architectural design: statelessness, immutability, and pure functions. They underlie DevOps practices and are at the core of many distributed systems patterns at the core of our architectures.

Why now?

Functional programming ideas have been around for a long time but conditions are ripe. 1. Coping strategy for complexity. As systems get bigger but our brains stay the same size, we invent tech to cope. Statelessness, immutability, and pure functions make it easier to reason about how a system behaves. 2. Problems grew in size. No single computer big enough to run a system. FP ideas suited to parallelism and concurrency, so many smaller computers can solve big problems. 3. We have more money than sense. You can buy 100 cloud machines for less than one junior developer. So why not do Continuous Integration with every source code commit? Why not have a farm of servers running different versions of your code during deployments? Why not burn RAM with immutable data structures?

Functional ideas in modern architectures

1. Client-side. Reactive patterns and frameworks. Eg React, CycleJS, Elm.
2. Server-side. So-called “serverless” pure functions. REST architectural style. Reactive services. Event queues between services.
3. Persistence. Append-only datastores. Event sourcing & Command Query Response Segregation (CQRS).
4. Batch sequential & pipeline architectures: Big data processing (Hadoop, Spark), Map-Reduce, Tensorflow and other machine learning graph-based functional transformation.
5. Devops infrastructure. Version control everything (append-only). So-called “immutable” and “idempotent” infrastructure set up by running code, not by Linux admins.

Reactive programming

1. What is it? Evolution of Observer pattern. Observable = Observer pattern plus onError and onCompletion. Hot and cold streams.
2. Use in UI architectures. Strong competitor to Model-View-Controller and sibling patterns.

What you will learn in this talk

The amount of innovation and hype in web technologies is intense and often overwhelming. If you haven’t been staying current, this talk should give you a mental map to start your learning. If you have stayed current, this talk should reveal how functional ideas weave throughout modern web architectures and perhaps provide insight into why they work.

The talk surveys how modern web systems are built with FP patterns. It will dig into one client-side example and show how FP ideas can simplify this task.

I propose this as a 30-minute tech talk. I can scale the material to fit into 22 mins + questions.

I have plenty of material so I’m happy to do a 90-minute tech talk that digs into more details if you think the topic is sufficiently interesting. 90-minute slots are rare at SATURN, so I don’t want to presume.

If you think 90 minutes is better than 30, please consider this as a participatory session. If the audience is really new to FP ideas, it can take time to see how to accomplish work using these patterns. There is a great game we could play a few rounds of (Cube Composer: http://david-peter.de/cube-composer) to warm them up (go ahead and try it now). Then we could design a system using event queues and discuss the quality attribute tradeoffs, or go further into the UI reactive example.