From Phoenix API to Phoenix/Liveview?

In order to learn Phoenix, I’ve re-developped a backend (api) application which now runs OK with my frontend (node + vue.js) app.

Now, next step in learning (LiveView, this time): I want to get also rid of this frontend app by using LiveView instead.

Do you know some web pages or docs which could give me some clear guidelines, step by step if possible, to add LiveView to an existing api Phoenix application ?

Thanks in advance.

1 Like

Why?

I believe decoupled design gives the greatest flexibility.

As far as I can see the question was to just learn Live View, which is fine on itself right? no other reasons needed.

But in the real world this would not even be such a weird choice to do as you will (in most cases) empower a single team (or even a single person) to move across the whole stack again instead of doing handovers to frontend teams. A lot of companies struggle with this (handovers, ownership of both parts of the code). So while I agree this ‘decoupled design’ can give you flexibility, from another perspective it can also give you even more flexibility if it’s possible to keep everything inside one team, 1 repo and 1 language+framework (and have less code, dependencies and less knowledge to constantly keep up to date, easier (and a single) deployment target). That said, the use case should still fit live view, we have to avoid 1 hammer, everything’s a nail :slight_smile: . (I believe Chris McCord was pretty clear on this, LiveView vs SPA fit different problems/use cases, but in the majority of the use cases they have seen with their company that live view would be a better fit than a full blown SPA).

4 Likes

Hmmm, perhaps because of the

part ? :wink:
This is just an experimentation and I’d like to see how it goes.

The only thing i can come up with given your question is to have your codebase really well structured in the form of contexts. As in; is it possible to drive the app from your IEx console? (only through your contexts) If the answer is yes, then it’s pretty easy to ‘move’ to a live view based app. If not then I think you have to refactor to this kind of architecture. More info about this kind of architecture can be found in this pragprog book: https://pragprog.com/book/jgotp/designing-elixir-systems-with-otp

If you have your code structured in the above mentioned way it should be possibe to have them both next to each other. (API+SPA and LiveView variants next to each other).

Maybe als good to mention that this is just good programming practice and not specific to LiveView.

(if you were looking into live view learning material, this one is very nice (and free!): https://pragmaticstudio.com/courses/phoenix-liveview )

2 Likes

And yes: the “one language only” aspect is very attractive for me (especially if this language is Elixir :wink: ): I’m a bit tired of the JS boilerplates (far too many layers of librairies, frameworks and such) just to achieve only half of the work .

3 Likes

I guess it depends on the nature of the final product. For me, I find the seperation of front and backends very attractive, always.

Hello!

You’ll find the LiveView docs useful: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#module-example

They use the Example section to guide you through what you need to get up and running.

Some of the main pieces are:

  • Adding “phoenix_live_view” to your mix.exs (not covered in the guide)
  • Configuring the socket "/live" in your Endpoint
  • Adding the live_view: [signing_salt: ...] Endpoint configuration key
  • Updating app.js to connect to the liveSocket

From there, just create your LiveView module, add a route to it and you’re good to go!

A short and awesome LiveView video is also highlighted on the website https://www.phoenixframework.org and it’s worth watching.

Let us know how it goes!

2 Likes

Already signed in, downloaded and seen one week ago ! :wink:

1 Like