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.
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’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.
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.
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"