3 ms·

Phoenix + Liveview + TailwindCSS + Postgres Unless a static site or buy option fits right, otherwise it doesn't get any better than a Liveview based app for co

Phoenix + Liveview + TailwindCSS + Postgres Unless a static site or buy option fits right, otherwise it doesn't get any better than a Liveview based app for continued productivity.

RedBeetDeadpool 5y ago
Any thoughts on using React or another frontend framework with liveview?
- mrdoops 5y ago
  React might make sense for some specific components wired up with hooks in Liveview for real-time interactions. So if you have a complex client side component that is already available in React and you don't want to recreate it - I'd just add the JS dependency to Phoenix and embed it in a view somewhere. There are definitely complex client side interactions where integration with Liveview would be preferred, however in those cases React isn't necessarily the best option - vanilla JS or D3 or something of that nature tends to be the winning ticket. TBH I wouldn't greenfield a new web app with React if I could avoid it - either wrapping a Liveview in a React component or React in a Liveview the purpose would be to gradually transition away from React running the whole DOM/view for a large existing app. A GraphQL server with Phoenix/Absinthe for a multi-platform app web + mobile (android + ios) is reasonable but still a bigger company/team solution. React + State management like Redux is a ridiculous amount of overhead by default and I would never implement a greenfield web app that way in 2021. A Liveview interaction follows something like Backend State <query/command> Liveview <websocket> Client/Browser (where only minimal diffs of changed state is sent over the wire) and React is Backend State <query/command> Controller <JSON/HTTP> Axios <Redux/State Management> Virtual DOM <> Browser/Client (where whole json payloads are sent and encoded/decoded over the wire) Where new state means re-fetching all the state each loop instead of just what changed. The amount of data sent over the wire by default is massive with this React + HTTP/JSON model. The encoding/decoding of JSON and having to send full payloads then having state management occur in multiple places and languages - it ends up being a lot more to know and think through. The lines of code to write and amount over the wire with the classic JSON over REST + React/Redux makes it almost 100% required to have separate front/backend developers which then means coordination costs for every new feature. So TLDR; React could make sense for complex components you don't want to reinvent the wheel for or when those interactions are complex and client side. Existing web apps with a lot of React code that is too much to port over all at once can be done piece by piece (where I'd recommend heading towards handling navigation in Phoenix/Liveview and components in React).
- eric4smith 5y ago
  Don’t. Not necessary in 99.9999999999999% of cases and would just duplicate most functionality. And no, your app is not that 0.000000000001%
  - RedBeetDeadpool 5y ago
    Just theorycrafting here, not saying I have an app that fits the description. Wouldn't you want client side statefulness if you have an app like an online spreadsheet (google sheets, microsoft excel) that could occasionally lose connection but you still want users to be able to continue working on their document?
    - mrdoops 5y ago
      Yeah offline or complex client side state management is a good use case for Javascript. There are Hooks and Push Events with Liveview for real time integrations with Liveview in those scenarios. In my experience offline requirements are rare and often in mobile scenarios where a native or Flutter-like approach is a good option. Complex client side state or collaborative features might use something like https://github.com/slab/delta-elixir https://github.com/slab/delta-elixir or https://www.inkandswitch.com/local-first/ https://www.inkandswitch.com/local-first/ which is where I'd want JS.
simion314 5y ago
I suggest you add more details, like advantages and disadvantages, and tell us how many years of experience you have working with projects in this technology/frameworks. I am curious about something that works on node buy is as boring but robust as a LAMP stack, I just hate maintaining shit where stuff is already deprecated after just a few years, but upgrading is not an option because there are 100 dependencies and we are in the hell where 10 packages are vulerable but can't be updated, 10 are abandoned and I need to research replacements and somehow make time to transplant them... My question is this, Ruby has Rails, PHP has Laravel or Sympony, Python has Django , what is the equivalent for node backends (something that is old,stable and not a mix of 100 packages from 100 random dudes)?
- mrdoops 5y ago
  Elixir is modern tooling on top of the BEAM / Erlang Virtual Machine. This is tech that has been running Telecom systems, companies like Whatsapp, Discord, Klarna, and software like RabbitMQ, etc for decades. The core libraries are very active and well maintained. I tend to prioritize "capabilities to build compelling systems" which, to me, means getting to production quickly so user feedback / product-market-fit tests can occur, but then also scaling a team to maintain the application over time because once you've found a good fit its time to grow. To me stateless CRUD isn't compelling. Its too easy - if your app just provides a GUI in front of a database for Create/Read/Update/Delete operations your app is a database not an app and if all it takes for someone to clone your app is 5 minutes of CRUD generators, then that's not exactly a defensible position to build a business on. Phoenix like other web frameworks provides generators and quick paths for your usual Web + Database applications. Run some commands and you've got a web app with database persistence. Everyone can do this nowadays (Django, Rails, etc) What Elixir and Phoenix does better than anyone else is distribution, concurrency, fault-tolerance, and real time streaming. These capabilities are possible because of deep details on the virtual machine level and become trouble for cooperatively scheduled runtimes elsewhere (e.g. Python, JS, Java, Ruby, etc). If you're building something with: websockets, collaboration, chat, i.e. anything real time between many users - save yourself the trouble and look into an Elixir/Erlang solution like Phoenix/Liveview/Channels/Presence. On the human side Elixir has top tier documentation (example: https://hexdocs.pm/phoenix/channels.html#content https://hexdocs.pm/phoenix/channels.html#content) - we've found it doesn't take long for developers with at least a few years under their belt to pick up the language/framework and be productive. You don't have to know everything - just build some familiarity of where to look and you'll figure it out. Its very important that this human side be scalable as well, and that means developer experience, documentation, on-boarding, etc. I've been using Elixir/Phoenix every day since 2017 to build apps, glue systems together, rebuild Ruby/Rails/PHP/Python apps that don't scale anymore and in general just ship features on time consistently. The thing that I'd toss in as an "it depends" on the technical scaling side is Postgres - its a boring single server relational database that just works but is still a single server architecture made for spinning disk persistence. SSD/NVME/Persistent Memory and more are new foundations for persistence which means new databases on the new foundations may warrant attention soon. 99% of the time just use Postgres/MySQL though. If you're not sure just use Postgres. For many apps in finance or with stringent auditability that are log-centric using a time series and/or event sourcing database makes sense for the projection / read model flexibility. That said you can use Postgres for that so there's no good excuses for not using it. I'd say the biggest disadvantage/con to using Elixir/Erlang is that its more of an expert's tool-set. These are sharp tools made for engineers that make sense to engineers with experience to know they want fault tolerance and concurrency. What this means is that a newbie developer might not know what they don't know they want to know when building an app the first time. This caveat is probably true with any tech stack, but there will be a lot to learn about the backend because there's more possibilities on this backend stack. These backends-as-a-service (Firebase, Hasura, etc) will get things rolling quickly but in my experience all the real juicy core problems of your business will end up in backend code and when that happens you'd better hope those quick solutions don't get in the way.

Phoenix + Liveview + TailwindCSS + Postgres Unless a static site or buy option fits right, otherwise it doesn't get any better than a Liveview based app for continued productivity.

RedBeetDeadpool 5y ago

Any thoughts on using React or another frontend framework with liveview?

mrdoops 5y ago
React might make sense for some specific components wired up with hooks in Liveview for real-time interactions. So if you have a complex client side component that is already available in React and you don't want to recreate it - I'd just add the JS dependency to Phoenix and embed it in a view somewhere. There are definitely complex client side interactions where integration with Liveview would be preferred, however in those cases React isn't necessarily the best option - vanilla JS or D3 or something of that nature tends to be the winning ticket. TBH I wouldn't greenfield a new web app with React if I could avoid it - either wrapping a Liveview in a React component or React in a Liveview the purpose would be to gradually transition away from React running the whole DOM/view for a large existing app. A GraphQL server with Phoenix/Absinthe for a multi-platform app web + mobile (android + ios) is reasonable but still a bigger company/team solution. React + State management like Redux is a ridiculous amount of overhead by default and I would never implement a greenfield web app that way in 2021. A Liveview interaction follows something like Backend State <query/command> Liveview <websocket> Client/Browser (where only minimal diffs of changed state is sent over the wire) and React is Backend State <query/command> Controller <JSON/HTTP> Axios <Redux/State Management> Virtual DOM <> Browser/Client (where whole json payloads are sent and encoded/decoded over the wire) Where new state means re-fetching all the state each loop instead of just what changed. The amount of data sent over the wire by default is massive with this React + HTTP/JSON model. The encoding/decoding of JSON and having to send full payloads then having state management occur in multiple places and languages - it ends up being a lot more to know and think through. The lines of code to write and amount over the wire with the classic JSON over REST + React/Redux makes it almost 100% required to have separate front/backend developers which then means coordination costs for every new feature. So TLDR; React could make sense for complex components you don't want to reinvent the wheel for or when those interactions are complex and client side. Existing web apps with a lot of React code that is too much to port over all at once can be done piece by piece (where I'd recommend heading towards handling navigation in Phoenix/Liveview and components in React).
eric4smith 5y ago
Don’t. Not necessary in 99.9999999999999% of cases and would just duplicate most functionality. And no, your app is not that 0.000000000001%
- RedBeetDeadpool 5y ago
  Just theorycrafting here, not saying I have an app that fits the description. Wouldn't you want client side statefulness if you have an app like an online spreadsheet (google sheets, microsoft excel) that could occasionally lose connection but you still want users to be able to continue working on their document?
  - mrdoops 5y ago
    Yeah offline or complex client side state management is a good use case for Javascript. There are Hooks and Push Events with Liveview for real time integrations with Liveview in those scenarios. In my experience offline requirements are rare and often in mobile scenarios where a native or Flutter-like approach is a good option. Complex client side state or collaborative features might use something like https://github.com/slab/delta-elixir https://github.com/slab/delta-elixir or https://www.inkandswitch.com/local-first/ https://www.inkandswitch.com/local-first/ which is where I'd want JS.

simion314 5y ago

I suggest you add more details, like advantages and disadvantages, and tell us how many years of experience you have working with projects in this technology/frameworks. I am curious about something that works on node buy is as boring but robust as a LAMP stack, I just hate maintaining shit where stuff is already deprecated after just a few years, but upgrading is not an option because there are 100 dependencies and we are in the hell where 10 packages are vulerable but can't be updated, 10 are abandoned and I need to research replacements and somehow make time to transplant them... My question is this, Ruby has Rails, PHP has Laravel or Sympony, Python has Django , what is the equivalent for node backends (something that is old,stable and not a mix of 100 packages from 100 random dudes)?

mrdoops 5y ago
Elixir is modern tooling on top of the BEAM / Erlang Virtual Machine. This is tech that has been running Telecom systems, companies like Whatsapp, Discord, Klarna, and software like RabbitMQ, etc for decades. The core libraries are very active and well maintained. I tend to prioritize "capabilities to build compelling systems" which, to me, means getting to production quickly so user feedback / product-market-fit tests can occur, but then also scaling a team to maintain the application over time because once you've found a good fit its time to grow. To me stateless CRUD isn't compelling. Its too easy - if your app just provides a GUI in front of a database for Create/Read/Update/Delete operations your app is a database not an app and if all it takes for someone to clone your app is 5 minutes of CRUD generators, then that's not exactly a defensible position to build a business on. Phoenix like other web frameworks provides generators and quick paths for your usual Web + Database applications. Run some commands and you've got a web app with database persistence. Everyone can do this nowadays (Django, Rails, etc) What Elixir and Phoenix does better than anyone else is distribution, concurrency, fault-tolerance, and real time streaming. These capabilities are possible because of deep details on the virtual machine level and become trouble for cooperatively scheduled runtimes elsewhere (e.g. Python, JS, Java, Ruby, etc). If you're building something with: websockets, collaboration, chat, i.e. anything real time between many users - save yourself the trouble and look into an Elixir/Erlang solution like Phoenix/Liveview/Channels/Presence. On the human side Elixir has top tier documentation (example: https://hexdocs.pm/phoenix/channels.html#content https://hexdocs.pm/phoenix/channels.html#content) - we've found it doesn't take long for developers with at least a few years under their belt to pick up the language/framework and be productive. You don't have to know everything - just build some familiarity of where to look and you'll figure it out. Its very important that this human side be scalable as well, and that means developer experience, documentation, on-boarding, etc. I've been using Elixir/Phoenix every day since 2017 to build apps, glue systems together, rebuild Ruby/Rails/PHP/Python apps that don't scale anymore and in general just ship features on time consistently. The thing that I'd toss in as an "it depends" on the technical scaling side is Postgres - its a boring single server relational database that just works but is still a single server architecture made for spinning disk persistence. SSD/NVME/Persistent Memory and more are new foundations for persistence which means new databases on the new foundations may warrant attention soon. 99% of the time just use Postgres/MySQL though. If you're not sure just use Postgres. For many apps in finance or with stringent auditability that are log-centric using a time series and/or event sourcing database makes sense for the projection / read model flexibility. That said you can use Postgres for that so there's no good excuses for not using it. I'd say the biggest disadvantage/con to using Elixir/Erlang is that its more of an expert's tool-set. These are sharp tools made for engineers that make sense to engineers with experience to know they want fault tolerance and concurrency. What this means is that a newbie developer might not know what they don't know they want to know when building an app the first time. This caveat is probably true with any tech stack, but there will be a lot to learn about the backend because there's more possibilities on this backend stack. These backends-as-a-service (Firebase, Hasura, etc) will get things rolling quickly but in my experience all the real juicy core problems of your business will end up in backend code and when that happens you'd better hope those quick solutions don't get in the way.