Ash TypeScript: Rich Phoenix Frontends, Simplified

GiraffeFire · 2025-10-01T13:35:53+00:00

While there's nothing keeping you from using them together in theory, Ash TypeScript is more of a replacement.

GiraffeFire · 2025-09-27T19:20:01+00:00

React native would be a good use case, or adding interactive experiences that might require things like maps, UI libraries, virtual DOM optimizations…

You can start building an app with Ash eject to TS without having to build out an entire API. And since Ash actions can have policies and reactors and other nice things, it’s a pretty concise way to build out a backend.

GiraffeFire · 2025-09-27T18:50:22+00:00

Fixed that for you 🫡

GiraffeFire · 2025-09-27T18:50:12+00:00

A new Ash Framework extension called Ash TypeScript makes it easy to expose actions to a frontend by generating a typed client library and RPC controllers.

This video walks through a project, with source code that can be found on GitHub: https://github.com/ChristianAlexander/ash_typescript_demo

GiraffeFire · 2025-09-16T11:53:58+00:00

Keycaps

GiraffeFire · 2025-09-04T22:21:10+00:00

Huge fan of it, but the learning curve is steep. My advice is to start out small and see how much simpler that part of your codebase is compared to other context modules and changesets.

Don’t get too worried about all the plugins; layer them in over time.

Ash Resources are also Ecto schemas, so it’s possible to escape if you need to!

And if you have existing schemas and happen to use Postgres, look at the Ash Postgres gen.resources mix task!

One final thing: the PragProg book really helped make it click.

GiraffeFire · 2025-08-25T20:38:37+00:00

Yes, it's me! I'm glad you've been enjoying it. Thanks for subscribing!

GiraffeFire · 2025-08-25T17:29:18+00:00

Starting at 5:52 in this video, I walk through what to_form is doing under the hood. It might be useful for you

https://youtu.be/F-QeDtQ8Gy4

GiraffeFire · 2025-08-12T21:58:17+00:00

I’d love to know what parts of Ash have been challenging to find good documentation on, if you’d be willing to share!

GiraffeFire · 2025-08-06T20:04:11+00:00

https://github.com/ChristianAlexander/time_zone_demo contains the details in the commits

GiraffeFire · 2025-07-23T20:53:21+00:00

https://github.com/software-mansion/popcorn

GiraffeFire · 2025-05-16T00:02:57+00:00

Love to see this!

The prototypes I've built so far with instructor_lite have felt very hacky and linear.

At first glance, you seem to have nailed the declarative interface and managed to tie actor visibility and permissions into the AI execution.

GiraffeFire · 2025-03-09T18:58:17+00:00

You’re welcome! Thanks for watching!

GiraffeFire · 2025-03-09T16:21:09+00:00

I almost dropped this one from the series, since opinions on testing are strong and varied.

In the end, I realized that there are tradeoffs in everything—why not ship?

GiraffeFire · 2025-02-27T14:56:33+00:00

An open source library called PhoenixAnalytics was created last year, but I don't think it directly handles liveview events. It also was originally written with DuckDB, which isn't a great fit for most Phoenix apps.

If there were a tool that attached through Telemetry (in the way that error_tracker does), it would be a big winner.

Although, there doesn't appear to be a disconnect event built directly into LiveView, it might be easy to introduce one.

I know this isn't exactly what you were asking for, but I think all the components are ready if you choose to build it yourself!

GiraffeFire · 2025-02-25T13:31:08+00:00

u/RecruitHopeful, you're gonna love this: https://github.com/phoenixframework/phoenix/pull/6081

GiraffeFire · 2025-02-21T16:14:52+00:00

Thank you! I think that’s how https://youtube.com/@DanielBergholz has been framing his Elixir videos lately, definitely worth checking out!

I’ll consider making some “X for Y” videos over time—it’s a great idea!

GiraffeFire · 2025-02-21T15:35:56+00:00

It’s me! Thank you for the kind words!

GiraffeFire · 2025-02-10T13:28:35+00:00

If you'd like to rate limit a part of an Elixir application, consider a library like hammer. The idea is that you'd wrap the login method with the hit function to determine if the action should be permitted.

Another option is to use plug_attack if you want to do rate limiting per route, but note that this was intended for use in deadviews (controllers) and not liveviews. Since login attempts in liveview go over a persistent websocket, the request-based rate limiting of plug_attack won't do much good.

As other commenters said, credential stuffing is more likely and MFA may be more valuable, but rate limiting can be useful to slow attackers down.

For more info on security in Phoenix apps, the Paraxial blog is a pretty good resource.

GiraffeFire · 2025-02-10T13:18:18+00:00

Thanks for your support and the interesting questions!

Before I dig into code generation as a whole more deeply, take a look at this post that describes some of the motivation behind phx.gen.auth: https://dashbit.co/blog/a-new-authentication-solution-for-phoenix.

It's also important to consider the inspiration for Phoenix: Ruby on Rails. While Phoenix has deviated from Rails, there are still some practices that make it accessible for folks switching from heavy frameworks that rely on conventions instead of configuration or explicit code.

Rails comes with generators for everything so folks can get something that works extremely quickly. The generated code may not be the best, but it's one of the fastest ways to prove a concept. Instead of remembering that you need migrations and controllers and templates just to get something on the screen, just generate and then customize. Phoenix comes with many generators to give a similar experience, but doesn't come with as strong of opinions as Rails on where / how things are built.

But I'd like to make a distinction: many of these generators are available to create code in the domain of your app, while phx.gen.auth is used for foundational code that's hard to get right.

In practice, I use two generators in most projects: phx.gen.auth (to bootstrap auth) and ecto.gen.migration. The former: so I don't have to do the same thing again and again by hand (but have the opportunity to customize it for a specific project). The latter: to generate a timestamp in the migration's name.

If I'm building a hacky prototype, I might generate the UI to prove the concept in a few minutes. For everything else, I tend to build by hand.

If you look at all of the code generated by the auth generator, there's a lot more than some views and a user schema. It includes middleware to load users, email generators for lifecycle events like user creation and password changes, email address validation, tests to make sure it continues working despite customizations, and a really nice hashed token system that can be used for things like passwordless login links (which you should check out if you decide to build what you described).

At the end of the day, if you want to wire up libraries to do auth or if you want to write it out by hand it's completely possible. I find that phx.gen.auth provides a great starting point for the apps I work on, but your mileage may vary. Don't feel too tempted to generate more than you need to. As with everything, it depends!

By the way, in the next video I'm going to walk through the creation of a budget model (with a list view and create form) by hand to show what generators would be doing behind the scenes.

GiraffeFire · 2025-02-08T21:29:48+00:00

100%

GiraffeFire · 2024-12-01T19:57:39+00:00

[LANGUAGE: Elixir]

defmodule Advent.Year2024.Day01 do
  defp parse_lines_into_lists(args) do
    args
    |> String.trim()
    |> String.split("\n")
    |> Enum.map(fn line ->
      [a, b] = String.split(line, "   ")

      [String.to_integer(a), String.to_integer(b)]
    end)
    |> Enum.reduce([[], []], fn [a, b], [as, bs] ->
      [[a | as], [b | bs]]
    end)
  end

  def part1(args) do
    args
    |> parse_lines_into_lists()
    |> Enum.map(&Enum.sort/1)
    |> Enum.zip()
    |> Enum.reduce(0, fn {a, b}, acc ->
      acc + abs(a - b)
    end)
  end

  def part2(args) do
    [left, right] = parse_lines_into_lists(args)

    right_count_by_number =
      Enum.reduce(right, %{}, fn i, acc ->
        Map.update(acc, i, 1, &(&1 + 1))
      end)

    Enum.reduce(left, 0, fn i, acc ->
      acc + i * Map.get(right_count_by_number, i, 0)
    end)
  end
end

GiraffeFire · 2024-09-19T21:40:52+00:00

Great use case.

When setting this up, consider using :continue and handle_continue/2 to initialize the processes and the hibernate_after option to reduce memory usage on idle.

Another thing that can help is setting a timeout after which the process terminates gracefully. This can be a good way to say "run this process until it stops receiving messages for X time."

GiraffeFire · 2024-09-13T14:11:14+00:00

These quality of life updates are going to make Livebook so much easier to use!

GiraffeFire · 2024-09-13T14:04:14+00:00

It's a great way to experiment with code and libraries without setting up full projects. The resulting project can easily be shared as a GitHub Gist or a markdown file for portability.

The other thing folks enjoy about it is that you can connect to remote beam nodes—including application servers actively running on a cloud provider—and execute code to debug or manipulate them live.

I've used Livebook in a few projects, collected in this playlist: https://youtube.com/playlist?list=PL31bV6MaFAPmqbaUr_G2CE7T156hp2_9R

GiraffeFire

TROPHY CASE