Crowdhailer
My opinion very much undecided on this Question so all comments welcome.
This is probably best discussed using the concrete example I am considering at the moment in Raxx.
(Raxx has the goal of being a capable toolkit for developing lean web applications in Elixir.)
For simple endpoints applications implement the Raxx.SimpleServer behaviour.
Simple endpoints are when streaming is not required for either request or response, if streaming is required then the Raxx.Server behaviour is implemented
A simple example would look like the following.
defmodule MyServer do
use Raxx.SimpleServer
@impl Raxx.SimpleServer
def handle_request(%{method: :GET, path: []}, _state) do
response(:ok)
|> set_header("content-type", "text/plain")
|> set_body("Hello, World!")
end
end
The line use Raxx.SimpleServer defined a default implementation of handle_request/2 which any application is always expected to overwrite.
The default implementation shows a page that explains what a user should be implementing, and this is done to help users.
https://github.com/CrowdHailer/raxx/blob/master/lib/raxx/simple_server.ex#L105-L111
I am no revisiting this choice for the following reasons.
- behaviours create a compile time warning when one of their callbacks is not implemented,
this is lost by implementing a default. Any mistakes are found only at runtime, hopefully by tests. - Safely generating this page required adding a dependency on eex_html, this dependency is included only to render pages that should never be rendered in a correctly set up application
- These helper pages are useless if the client is not a human. i.e. when making api services.
In summary I am thinking of removing this default because a compile time warning is more useful than any information that might be show at runtime in the page, and in any case is just a copy of the information available in the documentation
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
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
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
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.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
If you want to have a descriptive error page I feel it’s in the same realm as the phoenix error page with the debugging information: Enable it in
:dev, but fail for other environments.dimitarvp
Ignoring warnings when compiling dependencies is fine but one should not ignore warnings in their own code – and warnings about non-implemented callbacks are important.
IMO get rid of the help page for exactly the reasons you mentioned.
@LostKobrakai has a point as well; you could keep the current behaviour in
:devenvironment only.OvermindDL1
What phoenix does in such cases (like router callbacks into controllers and so forth) is it has a ‘jump’ function (
actionI think?) that is what actually calls the appropriate method, and if it throws, like it doesn’t exist, then it reports it as such. This means you don’t get compile warnings though as it’s anapply, however with macro work to ‘bake in’ the calls without usingapplyyou could get the best of both worlds? It would require making a pre-call function in that same module and calling that instead, and having it call the real function that needs to be overridden. That would give both a warning, maybe even an error at compile-time, but if such a thing does somehow make it through then it would give a good message.On the other hand, making a public function with a (mostly) uncallable name that just calls the functions that needs to be implemented locally then it wouldn’t compile if they didn’t exist, but you’d need to craft good default data to let dialyzer handle it properly and that can be pretty hard to do without taking ‘opaque’ arguments in (this function would never actually be called, it’s sole purpose is just to require those functions).
Although at that point you could just analyze the module
info(:functions)at compile time from the thing that calls those implementations and verify they exist first, but that would involve requiring those files to be compiled first and the beam files to be scanned.Honestly, I’d say just implement a behaviour, no default implementations, and let the compiler handle it as normal.
josevalim
FWIW, we have been slowly migrating away from default implementations and using optional callbacks instead. If the user wants warnings, then
@implis the way to go. There is an old discussion about it here: Behaviours, defoverridable and implementationsCrowdhailer
A lot of smart and interesting solutions there. thanks.
But I think I also agree with your summary, let the compiler handle it.