Adding a cache to the repository and broadcasting changes to the views.

In the previous part, we talked about Phoenix LiveView and implemented all the necessary views and templates to render all the content on our website. Each live view requests its contents to Airtable on its mount function, assigning them in its state. At first, it sounds like a proper implementation, similar to what we would have done using Ecto and a database to store the contents. However, the current solution has three main issues:

  • Using HTTP to request content against an external service adds an overhead to the initial page load.
  • If, for whatever reason, the external service is down, we won’t be able to display any content to our visitors. …


Rendering content using LiveView

In the previous part, we generated the base application, and the Airtable API HTTP client to request both contents and blog articles. We also defined the Article and Content domain models, and implemented the repository pattern with two different adapters, one returning fake data for testing purposes, and the other using the Airtable HTTP client to request and convert the returned data into our domain. It's time for some front-end fun, so let's get cracking.

Image for post
Image for post

Content rendering using LiveView

One thing before continuing, though. I’m using Bulma, which is very good looking and easy to use CSS framework for the UI styles. …


The project set up and implementing the repository pattern.

In the previous part of these series, we talked about what we are going to be building and its two main parts. Today, we will focus on the Phoenix application, but you need the Airtable base to follow up on the tutorial. Therefore, if you don’t have an Airtable account, sign up, and click on the Copy base link located at the top right corner of the source base. Once you have imported it into your workspace, we can continue creating the Phoenix application.

Image for post
Image for post

Creating the Phoenix application

Before generating the project scaffold, let’s install the latest version of phx_new, which by the time I’m writing this part is v1.5.3. …


Building a headless CMS around Phoenix LiveView and Airtable.

Introduction

In this new tutorial, we are going to be building a headless content management system consisting of two main elements, which are an Airtable base and a Phoenix application powered by LiveView. Let’s take a more in-depth look at them:

Airtable

Airtable is a really cool service based on spreadsheets grouped in bases, that act as a database. …


How I built a concurrent ant farm with Elixir and Phoenix LiveView.

A couple of years ago, I worked on an Elixir personal project which consisted of a virtual ant farm, where every ant was a GenServer process, simulating a basic AI behavior. What initially was going to be something straightforward; it ended up being much bigger and not working as planned, and eventually forgotten. …


Removing Elm ports (to interact with external JS libraries) in favor of Web Components.

One of my favorite talks from Elm Europe 2018 conference was the one about When and how to use Web Components with Elm by Luke Westby, creator of the popular Elm live editor Ellie. In this fun and enlightening talk, he suggests an alternative way of using external JS libraries in Elm, rather than relying on ports. Ports, although being the standard way of communicating with external JS in Elm, might not be the right tool for some particular situations, especially when your application grows and you need to handle a significant amount of them. …


Setting up webpack as our asset bundler and the Elm single-page application.

In the previous part of the series, we covered all the back-end logic regarding sending authentication emails and using the generated tokens to authenticate the connection of a Phoenix socket. In this part, we are going to focus on the front-end, building the Elm single page application skeleton, and using the websockect authentication to hide some parts of it to unauthenticated users. Let’s get cracking!

Front-end setup

I’ve been using Elixir and Phoenix in the back-end, and Elm in the front-end, for almost three years already, and I’m delighted with the result. I tend to use Phoenix’s default asset bundler, Brunch, but I’ve been having some issues lately with it, especially while using its Elm and SASS plugins. Therefore, for this particular experiment, I wanted to test out other alternatives, replacing Brunch with webpack and SASS with Tailwind CSS, which I’m starting to like a lot and seems like the first strong candidate to replace SASS in my front-end stack. Recalling the first part of the series, we created the project using the — no-brunch flag, which doesn’t install Brunch so that we can add webpack directly. …


Sending authentication link emails and the user socket connection

In the previous part of the series, we set up the umbrella application for our new project and created the necessary modules for storing and generating authentication tokens. Having done this, the next step is sending emails to valid users containing the sign-in link that will authenticate them into the system once they click on it.

Image for post
Image for post

Sending emails

To send emails in an Elixir application I usually rely on Bamboo from the awesome team at thoughtbot, which is not only simple and powerful, but very customizable as well. Let’s go ahead and add the dependency to the project, under the PasswordlessAuthWeb application:

# apps/passwordless_auth_web/mix.exs …


Project setup and the initial functionality for storing and verifying authentication tokens

Have you found yourself working on a small project where, at some point, you are asked to give access to some users to a private part of the application or a small admin panel of some sort? …


Adding Google reCAPTCHA support to avoid spambots

In the previous part of the series, we created the landing page main layout and implemented the Elm subscription form, which lets visitors subscribe, saving their name and email in the leads database table. We do not want spambots to subscribe, therefore, in this part we are going to add a protective layer to the subscription process using Google’s reCAPTCHA, which consists of two different steps:

  • Adding the reCAPTCHA widget to the Elm subscription form, and sending the user’s response along with the name and email.
  • Verifying in the server-side the user’s response against Google’s RECAPTCHA API to verify whether is valid or…

About

Ricardo García Vega

I am a passionate full-stack web developer, who loves surfing before dawn. http://codeloveandboards.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store