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:
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.
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!
Internationalization can be done by creating a json serverside with screendefinitions: language dependent labels, errormessages etc. which can be used to render the ui clientside. Can be done via a phoenix channel also. But I like to have a ui that does not know about the other layers so that I could switch the backend when needed. And I did not care to learn a bit of js.
Yeah that is basically what I’d done, just a map of default strings to internationalized strings for the currently logged in user, defaulting to using the existing string if not in the map. Just feels like a hack.
I guess for me separating Elixir and “HTML” is not so much separation of concerns rather than separation of technologies. I still think server side REST MVC solves 90% of business’ needs, but I’m old fashioned
I mean a json with more than just internationalized strings. Others do it also, see f.e. https://korynunn.wordpress.com/2013/05/20/deploying-a-web-app-in-14-days-no-html/.
The json can be created in a wysiweg gui designer. Extjs had such a thing, which was the base for sencha architect. I don’t know if it still works with this principle. If and how they handle internationalistion I do not know.
I’ve been working on a project that has steadily grown over the last year and a half and I really wish I would have separated the frontend from the backend up front. The larger your application gets the harder it is to manage if you have a monolithic codebase. In addition, it is SOOOO much harder to get rid of technical debt if your app isn’t split into multiple pieces. If you go the modular route its super easy to swap out pieces of code when the winds of developer community preference change. I’d 100% recommend doing a separate frontend and backend. You definitely need to have more technical skill to write a program like that but learning whats necessary to build an app like that will pay you back big time in the long run. That said, if your app isn’t serious, you don’t plan to ever work with anyone else on it, and you don’t expect it to be very big you probably can just roll with a server rendered phoenix app.
SPA for many sites means need to run node on the backend to do server side rendering. If you can get away from the need to do an SPA you can save yourself a lot of pain.
Yep doesn’t change a fact you will have to run node to do server side rendering of an SPA. Your API can obviously be in Elixir & Phoenix but you now have to support running both BEAM and node in production monitor both patch both etc. You also would have to deal with securing much more complex environment with more than double size of attack surface.
I have one SPA in my big application (an inter-campus messaging system integrated into a few local services) with Elm, and no server-side rendering or node is needed at all.
Sure for any app that does not need to be indexed by search engines or when initial render time is not critical you don’t need to support server side rendering.
So you have no problem to get locked into an elixir backend with your frontend. That can be a legitimate choice. I named separation of concerns because I think the responsibility of rendering the client belongs to the client. Elixir is not running in the browser. A lot can be said about this but for now I’ll just copy paste some benefits after googling (saves me typing):
"Keeping server side code separate from browser side code allows teams to:
establish independent release cycles, which:
allows faster development in front-end codebases (which should operate on faster release cycles)
prevent release rollbacks for server-side code when front-end bugs are introduces
maintain clearer distinction between codebases, which:
decreases overall platform learning curve for new developers
improves ability for individual codebases to be thoroughly tested
increases independence from any single framework/architecture"
