mmport80
A Database-less App Framework?
I suspect many apps these days have enough memory available for many tasks.
The problem with applications is that they crash and lose memory, so you need some storage, but we have Mnesia etc.
After the recent talk about component and design etc. I started thinking about this.
Could you have a ‘Phoenix’ with an Elm / Redux like architecture and backup state every so often to disk (automagically).
Of course you could include DB reliant features, but by default state would be backed up in the background.
I suspect that would simplify things quite a bit (perhaps too much - but at least you could get up and running quickly).
Perhaps this already exist in other frameworks?
Most Liked
hubertlepicki
Okay, well not always. Try implementing in-memory joins / mapreduce on your virtual actors to filter them out to some subset matching given criteria, and then compare the speed to your SQL query that’d do the same. Or implement a full text search and compare it with elasticsearch.
Generally SQL/database will likely to be quicker when you need to deal with querying large data sets, and in-memory solution will be quicker to access to individual ones.
cmkarlsson
We are talking about state here. In my opinion if you have business data that needs to be persisted you should be using a SQL database. I also think that you should design and manage this outside of an application context. I.e use SQL scripts for DDL and migrations.
The business data is likely to outlive your application by a big margin. Having this completely separate from the app will make it much easier to maintain in the long run. Perhaps after 5 years you want to use a completely different framework. Your business data though is still the same and by having it managed outside of the application makes this transition much easier. You can also add multiple different applications to your data without having the design choices of one framework affect any other.
On the other hand. If the data is only there to help run the application and not a thing in itself then the database-less approach is interesting. This auxiliary data can be stored in many different ways and can be quite tightly coupled with your application as it is more there to help the application than being data you care about in the long run.
A third type of data would be ephemeral data which can be recreated at any time. This is usually stored in memory can can be recreated when needed.
Likely your application will contain all three and there may some overlap between the three. What I think is important is that business data and the auxiliary data is loosely coupled. On is the core of your business and the other is just there to help.
AstonJ
You might like this post from Joe Armstrong:
And the discussion that followed:
Popular in Discussions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
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.
Real-time error tracking, performance insights, and observability for devs.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"