smedegaard
I’m pretty new to Elixir. I’ve read some books, done a Udemy course, done some exercism and hackerrank problems and started on a Phoenix app.
I was a happy camper, but following the Elixir buzz on this forum, Elixir Fountain and other places I started getting the feeling that the “1.2 way” of doing Phoenix apps was kinda frowned upon by some people.
So I stopped development on my Phoenix app and read a bit more about OTP, watched Chris presentation of Phoenix 1.3 a bunch of times, bought and started reading Lance’s new prag prog book and tried to apply those thoughts and ideas to my app.
Now i bassically feel like a poor noob that is getting told that
“You probably don’t need a database”
But I really can’t see how anything else but a live session kinda thing like a game or a chat could work without persisting data in a database.
Am I misunderstanding this totally? Are there any other poor noobs out there that are getting the same vibe?
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tyro
Well, it really depends on what you are doing. There’s no one size fits all solution here. That said, I reckon most web apps do use, and do need, at least one database.
With regard to phoenix, there are certainly some new ‘best practices’ in 1.3 but they don’t concern whether you should use a db or not.
Most Liked
NobbZ
Well, most of this thoughts about not needing a database assume a basic thing: You never shut down your application.
If this is a fact and you can guarantee that it will never shutdown, then leave DBs completely.
But since you can’t guarantee zero downtime, you have to persist your data somehow.
To persist your data and getting it back into your live system, you have a couple of options:
One of the most important things to remember to understand that mantra is, that it means “you don’t need the database as primary source of truth, but it may be a valid backup strategy”.
gwww
DB, no DB. Uncle Bob has much to say about that:
And:
easco
I wonder, perhaps, if you are misinterpreting something that I perceive as a main theme of Phoenix 1.3.
I gather that in Ruby on Rails, there is a tendency for the persistence mechanism (ActiveRecord) to pervade an application in a way that the logic of the domain model that the application operates on becomes entangled with the persistence code. As a result, I have been lead to believe that it is common when writing an Rails App to begin solving any problem by figuring out how you are going to squeeze that problem into the database. (as with most things, probably true in some cases and untrue in many)
I gather from the 1.3 presentation, that for various reasons (one of which was the generated code that Phoenix produced) some Phoenix 1.2 apps started to show this unhealthy trait of the persistence driving the domain model of a problem. As I understand it, one of the main aims of Phoenix 1.3 is to help developers keep a healthy separation between their domain modeling code and the code used to persist elements of that model.
In that case the warning is “Don’t start solving your problem by designing your database”. Start by creating code that models your domain and solves the problem. Then, if you need to persist data, find a way to do that. A database might be one good choice among many.
Last Post!
AstonJ
@NobbZ’s post sums it up for me:
If it’s data you don’t mind losing in case of a system/power failure (such as temporary user settings) then there’s a good argument not to persist. But if it’s something like User account details, then I would persist.
Also, as you’re interested in application architecture I highly recommend PragDave’s online course - it’s sparked some really interesting discussions about approaches to development in Elixir.