4 ms·

After using Liveview it’s very hard for me to go back to normal full stack development, the separation between frontend and backend with some rest api seems so

After using Liveview it’s very hard for me to go back to normal full stack development, the separation between frontend and backend with some rest api seems so arbitrary to me. Especially with doing anything realtime, with your custom websocket protocols, sagas etc. I’ve been consulting with a few startups and it’s crazy to see how much effort is duplicated and coordination needed even in cases where there’s no public api necessary. ATM I’m working on a few side projects and I’m enjoying being able to build all of the functionality necessary alone without reaching for anything outside elixir+postgres. The biggest issue is a pretty steep learning curve and lack of beginner friendly documentation, lots of tinkering and code reading is necessary when starting.

cultofmetatron 4y ago
after 8 years as a nodejs developer, elixir's concurrency and parrallelism toolkit is lightyears ahead. sagas, promises, channels.. Its all a joke compared to what elixir offers. Phoenix gives me a network synced crdta backed data structures, multicluster websocket support with long polling fallback, supervision trees with long lived processes and a descent pubsub system out of the box. we've gone 2 years in production and haven't needed redis or rabbitmq yet. its allowed us to focus on delivering features without drowning in infrastructure.
- mstipetic 4y ago
  For me the most depressing thing has been - once I've seen the OTP library and everything elixir (well, erlang) provides, I've realized we've figured out most of the things like 30 years ago and have kept reinventing the wheel constantly, just because of not looking back and checking has it been solved already. Erlang's introspection tooling is better than 99% of what the market offers now as an expensive SaaS.
AlchemistCamp 4y ago
Can you elaborate a bit on the "steep learning curve" bit? What took the most time and what do you wish you'd known sooner?
- mstipetic 4y ago
  Hey, big fan of AlchemistCamp! I'd say there's plenty of short snippets on specific functionality of phoenix, but not enough of content on how things fit together (what exactly do you use genservers for, where do you place things in a project, how do you organize your repo queries - do you pass objects or PKs around, how to refactor a complex function, how do nested livecomponents work and what happens to assigns when you route back, what's the difference between live_redirect, push_redirect, redirect etc.) These are the things off the top of my head that I've struggled with, and ultimately built something but in the back of my head I'm not REALLY sure if I did it correctly. I've also really enjoyed Pragmatic Studio's course on OTP where they build a genserver from scratch, thay was eye opening, a few more in-depth courses would definitely be welcome.
  - AlchemistCamp 4y ago
    Thanks for your kind words. I kinda got frustrated with my LiveView series since I started so early when it was in so much flux and have kinda been waiting for it to hit 1.0 before publishing more. One in every four episodes or so was an upgrade of the project and I kept getting incoming email from people trying to follow my series on newer library versions. Agreed on Pragmatic Studio's course. It's probably my favorite video resource for OTP, my favorite overall resource being Saša Juric's book, Elixir in Action.
eterps 4y ago
> with your custom websocket protocols, sagas etc. What is meant by sagas in this context?
- mstipetic 4y ago
  Something like https://redux-saga.js.org/ https://redux-saga.js.org/, basically doing complex background workflows, something that feels like event-driven browser JS was not really built to do
  - eterps 4y ago
    Thanks
foldr 4y ago
LiveView is kind of magical when it works. Where I struggle with it is the constant need to decide between implementing UX logic directly in LiveView or implementing it purely on the client side via the JS helpers. Sometimes you really want the logic on the client side for latency reasons, but then you lose the ability to test it properly (unless you resort to Cypress or something like that).
- josevalim 4y ago
  Generally speaking, if it can be done in the client, it should be done in the client. Phoenix.LiveView.JS aims to tackle the obvious cases but it also documents a pattern that I tend to use a lot in my apps: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html#module-custom-js-events-with-js-dispatch-1-and-window-addeventlistener https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm... The pattern above has a benefit that the dispatch still comes from Phoenix, so you are not relying on IDs or query selectors to attach functionality. You can see how we use it in Livebook here: https://github.com/livebook-dev/livebook/blob/main/assets/js/events.js https://github.com/livebook-dev/livebook/blob/main/assets/js.... However, if the callbacks get too complex, then you may indeed want to test them via headless browsers.
  - mstipetic 4y ago
    Hey Jose, funny to see there answering phoenix questions on a Saturday. Since we're discussing JS, are there any official plans to expose pushing events to the backend directly from JS? What I've been doing (and seen others do) is to assign a hook to a global window variable in the mounted callback, but that seems very hacky. Is there any reasons why that should be avoided or why you don't want to expose a proper API for that?
    - josevalim 4y ago
      You can do it using JS.push from the linked page. You can also use execJS to execute any JS event, including push, from anywhere. I am not sure if this helps though. :)
  - 4y ago
papito 4y ago
> it’s crazy to see how much effort is duplicated and coordination needed even in cases where there’s no public api necessary. Probably because they decided to use microservices (read: distributed systems) for no God-loving reason.
- sahruum9 4y ago
  It's a distributed system either way. Acknowledging that opens up a whole world of already thought through solutions to problems in distributed systems.
  - deleted 4y ago
    [deleted]
- sodapopcan 4y ago
  Microservices aside, writing a web API so a single client can talk to a server is perverse in my books.
JanSt 4y ago
Is it possible to pack a liveview application for the app store (i.e with capacitor)?
- bostonvaulter2 4y ago
  I think you may be looking for this neat library: https://github.com/elixir-desktop/desktop https://github.com/elixir-desktop/desktop Although to be honest it boggles my that it's possible to accomplish this on iOS.
- klohto 4y ago
  Yes, there are several. I don't have examples on hand, but elixirforum will find a few.
mavelikara 4y ago
Does something like Storyboard exist for LiveView?
- bostonvaulter2 4y ago
  Yes! (well I'm assuming you mean Storyboard). There's a new project that accomplishes just that: https://github.com/phenixdigital/phx_live_storybook https://github.com/phenixdigital/phx_live_storybook

cultofmetatron 4y ago

after 8 years as a nodejs developer, elixir's concurrency and parrallelism toolkit is lightyears ahead. sagas, promises, channels.. Its all a joke compared to what elixir offers. Phoenix gives me a network synced crdta backed data structures, multicluster websocket support with long polling fallback, supervision trees with long lived processes and a descent pubsub system out of the box. we've gone 2 years in production and haven't needed redis or rabbitmq yet. its allowed us to focus on delivering features without drowning in infrastructure.

mstipetic 4y ago
For me the most depressing thing has been - once I've seen the OTP library and everything elixir (well, erlang) provides, I've realized we've figured out most of the things like 30 years ago and have kept reinventing the wheel constantly, just because of not looking back and checking has it been solved already. Erlang's introspection tooling is better than 99% of what the market offers now as an expensive SaaS.

AlchemistCamp 4y ago

Can you elaborate a bit on the "steep learning curve" bit? What took the most time and what do you wish you'd known sooner?

mstipetic 4y ago
Hey, big fan of AlchemistCamp! I'd say there's plenty of short snippets on specific functionality of phoenix, but not enough of content on how things fit together (what exactly do you use genservers for, where do you place things in a project, how do you organize your repo queries - do you pass objects or PKs around, how to refactor a complex function, how do nested livecomponents work and what happens to assigns when you route back, what's the difference between live_redirect, push_redirect, redirect etc.) These are the things off the top of my head that I've struggled with, and ultimately built something but in the back of my head I'm not REALLY sure if I did it correctly. I've also really enjoyed Pragmatic Studio's course on OTP where they build a genserver from scratch, thay was eye opening, a few more in-depth courses would definitely be welcome.
- AlchemistCamp 4y ago
  Thanks for your kind words. I kinda got frustrated with my LiveView series since I started so early when it was in so much flux and have kinda been waiting for it to hit 1.0 before publishing more. One in every four episodes or so was an upgrade of the project and I kept getting incoming email from people trying to follow my series on newer library versions. Agreed on Pragmatic Studio's course. It's probably my favorite video resource for OTP, my favorite overall resource being Saša Juric's book, Elixir in Action.

eterps 4y ago

> with your custom websocket protocols, sagas etc. What is meant by sagas in this context?

mstipetic 4y ago
Something like https://redux-saga.js.org/ https://redux-saga.js.org/, basically doing complex background workflows, something that feels like event-driven browser JS was not really built to do
- eterps 4y ago
  Thanks

foldr 4y ago

LiveView is kind of magical when it works. Where I struggle with it is the constant need to decide between implementing UX logic directly in LiveView or implementing it purely on the client side via the JS helpers. Sometimes you really want the logic on the client side for latency reasons, but then you lose the ability to test it properly (unless you resort to Cypress or something like that).

josevalim 4y ago
Generally speaking, if it can be done in the client, it should be done in the client. Phoenix.LiveView.JS aims to tackle the obvious cases but it also documents a pattern that I tend to use a lot in my apps: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html#module-custom-js-events-with-js-dispatch-1-and-window-addeventlistener https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm... The pattern above has a benefit that the dispatch still comes from Phoenix, so you are not relying on IDs or query selectors to attach functionality. You can see how we use it in Livebook here: https://github.com/livebook-dev/livebook/blob/main/assets/js/events.js https://github.com/livebook-dev/livebook/blob/main/assets/js.... However, if the callbacks get too complex, then you may indeed want to test them via headless browsers.
- mstipetic 4y ago
  Hey Jose, funny to see there answering phoenix questions on a Saturday. Since we're discussing JS, are there any official plans to expose pushing events to the backend directly from JS? What I've been doing (and seen others do) is to assign a hook to a global window variable in the mounted callback, but that seems very hacky. Is there any reasons why that should be avoided or why you don't want to expose a proper API for that?
  - josevalim 4y ago
    You can do it using JS.push from the linked page. You can also use execJS to execute any JS event, including push, from anywhere. I am not sure if this helps though. :)
- 4y ago

papito 4y ago

> it’s crazy to see how much effort is duplicated and coordination needed even in cases where there’s no public api necessary. Probably because they decided to use microservices (read: distributed systems) for no God-loving reason.

sahruum9 4y ago
It's a distributed system either way. Acknowledging that opens up a whole world of already thought through solutions to problems in distributed systems.
- deleted 4y ago
  [deleted]
sodapopcan 4y ago
Microservices aside, writing a web API so a single client can talk to a server is perverse in my books.

JanSt 4y ago

Is it possible to pack a liveview application for the app store (i.e with capacitor)?

bostonvaulter2 4y ago
I think you may be looking for this neat library: https://github.com/elixir-desktop/desktop https://github.com/elixir-desktop/desktop Although to be honest it boggles my that it's possible to accomplish this on iOS.
klohto 4y ago
Yes, there are several. I don't have examples on hand, but elixirforum will find a few.

mavelikara 4y ago

Does something like Storyboard exist for LiveView?

bostonvaulter2 4y ago
Yes! (well I'm assuming you mean Storyboard). There's a new project that accomplishes just that: https://github.com/phenixdigital/phx_live_storybook https://github.com/phenixdigital/phx_live_storybook