Elixir in Production: Venu
In this article, we’re interviewing Nathan Johnson, one of the co-founders of Venu, a community-driven online marketplace for virtual events. Venu is written in Elixir and has recently gone into beta, so we thought it would be an excellent opportunity to learn more about the choice and advantages of using Elixir for one’s startup.
If you want to learn about their stack and how Phoenix LiveView enabled them to build their app quickly (3 months of part-time work), read on.
Interview with Nathan Johnson
Could you tell us more about your company and your role there?
Sure thing. Venu is a marketplace for live events/experiences. It allows organizers to create/sell tickets, set up schedules and multi-track events, and live stream those events in the same vein as Twitch or Mixer. Its focus is on conferences but can be used for any live-streamed content.
I am one of the co-founders along with Brodey Newman and Dillon Chanis. I do a good bit of the backend development/integrations.
Could you talk about the stack of Venu? Any particular Elixir libraries that you want to feature?
Our stack is Elixir + Phoenix LiveView + Alpine.js + Tailwind CSS hosted on Gigalixir with a couple of AWS services (S3/CloudFront).
LiveView has enabled us to build the app in about three months part-time and is definitely worth mentioning. It can be a bit of a learning curve, and new things are always being added to it, but the velocity it gives you is well worth it. You don’t have to worry about the plumbing of how data gets from your backend to the frontend so you can focus primarily on the UI/presentation layer. LiveView isn’t a 1.0 release yet, so there have been some challenges with new releases coming out and some bugs, but overall it’s been fantastic.
Do you use any Erlang libraries in Elixir code? If so, are there any you would like to feature?
Nothing third-party, but some of our prototype streaming code is using the raw
Do you use distributed Erlang functionality for cross-node message passing? Why or why not?
Currently, we don’t use cross-node messaging because we can run everything off a single replica, but we built our app with that in mind. For instance, our code that manages the state of a live stream, users connected, etc. is all GenServers, so if we need to scale out, we can transition from a single node to multiple nodes with message passing easily.
Do you have non-BEAM code in your codebase? If so, how much and why?
Only some of our front end is non-BEAM because we didn’t want to put things like which modals/dropdowns were open in our LiveView state. We’ve considered writing some Rust for the live streaming as well, but Elixir works pretty well for that.
Where is Elixir great to use and where does it fall short in your stack?
Elixir has been great for everything so far. A lot of our codebase right now is a simple Phoenix app managing some basic content, but even the complex stuff like payouts via Stripe and the live streaming has been trivial as well. The only thing we had any real issues with was deployment, but we’ve been using Gigalixir and it makes that process extremely simple.
What was the biggest challenge you’ve overcome while working on this project? If Elixir helped you to solve it, how?
We had a couple of major challenges. The first one: an ongoing issue with time zones that is not that fun to talk about but is easily solved with Elixir’s Timex library. The other one was handling real-time content, which is pretty interesting.
For our app, we need to keep everyone in sync when viewing/messaging on a live stream. Elixir definitely helped solve this in a simple way. Phoenix has built-in Pub/Sub functionality that allows us to broadcast and subscribe from our LiveView instances. So, we can easily publish updates for when a stream starts/stops or when new messages come in, and the UI updates in real-time because of the magic of LiveView.
Are you satisfied with the result?
Absolutely. It has definitely come a long way over the past three months, and I look forward to what’s to come.
What is your scaling strategy post-launch?
After we’ve ironed out the bugs from our beta, we’ll be primarily focused on marketing and landing larger and larger conferences. Our app leverages some heavy third-party integrations to do the payments/streaming, so we should be able to scale well with what we have in place.
Any key takeaways?
I would encourage anyone who hasn’t had the opportunity to check out Phoenix LiveView to take a minute to do so. It changes the way you think about building applications and, even though it is still pre 1.0, is definitely worth investing in. It’s also a good way to get introduced to the joy of Elixir programming.
We want to thank Nathan for taking his time to talk with us, and wish the best of luck to Venu and its team!
If you want to read more about companies using functional programming in production, we suggest you check out our Haskell in Production articles or our overview of the largest Elixir-using companies.
If you have your own Elixir in production story to tell (both good and bad), we definitely want to hear it! You are welcome to write to us: email@example.com.
- Interview with Nathan Johnson
- Could you tell us more about your company and your role there?
- Could you talk about the stack of Venu? Any particular Elixir libraries that you want to feature?
- Do you use any Erlang libraries in Elixir code? If so, are there any you would like to feature?
- Do you use distributed Erlang functionality for cross-node message passing? Why or why not?
- Do you have non-BEAM code in your codebase? If so, how much and why?
- Where is Elixir great to use and where does it fall short in your stack?
- What was the biggest challenge you’ve overcome while working on this project? If Elixir helped you to solve it, how?
- Are you satisfied with the result?
- What is your scaling strategy post-launch?
- Any key takeaways?