Conflict-free Replicated Data Types (CRDTs) are a hot new datatype in distributed programming that promise coordination-free and always eventually-consistent writes. Most of the stuff you will read about them is limited to the context of high-end distributed databases, but CRDT's are more flexible and shouldn't be limited to this field. In the talk, I will demonstrate how CRDT's are great for applications that have partial connectivity (including websites): updates can be applied locally, and when communication is possible, you can send the data back up, and the data will remain consistent even in the most byzantine (or apocalyptic) scenarios. There are even scenarios that can support multiple simultaneous editors.
Beyond that, I will also demonstrate how Elixir's metaprogramming can be used to compose complex models out of CRDT's that themselves exhibit the same exact features. I will also exhibit some newer CRDT features, such as shared-context and delta-operation CRDT's to overcome some of the shortcomings of older CRDT's.
I plan to keep the talk light on theory (the academic literature is sufficient for that).
GraphQL is a query language created by Facebook in 2012 to provide a common interface between clients and servers by defining their data capabilities and requirements. In our work at CargoSense, we’ve both found it to be a transformative technology choice for building general purpose APIs to support devices in the field and third-party developers.
Elixir forms the core of our backend infrastructure, so we knew from the beginning that we’d need to build a GraphQL implementation for the language. The Absinthe package, available on Hex, is the product of these efforts. Its goal is full implementation of the specification--in as idiomatic, flexible, and comfortable way possible to Elixir developers.
In this talk, we’ll walk you through how to build a GraphQL API on top of Phoenix and Absinthe from the bottom-up. We’ll give you the background you need to know about GraphQL’s underlying concepts and provide some of the real world, production insights we’ve gained. Finally we’ll look at Phoenix channels with GraphQL subscriptions, demoing how GraphQL’s concepts extend beyond the traditional request response cycle.
As programmers, change is our only constant. Whether it's innovations in our current stack or the emergence of new languages and frameworks, there is always a new technology to explore. For many of us, that is one of the reasons we were drawn to programming. There is a profound curiosity that drives us and it's that curiosity that can lead to a Polyglot lifestyle. However, just knowing multiple languages isn't enough to claim a Polyglot lifestyle, one must actually utilize their skills. A great example is using one language to explore another. Because of it's flexibility and dynamic nature, Ruby is a great fit for this role. But where to start? In this talk we are going to explore the new functional language Elixir by using Ruby to fill in the gaps. We will look at how Ruby can be used in conjunction with the primary language to handle some of the secondary tasks seamlessly. If your interested in propagating your polyglot potential, join me in embracing Polyglot lifestyle.
This talk will discuss how the Phoenix team was able to create a single chat room with 2 million users on a single machine. Benchmarking WebSockets is a little more in depth than benchmarking HTTP requests, this talk covers the Tsung tool which was used for the benchmarks and how it can be configured for different testing scenarios. I will cover how Tsung was used to find the concurrent connection limits that Phoenix could handle. I will then cover the techniques that were used to find the parts of the Phoenix codebase with the bottlenecks that caused these limits and how these limits were overcome.
Learn how to benchmark WebSockets using Tsung Explore how to find and fix bottlenecks.
Anyone interested in Phoenix Channel performance.
Gary is a member of the Phoenix core team, often found answering questions on StackOverflow for the elixir and phoenix-framework tags. He is developer at VoiceLayer using Elixir and Phoenix on a daily basis.
Through Erlang, Elixir developers have access to some amazing tools for building resilient distributed systems. riak_core is one such tool: it provides the framework behind Riak’s high availability KV store. In this talk, I’d like to explore some unconventional architecture by using riak_core and Phoenix to build fault-tolerant stateful web applications. What happens when the app servers are also the database nodes? Can we avoid some of the traditional pitfalls of stateful servers? Is this a remotely good idea? Let’s take a look!
1) Stateless/stateful setups for web applications — what do these words mean?
2) CAP in brief, consistent hash rings for distributing work: what are the tradeoffs?
3) riak_core - what does it do? Paraphrasing Mariano Guerra’s excellent work.
4) Build a Phoenix application that cohabitates on a riak_core hash ring. What superpowers do we gain from this? What do we have to watch out for? Can we do cool tricks with load balancing or channels? In-memory databases for super-speedy responses?
5) Loosely comparable systems in production/prior art - Microsoft Orleans, Facebook Scuba, others
Intermediate+ Elixir programmers, web developers, students of distributed systems.
Ben works on service discovery, maps of the infrastructure, and human-system reliability.
Bleacher Report is the second largest sport website in the world. At peak times we reach 80 million unique users per month and serve over 100,000 requests per minute to our mobile apps alone. In the past we scaled by adding caching layers, relying heavily on in-memory databases and pre-built content. However as we strive to further individualize the user experience we can no longer rely on caching alone. In elixir and phoenix we found the technology that allowed us to build concurrent api web-servers in an easily approachable language. It complements our existing infrastructure nicely, which is using Ruby on Rails. The performance gains over Ruby allow us to move from a cached-based to a real-time strategy. This talk will give an overview over the caveats we found and how the numbers are showing that we found the right tool for the job.
- Software engineers interested in scaling non-cacheable websites
Whether you're polling message queues, batching records to a datastore, or concurrently uploading a file in pieces to S3, interacting with external services is often complex. When this complexity mingles with your application logic your code becomes messy, hard to test, and fragile to change.
What if you could cleanup the mess with the use of Elixir streams? By choosing to describe these resources as `Enumerable` and `Collectable`, we can encapsulate this complexity and allow the purpose of the code to shine through.
Everyone is familiar with the classic streaming example:
File.stream!(""source.txt"") # source
&String.capitalize/1) # logic
File.stream!(""destination.txt"")) # destination
The power of this way of writing code has very little to do with files, and far more to do with the way in which the `Enumerable` and `Collectable` protocols separate the concerns at work. There is tremendous untapped potential here for declaratively integrating external services with program logic simply and succinctly.
By implementing Enumerable for SQS, and Collectable for a task cluster, a stream could be just as easily be:
SQS.stream!(""task-queue"") # source
|> Stream.map(&build_task/1)# logic
Tasks.cluster(""task-cluster"")) # destination
In my talk I'll cover concrete, practical ways you can encapsulate external resources in this way, yielding tremendous benefits with respect to clarity, versatility, and testing. I'll also go over some of the challenges presented by this approach, to include difficulties faced when making such streams proper OTP citizens.
Future changes to the standard library are likely to make great strides toward overcoming these difficulties, but they're already surmountable. My talk will show you how I've done it, and the decisions that you'll likely encounter along the way.
A talk from Full Stack Fest 2015 (http://fullstackfest.com/)
Functional programming is being revitalized thanks to languages like Clojure, Haskell and Elixir. Even though Ruby is an object-oriented language there are many beautiful concepts in functional programming that we can borrow and successfully apply in our Ruby code.
In this talk I’ll show you how I mix FP with OO. I’ll introduce you to functional objects, explain the beauty of Proc-like behavior, the power of call method and explain why immutability matters.
Recorded & produced by El Cocu (http://elcocu.com)
They bridge your application and your database. They're object-relational mappers, and no two are alike. Join us as we compare ActiveRecord from Rails with Ecto from Phoenix, a web framework for Elixir. Comparing the same app implemented in both, we'll see why even with two different web frameworks in two different programming languages, it's the differing ORM designs that most affect the result. This tale of compromises and tradeoffs, where no abstraction is perfect, will teach you how to pick the right ORM for your next project, and how to make the best of the one you already use.
Let’s talk about language exploration. We’ll discuss how to learn a new language, considerations when introducing things to production, and come up with some ideas for Ruby and it’s ecosystem. Plan on dipping your toes in Elixir, Go, Haskell, Rust, and Scala during the session.
GraphQL is a query language for your unified API. What you ask for is exactly what you get. This holds true no matter what backend powers your API, whether an Ecto backed Database or other APIs themselves. How does this work in practice? In this talk we're going to walk through a service that exposes a 3rd party REST API via GraphQL, augmented with database driven metadata. We'll see how GraphQL can efficiently query both data sources without sacrificing client flexibility, and even provide push notification features not found natively via the REST API or the database.
Concurrency is all the rage. When you have tons of data being shoved down your throat, you need all the help you can get. All the cool kids are turning to alternatives to try and keep up: node.js, clojure, erlang, elixir, Go. Popular thinking is that Ruby is too slow and “won’t scale.” But our favorite friend can support it very well. In this talk we’ll take a look at the actor pattern in Ruby with Celluloid and compare to similar solutions in other languages.
WebRTC brings peer-to-peer communication to the browser in a way that could revolutionize the modern web. Phoenix Channels are great for real-time client server apps, but sometimes parts of your application need lower latency that only P2P can offer. From telephony to video conferencing, P2P communication will drive the next generation of web applications. We'll review WebRTC from the ground up, and what you can expect when using it. Along the way, we'll see code from a real-world application and the lessons learned integrating WebRTC with Phoenix channels.
A overview and dive into the Stream module. When should you use it over Enum? What are the pros and cons of using Stream for your day-to-day tasks? How are some of the functions implemented? We'll go into those questions and find some answers together.
About Geoffrey: Geoffrey Lessel has been a web developer for over 15 years—first with PHP and Perl and now with Ruby on Rails and Phoenix. He has spoken at ElixirConf, blogs about Elixir and Ecto at geoffreylessel.com, and tweets from @geolessel.
When a Rubyist hears "concurrency" they usually Google Elixir, Go, or even Node.js. Turns out, Ruby can be great for concurrency! The Global Interpreter Lock (GIL) does NOT prevent Ruby programs from performing concurrently. In this presentation we'll discuss the true meaning of concurrency, explore the inner-workings of the GIL, and gain a deeper understanding of how the GIL effects concurrent programs. Along the way we'll write a bunch of concurrent Ruby code, run it on multiple interpreters, and compare the results.
Phoenix is the new hotness. Elm is the new hotness. Let's turn up the heat by combining the two for fun and profit.
In this talk we will:
Create a simple Elm client app to demonstrate its Model-View-Update architecture
Enhance our Elm client by getting it to retrieve data from an API
Build a simple Phoenix data API to serve data to our Elm client
Swap our Elm client to use our newly generated Phoenix API
Discuss several ways that Phoenix and Elm can play together
Turn the dials up to 11 by combining Elm's Functional Reactive goodness with Phoenix's channels.
It's been stated that in order to make full use of BEAM, the Erlang virtual machine, any language implemented on top of it needs to adhere to the semantics of Erlang.
Yet, other virtual machines, such as Parrot, stemming from the Perl 6 community, or JVM, the Java virtual machine, support a plethora of languages with differing semantics.
At the heart of these virtual machines, BEAM included, lies an instruction set. Specific commands that any language implemented on top of the machine in question has to be broken down into; any running program ultimately composed of. The instruction set comprises the extent of the virtual machine's understanding of what we want it to do and thus dictates its capabilities.
Let's examine BEAM's and contrast it to that of other virtual machines. In the end we might be able to answer if and why BEAM mandates Erlang's semantics. Or we might all become BEAM assembly programmers.
You have been warned.
Erlang comes packed with a great tool for manually monitoring, debugging, and visualizing Elixir processes: observer. However, it is not always possible to use observer to monitor due to restrictions in the current world of mixed ecosystems, micro services, and docker containers. We offer a new solution :wobserver. It will allow you to directly monitor any node, while offering additional options like:
- web interface, view from anywhere, from any system [with a browser]
- api, json api for automated monitoring or integration with other applications
- system metrics, pre-formatted metrics, simple to integrate with other software
- node discovery, discover nodes behind load balancers and view them all through one single interface
- simple, just add it to your mix file and you are up and running
In the talk we will go through the background of the project and show you how to mount :wobserver into a Phoenix application, hook it up to Prometheus, and deploy it behind a load balancer.
Feature tests are one of the best ways to ensure reliability and consistency for web applications. But, as your test suite grows feature tests can become a performance bottleneck. This leads to developers running their tests less often or only on the continuos integration server. In some cases it means avoiding feature tests altogether.
Luckily, the release of Ecto 2.0 means that its now possible to run concurrent browser tests. Wallaby is a tool designed to take full advantage of that.
In this talk we'll look at how to configure a Phoenix application for concurrent testing, give a brief overview of Wallaby, and showcase how we can use data transformation and composition to quickly build a highly concurrent test suite.
ActionCable – одно из самых примечательных нововведений Rails 5, которое буквально всколыхнуло Rails сообщество: статьи, инструкции по применению, "лайки" и "репосты" в Twitter. Это не удивительно: минимум настройки сервера, использование бизнес-логики (и даже шаблонов!) в _каналах_, JS-клиент, который просто работает – это пункты "за".
Но есть и весомое "против": все это написано на Ruby – языке, который я очень люблю, но который пока еще сильно уступает в вопросах масштабируемости и производительности _конкурентных_ приложений, а значит, либо ваше приложение рухнет под нагрузкой, либо ваш чек за серверные ресурсы начнет стремительно расти.
А теперь давайте представим, что никаких "против" нет, а есть _идеальный_ ActionCable с приятным Rails интерфейсом и производительностью и надежностью Erlang/Elixir приложения (с "2 million connections"). Я хочу представить свою попытку "приблизиться к _идеалу_" – AnyCable.
VoiceLayer is a real-time voice messaging platform developed using the Phoenix Framework. Its media router core service must be resilient to a wide variety of adverse conditions, including software, hardware and even network failures.
According to the CAP theorem, a system can only meet two of the following three guarantees: Consistency, Availability or Partition Tolerance. We will characterize Available and Partition Tolerant (aka AP) systems and describe different implementation approaches.
One such approach is based on Riak-Core, which is the distributed systems framework that forms the basis of how Riak distributes data and scales. Despite Riak-Core being an impressive framework, at VoiceLayer, we took a different route and relied on Phoenix Tracker (a core component of Phoenix Pubsub) to meet our requirements. We will describe this approach details, contrast it to other solutions and discuss its tradeoffs.
So, you've played around with Ecto, and maybe even shipped an app or two that uses it. But you still have this sneaking suspicion that you might not be using it as effectively as you could, or maybe you just find yourself Googling for examples a little more often than you'd like.
Let's get you levelled up.
In this hands-on, practical talk, you'll learn about some of the foundational principles behind Ecto, and walk through a series of examples, starting from the very simple and ending with the truly gnarly, to help you understand how Ecto works and how to use it more effectively. You'll come away with a better understanding of Ecto, and a cookbook of examples you can refer back to when you need a refresher. Feel free to bring a laptop and code along!
With the announcement of Phoenix 1.3 supporting umbrella projects at ElixirConf 2016, I was inspired to start early on converting our Phoenix 1.2 application to umbrella. Since the umbrella project templates weren't publicly available yet, I had to find the seams in our single, monolithic application where I could start breaking it into OTP apps for the umbrella project.
I'll cover the thought process of how I broke up the app and what guidelines I use now when adding new code as to whether add it to a pre-existing application or to make a new OTP application. I'll share the common code I was able to share between our RPC server and API controllers, which I believe is a good behaviour for resource module in Phoenix 1.3.
Developing "hardware and hardware accessories" can be difficult and time consuming. Until now, you would have to constantly swap SD cards or create and push full firmware updates in order to iterate on your device. We want to make the development cycle as comfortable as possible by marrying the fundamentals of Erlang hot code reloading with connected Hardware in the Loop (HIL). Together, we will explore the Nerves development cycle through live demonstrations from mix nerves.new to mix firmware. Furthermore, we will push live code updates and even leverage the Phoenix Live Reloader on the Target. Finally, we will take a peek at executing ExUnit tests on connected hardware.
Thanks to frameworks like Phoenix, web services can be developed quickly. The result is scalable, fast and easy to adapt. A perfect platform to create really complex web services. When software gets more complex, it gets harder to test. There are many different parameters one can supply, posted JSON data types can have different dependencies and the order in which things happen may play a role. Thus, even if Phoenix helps a lot in getting a correct and complex web service produced, there still are possibilities for mistakes. These mistakes have to be found and testing is a way to do so. QuickCheck helps to automatically generate test cases for such web services.