Where should an FFI live?

[regal oxide]

I'm realizing as I write a FFI to an Elixir lib for a Gleam webapp that if there is another Gleam app that the FFI logic could be useful to other projects. It feels kind of weird that the FFI lives only in my Gleam app.

I think the tough part is that I'm the Elixir library author and the Gleam webapp author, so I'm having a hard time drawing the line. In my other question someone said that the library author shouldn't be responsible for the FFI --and I agree --but in my case, the FFI is just more Elixir code that translates the data into a shape that allows it to interop with Gleam.

So, where should the FFI live? Is it something other than an FFI if it doesn't live in a Gleam project? Are there Gleam libraries specifically for providing a FFI to Elixir/Erlang libs?

I'm curious to hear what others think and what the "best practices" are.

[shy pawn]

the FFI is just more Elixir code that translates the data into a shape that allows it to interop with Gleam
this is what most ffi is in gleam really

usually ffi lives directly next to the gleam module that the rest of your app would use, so if you had wibble.gleam you might expect to see a wibble.ffi.mjs or wibble_ffi.erl alongside it (idk how elixir modules are named but you get the point)

Are there Gleam libraries specifically for providing a FFI to Elixir/Erlang libs?
in my experience these libraries are often quite bad because they try to provide bindings to something that already exists vs start from a nice gleam api and using an existib lib internally

[regal oxide]

Hmm, interesting. Thanks for the insight. I'll just leave it to live in my Gleam app, then.