Working on a game as my hobby project brought up some very interesting challenges. While the game is mostly static/table-top style, many of the challenges were related to the multiplier/backend area. But still, some dynamic aspects of the frontend (built with Phoenix Live View and Surface) are needed. This is how I ended up exploring various ways to create dynamic styles for the HTML components.
José Valim posted this message on Twitter. So here is my experience integrating phx_gen_auth with OAuth for a Phoenix LiveView app.
I’m working on (yet another) personal project. It’s a multiplayer browser game written in elixir/phoenix/live_view/surface. If you did not try surface yet, please do. It’s awesome! But more on my game and surface, maybe in a future post.
To start my project, I needed a fast and straightforward way to handle authentication. That was my first contact with phx_gen_auth. After a while, I decided to go with OAuth. …
Phoenix contexts are a great way to organize the code. They separate the business logic from the web related logic. They group together schemas and business logic. And provide clear ways of inter-contextual communication.
If you are new to Phoenix, I recommend reading at least the official contexts docs before proceeding.
The main advantage: dealing with groups of related functionality isolated into manageable contexts. But that’s also a source of complexity. Designing a new, or existing but fast-growing app into contexts is no easy thing. There may be interdependencies between the contexts (especially between schemas).
There is good advice on…
LiveView is the new cool thing in the Phoenix world. I will not try to say what it does and how it works. There are already many articles and tutorials doing it. I will skip also the installation part, which is covered by the docs.
So let’s start directly with our question. How other application processes can communicate and update the LiveViews?
This time I’ve chosen a real example, a personal project I’ve been working on. It’s a basic Phoenix app, with server rendered templates (EEX) and very little JS.
The challenge is simple. Update the number of recommendations after…
When building a small application is quite easy to overlook the (horizontal ) scalability related aspects. Especially in the early phases. You want it ready and deployed in production. You can build on top of it later on. And I don't say it’s a bad approach. But at least keeping in mind that one day your application may run on more than one server, can save you of some trouble.
Especially with Elixir, if your application relies on GenServers, Agents or, generally, state holding processes. Let’s see why by building a small demo application.
A while ago I read this article about Sagas Pattern and its Elixir implementation: Sage. It immediately got my attention, as a nice way of error handling. I’ve explored error management (from a different perspective) in the Functor Flavoured Pipes in Elixir article. So I was curious trying some new perspective.
As I could not find any complete example implemented with Sage, I decided to build my own. It soon became interesting enough to share it here.
Well, for this answer I will point back to Andrew’s article: https://medium.com/nebo-15/introducing-sage-a-sagas-pattern-implementation-in-elixir-3ad499f236f6. He does a great job of explaining the concept and the…
As you may guess, this article is not about rebuilding the Elixir GenServer. It’s already there and it works great. And that’s what interests me the most: why it works great?
Also, we will not discuss what GenServer does and its generic concepts. If you are not familiar at all with the it, I suggest starting with the docs. They do a great job explaining the basics:
I’ve been using Elixir for quite a while now. But I always had some doubts on some specific aspect of the GenServers: the asynchronous requests (
handle_cast/2). To be more explicit:
(Even More) Functional Elixir — 2
In the last article, we explored some functional concepts such as currying and composition. And how to apply them to Elixir. Reading through the same book, Professor Frisby’s Mostly Adequate Guide to Functional Programming, another concept draw my attention: functors.
According to the same book above:
A Functor is a type that implements map and obeys some laws. It is simply an interface with a contract.
The values are isolated in a “container”. When we
map a function, it will run inside the container, and the effects are isolated in that container. I know…
If you (like me) got into Elixir from an object-oriented language, then concepts like currying, function composing and pointfree functions may not be very familiar. Some of them do not apply by default to Elixir. But they are part of the general functional programming (FP) concepts and worth exploring.
This is the last article in the GenStage under Umbrella series, and the shortest. We made quite some progress. We have a working application and tests are passing. GenStages are sending and receiving the expected information across the Umbrella apps.
We miss just one more thing: automate the GenStage subscriptions. As you remember, we manually subscribed the consumers to the producers in our tests, like so:
GenStage.sync_subscribe(MyUkApp.ReceiveConsumer, to: Converter.ReceiveProducerConsumer)
In the last article, we saw why it is not possible to handle the subscriptions in the GenStage
init. Basically, we do not have control over the application start order in…