Using bandit with postgrex directly for rest api?

Questions / Help
,
1

Hi all,

I’m experimenting with using Bandit as the webserver and Postgrex directly for a REST API without any framework layer.

Background:

We have an older app with a lot of plain SQL that we want to transition incrementally. Keeping SQL as-is to reduce risk.

Our VP wants the team to learn Elixir and OTP, and he has a strong philosophy: you should know every line of code you write — no abstractions. Phoenix would be nice, but right now it’s not an option.

Is anyone running Bandit + Postgrex directly? If so, any tips on:

· What to look out for
· Issues you faced
· How you manage the connection pool

Thanks!

2

I have a strong philosophy too:

If some higher up would tell me something like this I would update my CV and start looking.

4 Likes
3

That’s an interesting take, though I’m really trying to gather practical insights about this approach rather than broader philosophy.
Any technical feedback would be helpful.

4

I understand that Phoenix does a lot for you but you could you at least consider using

5

OTP is already an abstraction. So why are you allowed to use OTP but not phoenix? Why not reinvent OTP as well while you are at it?

The point I’m trying to get across is that this endeavor will not be fruitful, and you will end up building a half-baked, semi broken version of phoenix. Critically: one that was built by a team who just learned Elixir.

Does that sound like a recipe for success to you?

1 Like
6

Thanks for the input. I think we’re working from different assumptions, so I’ll leave it there and focus on the technical side.

7

Thanks for the suggestion — we’ll definitely explore Plug and see how it fits our setup.

8

Bandit only works with plug for handlers anyways. It doesn‘t have a separate bandit specific handler abstraction.

I‘d still go with ecto, even if you just use it as a means of having a repo to issue sql queries against. But it‘ll be a less harsch to move once you want to use more of the toolkit

2 Likes
9

That is stupid philosophy, because that is the reason why we have programming languages - to have abstractions. In modern computing it is that even when you write assembly directly you are using some form of abstraction on top of “real hardware” because of microcode.

Abstraction is there to make expressing ideas easier rather than focusing on internal workings of the stuff. Digging too much into details of how stuff works IMHO sometimes may harm your creativity, expressiveness, and sometimes even performance of your system.

1 Like
10

NIH-syndrome?

To be honest, this philosophy usually ends up in having to keep more in the head than just using phoenix.

Sure, using “vanilla bandit” will also work, though depending on the scope of the application, you will eventually ending up writing your own abstractions, which any new team member had to learn, making their onboarding more complicated.

While with phoenix, you can just assume, developers know it, or will at least be able to a “blog in 15 minutes” tutorial before having their first day (or even. on their first day) and be able to understand the most important concepts.

2 Likes
11

Edit:

Thanks everyone for the responses — I want to clarify the context. We’re exploring a greenfield Elixir service alongside our existing homegrown C application with embedded SQL. The team comes from that codebase, so auditability and traceability are baked into how we work. Keeping the stack small is a deliberate choice, not a gap in awareness

12

Phoenix and open telemetry probably give a better out of the box experience related to traceability as you’d get with some self built bandit based app.

At the same time, phoenix and the full stack are well known and covered by CVEs if necessary.

If your app remains small, not more Han a couple of endpoints bandit might make sense, but beyond that phoenix will give you a massive productivity boost, as it removes the nasty boilerplate.

If you want to use modern features in your apps UI phoenix with live view is just unbeatable.

1 Like