sashaafm
Embedded Elixir/Phoenix in a webpage vs. Frontend communicating with a Phoenix Backend
I’d like to know what are your opinion between building a Web App using embedded Elixir/Phoenix (.eex files), where the data is being passed with the render function to the template, like so:
<%= if @var do %>
It is obviously true
<% else %>
This will never appear
<% end %>
vs. separating the frontend (with Javascript and AngularJS maybe) from the backend, using Phoenix to serve a RESTful API:
$http({method: 'GET', url: '/some/phoenix/api/resource'})
What are the advantages and situations where each one is better suited? Are there any use cases where they should be mixed? (particularly does Phoenix mix well with Angular?)
For a simple information system, I think embedded is more than enough but for more modular, better structured and to allow frontend and backend developers to work concurrently the latter is better. Also, separating makes the backend development easier since you just have to build on the :api pipeline instead of both :browser and :api pipelines.
The main disadvantage (for me at least) when separating the frontend from the backend is to have to use a lot of Javascript which I personally hate and find difficult.
Most Liked
OvermindDL1
Well using embedded it is significantly easier to internationalize if that is important for your project first of all.
Personally I would go with embedded regardless unless I want/need a single-page-app, in which case phoenix would just be an API endpoint.
zimt28
I’m currently rebuilding an SPA app, which I had built in Meteor using Phoenix. Rendering things on the server again, like I’ve done “in the past” makes things so easy again! Also, comparing the two, the SPA solution didn’t feel or responds faster. There are some places where I need JS, but I will just use Vue.js or so where is makes sense.
Just because everyone builds SPAs now doesn’t mean it’s always the best solution!
andre1sk
Last Post!
ibgib
I think this is a great idea. ![]()
I’m in the middle of deploying the first stab at ibgib (v0.1.0) which uses server-side rendering + plain vanilla js (mostly relying on d3.js) to simplify development. But I inevitably need a real solution on the front end, so I’ve been keeping a watch on this thread and others similar to it.
So your idea of a slightly more formal wiki of the landscape would be a big help. I would only hope that in addition to what “should” be a good stack, that we also encourage anyone who lists in the new Showcase category to include what they are actually using WRT front end and how they communicate with the back end (channels/sockets, json api, etc.). This way, we could see real world
examples of the end result of the stack.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









