Using Node.js would have worked, except that we had other internal tools in Node that would fall over (affecting all requests) with a single unhandled exception. Java would also (historically) limit contributions to backend devs. We could have pursued a purely server-rendered approach, but our Java stack wasn’t built for this.
It would have occupied all of my time and may not have launched ahead of our product launch.
#LIVEVIEW ELIXIR CODE#
Having to write all of the frontend code wrestle with webpack configuration, react router, and react form and also write all of the backend endpoints seemed daunting for little gain. We had ideas of realtime features (like maps of ad campaign interactions) that could involve more client-side interactions, but those were nice-to-have and we still weren’t convinced an SPA was needed for that.
#LIVEVIEW ELIXIR OFFLINE#
This tool didn’t need a single page application: it didn’t have rich user interactions (would be mostly form submissions and some tables) and didn’t need offline capabilities. Even with a single fullstack dev, this would still be a lot of work. Traditionally, this would shake out to needing both a frontend (FE) and backend (BE) dev working on this tool. The standard approach at our company would be to spin up a single page React app and a Java JSON API backend. To start, I aggregated a list of all of the features we’d need for the app and thought through the tradeoffs of various tech choices. I volunteered to lead this effort and build the first version. It also didn’t make sense for a disconnected team to build it for us since we’d need control over rolling out features as we learned more about our needs. Similar to my earlier points, it would be hard to get this internal app prioritized before launch, given that it was only to be used internally.
The problem was that all of the teams involved with the launch were swamped with bug fixing, last minute polish on features, and end-to-end testing. The app would give us visibility into numerous backend services involved in the product and also provide monitoring capabilities for purchased goods. My team at work was recently in the situation of needing an internal app built a few weeks before the launch of an important product. Phoenix LiveView checks all of those boxes. Ideally, you’d want to spend as little time as possible on internal apps, but have them be reliable, cheap to extend, and be welcoming/maintainable by a wide variety of teammates. What also inevitably happens is that teams and non-technical stakeholders end up relying heavily on the internal tool and the lack of attention and quality end up biting you. Internal web apps tend to have some of the following qualities: they’re important, but not customer facing because they’re not customer facing, they’re often hard to get time to work on or maintain - making them stagnate or have low quality the functionality is often trivial (and potentially boring) to build and it’s usually hard to get any team to own it. Aside from the programming model, LiveView itself lets you build fault-isolated components that keep the rest of your page usable with no extra code. Developers without frontend experience are also empowered to contribute given the fewer moving parts with this model. TL DR: After building a large internal web application, I found that Phoenix LiveView’s programming model lets you build web applications in half the time and with half the number of people - compared to a single page application with a JSON API backend. He also shares how he made his OpenSource work sustainable, and successfully shifted to being full-time supported for his community work.Learnings using Phoenix LiveView for Internal Web Applicationsĭisclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer.
He created Alpine.js to help solve problems common to both LiveWire and LiveView. Caleb is the creator of PHP Laravel LiveWire, a framework inspired by LiveView. We reached outside the Elixir community to talk with Caleb Porzio.
0 kommentar(er)
