-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathliveview-production.html
202 lines (192 loc) · 8.71 KB
/
liveview-production.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
<!DOCTYPE html>
<html class="no-js" lang="">
<head>
<meta charset="utf-8" />
<meta http-equiv="x-ua-compatible" content="ie=edge" />
<title>Phoenix LiveView in Production | aswinmohan.me</title>
<meta name="description"
content="I used Phoenix LiveView in Production for my last startup IndiePaper. This blog post outlines why I used LiveView, issues I came across, the good parts and gotchas to look out for." />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link rel="stylesheet" href="./styles/output.css" type="text/css" media="screen" />
<script defer data-domain="aswinmohan.me" data-api="/stats/api/event" src="/stats/js/script.js"></script>
</head>
<body>
<div class="flex items-baseline justify-between">
<p>
<a href="/">back to home</a>
</p>
<p>2022-Apr-06</p>
</div>
<article>
<h1>Phoenix LiveView in Production</h1>
<p>
I came across a
<a href="https://elixirforum.com/t/are-you-all-in-on-liveview-how-are-you-using-it/41628/14">thread on ElixirForum
</a>
that highlighted how everyone was using LiveView in their production
apps. Since IndiePaper is a Phoenix LiveView app, I thought it would be
nice to share my experience with it.
</p>
<section>
<h2>Context</h2>
<p>
Before we jump right in, it's better to have some context about me and
about the project. I'm a single developer working on IndiePaper. It is
a book publishing platform, where authors can write out their book in
an online text editor and we typeset beautiful PDF books from it. The
app is a simple CRUD app with auth, uploads and a custom typesetting
engine.
</p>
<p>
I used TDD to develop the app and it's deployed on
<a href="https://fly.io">fly.io</a>.
</p>
</section>
<h2>Why chose LiveView?</h2>
<p>
I wrote the first version of IndiePaper in Phoenix, but it was at a time
when I didn't know anything about the framework. I rewrote the entire
app in NextJS and Hasura, then in Rails, then using FaunaDB, then in
LiveView and finally in in vanilla Phoenix. This time around I knew
enough Elixir and Phoenix to actually make something useful. I was
content with the full page reloads and it was working well.
</p>
<p>
After some features was complete I wanted to add file uploads for book
promo images. Even though there were well built packages for handling
uploads, I was intrigued by the
<a href="https://www.youtube.com/watch?v=PffpT2eslH8">File Uploads in LiveView</a>
video by Chris. I tried implementing it, but it didn't work out because
I didn't know anything about LiveView. So I bought
<a href="http://pragprog.com/titles/liveview/programming-phoenix-liveview/">Programming Phoenix LiveView</a>
and <a href="https://www.testingliveview.com/">Testing LiveView</a> and
started learning about it.
</p>
<p>
After a while I finished setting up the uploads feature. Then I
converted one more page just for the sake of it and was instantly
hooked. I ended up converting the entire app to Phoenix LiveView,
including a complex realtime editor. LiveView wasn't chosen, I used it,
loved it and used it again.
</p>
<h2>The Great Parts</h2>
<p>
For any tech to be adopted widely, it should be exponentially better
than it's predecessors and current competition (except if you're
javascript). Phoenix LiveView is a step up from everything that has come
until now, with great just enough abstractions and great developer
experience.
</p>
<h3>Elixir Phoenix</h3>
<p>
Elixir and Phoenix is the best part about LiveView. Elixir is a recent
language and hence do not have the hairy legacy that older languages. It
has beautiful patterns, beautiful constructs and beautiful tools that
make working with it a beautiful experience. Phoenix as a framework is
highly performant even with small system configurations, and that sub
10ms response time is a major factor why LiveView has a usable
experience.
</p>
<h3>Testing</h3>
<p>
The second best thing I loved about LiveView is testing, especially
integration testing. I used to write integration tests with Wallaby
which ran the tests in a headless browser. This lead to slow and flaky
tests, even with parallel tests and error recovery. LiveView runs tests
without instantiating a browser. It handles clicks, redirects, and form
events. This leads to fast and stable tests.
</p>
<h3>SPA without SPA</h3>
<p>
This is the major selling point of LiveView and it holds that promise
well. Single Page Apps with a REST or GraphQL backend requires a lot of
extra code at the middle where the communication happens. With LiveView
your app acts with almost the same performance and UX of a well built
SPA without the need for API interfaces. You specify the data in the
templates and it does the rest.
</p>
<h3>Javascript Hooks</h3>
<p>
Interop with Javascript is done through hooks. They enable you to "hook"
into various lifecycle events of the LiveView process. Unlike other
frameworks where escape hatches are an afterthought, hooks are well
designed. For IndiePaper I made a text editor using TipTap and was able
to convert the entire page from Vue to hooks with the hooks version
being more capable and better.
</p>
<h3>Performance</h3>
<p>
With the new <code>live_session</code> helper, we can bundle together
liveviews and the navigation happens through the same websocket. This is
insanely fast. Page navigations happen in under 100ms using from India
with the server in US.
</p>
<h2>The Good Parts</h2>
<p>
These are the things that I liked and would never give up, even though
these were not the reason I would switch to LiveView.
</p>
<h3>Form Recovery</h3>
<p>
Phoenix LiveView requires internet connection to function. But sometimes
internet gets disconnected. This can be frusturating when the person is
filling a form, because on reconnection Phoenix restores the last known
data. If you have a <code>handle_event</code> setup with your LiveView,
the form state gets automatically synced with the server.
</p>
<h3>Free Websocket</h3>
<p>
You get a full functional bi-driectional websocket with good
abstractions for free. For the realtime text editor, rather than
implementing a complex system wiht Redis and syncing, I created a json
diff and sent the data through the websocket with
<code>pushEvent</code> function.
</p>
<h2>The Bad Parts</h2>
<p>
Every technical choice has it's downsides, and LiveView is no exception.
</p>
<h3>Requires Internet Connection</h3>
<p>
LiveView requires an active internet connection to work properly. This
might not be an issue for 90% of people, but if you're domain requires
offline access, LiveView might not be a good fit. This might be a
temporary problem as work is being done to add more offline capabilities
to LiveView.
</p>
<h3>Almost Maturing Ecosystem</h3>
<p>
I hate to put this as a negative, but as LiveView is a young framework,
it has not many resources to learn from for beginners. Although the
community is small, it's really active and welcoming, so this won't be a
problem for long.
</p>
<h2>The Fuck This Parts</h2>
<p>
Gladly nothing yet. I love Phoenix LiveView, in almost 5 months with
LiveView I have never come across a scenario where I just put my hands
up and thought about switching to another framework.
</p>
<h2>The Hopeful Parts</h2>
<p>
Things I wish the LiveView ecosystem would have, but doesn't or
shouldn't.
</p>
<h3>Mobile</h3>
<p>
It would be nice to have a way to run LiveView as a native app on
mobile. I recently made a React Native app with a Phoenix backend and I
was put off by the amount of middleware code I had to write to get the
data and display it. It would be great if we could write a LiveView app
that updated a React Native based mobile app.
</p>
<p>
This might sound like a hype post for LiveView, and it would be
partially true. I loved using Phoenix LiveView for IndiePaper and If I
had to start over again I would choose it again. It has it's
shortcomings, sure, but it has the least shortcomings of any framework I
have used. Try it out, you might surprise yourself.
</p>
</article>
</body>
</html>