Is it possible to program backend with pure elixir (direct SQL in BD) without frameworks? What are the challenges or problems?
1 Like
Hi Megatomic! Welcome to the forum!
There’s no need for any specific library or framework to make a backend in Elixir, it just means that you have to make more decisions about what conventions and patterns to employ, and you may need to implement some functionality that the frameworks might otherwise offer.
At my previous workplace we had Elixir services that didn’t use the Phoenix framework or the Plug webserver abstraction, instead we just used the Elli web server (which has a very simple interface). We could have also done the same with Cowboy if desired.
The Raxx web server would have also been a good fit, we went for Elli as Raxx didn’t have middleware at the time.
The service that had a postgres database used Ecto, though if writing it again we might have instead opted to use the Postgrex library directly as we didn’t find Ecto offered much in that specific use-case. Our tech stack was quite diverse so we found that keeping things as simple as possible and using as few libraries and macros as possible made maintenance and on-boarding easier.
So yes, it is possible to implement a backend in Elixir without frameworks.
What’s a BD? 
5 Likes
Sure, as another example, I use Phoenix for routing etc, but not ecto: phoenix + postgrex.
1 Like
PostgreSQL
I intend to use PostgreSQL
tnks
Postgres is a RDBMS, relational database management system. I’ve not yet heard someone classifying it as a BD.
Could you therefore elaborate on that term?
1 Like
Sorry: a failed act at writing
BD = DB
BD in portuguese, DB in english (DataBase)
6 Likes
Hi @Megatomix,
I don’t see any blocks that would keep you from interacting directly with a database, without using a library. I also don’t see a good reason to not use a library such as Ecto, tho. Why would you like to do such a thing?
By the way, the answer for your question is YES. It’s completely possible to interact with databases directly. You would still have to deal with the issues that libraries like Ecto solve, but assuming you have a good reason to do so, and your preference for Postgres, I would advise you to take a closer look at postgrex, the package that allows you to interact with Postgres using Elixir.
2 Likes
Yes.
Less pleasant API and that will probably be it.
1 Like
And crying yourself to sleep because you don’t have proper queries, joins and aggregations which you will inevitably need no later than two weeks in the project. 
SQL query builders such as Ecto are just one approach to querying a database, other options are available, and in some other ecosystems these options more popular.
Personally I am a fan of writing plain SQL and have written a small library to make this a bit more convenient in Elixir. GitHub - lpil/yesql: An Elixir library for using SQL.
9 Likes
??? You have SQL, which has joins, aggregations, etc. Not every project needs an ORM to simulate “object” coming from the db. Some (think utilities) work perfectly well sending queries to the db and getting back an array of maps.
3 Likes
That’s perfectly in the realm of ecto. It can do quite a lot even without writing a single schema and even schemas are more a typed map than “objects coming from the db”.
1 Like
What was discussed was “could we not use a DB at all”, which I interpreted as “can’t we just use GenServers / Agents for data storage” – in which case you lose all the benefits that a SQL interface would give you otherwise.
I misunderstood the comments above mine but this is what I was talking about. I see now that people were discussing “SQL without frameworks”. Oh well, my bad.
1 Like
Ah, now your comment makes sense–you are so right about not using a db…
1 Like
I’m actually a beginner in development, and I’m, let’s say, lost with so many possible paths, and each path with its pros and cons - and many frameworks that take you to the same destination, so I’ve chosen the most direct path possible, and in my modest opinion, to use things in native language, would be those way!
As I said, I know some things will take longer without using the framework shortcuts, but I bet in the future, knowing how to use the pure concepts of each language will help me better use frameworks when I’m ready for them!
Or not ?
1 Like
If you are a beginner in development I would highly recommend using a framework like Phoenix - it makes a lot of sensible choices for you and so will save you a lot of headache - saving you from having to research all the different paths/approaches etc.
I would ask, why not use a framework? If you don’t have any pressing reasons not to use a framework, I would say use one 
4 Likes
It is also easier to go from framework to direct, just treat the framework as a proof-of-concept work. Once you have a stable set of features you can decide if rewriting to direct SQL makes sense.
Often times starting with direct SQL you find yourself adding features until it starts looking like a framework anyway.
With Ecto I do just this :
fetch_all(
"""
SELECT name, first_name
FROM users
WHERE category_id = $1
""",
[category_id]
)
defp fetch_all(sql, params \\ []) do
rs = Ecto.Adapters.SQL.query!(Repo, sql, params)
cols = Enum.map(rs.columns, &String.to_atom(&1))
data =
Enum.map(rs.rows, fn row ->
Enum.zip(cols, row) |> Enum.into(%{})
end)
end
defp fech_one(sql, params \\ []) do
case fetch_all(sql, params) do
[result] -> result
_ -> {:error, :not_found}
end
end
It’s far from perfect but it does the job. Beware of String.to_atom
1 Like
The thing is - SQL is native to the RDBMS - not the backend environment.
So you typically end up with repetitive data type conversions SQL <-> native which often leads to an ad hoc framework.
By all means learn SQL first and design your queries SQL first. But once your have those basics down it’s worthwhile to invest some time into something like Programming Ecto just so you don’t have to explicitly deal with even the most basic data type conversions. On top of that you’ll be able to compose dynamic queries much more easily.
Learning and using Ecto without some appreciation for SQL can in some cases be problematic. But once you understand SQL, Ecto can remove some of the annoying, repetitive detail that could otherwise clutter your code.
3 Likes
