Using lightweight libraries/tools instead of Phoenix

You should be able to get something quickly up and running using Plug (Plug.Router in particular) and Phoenix.Template+Phoenix.HTML (if you are doing HTML stuff). If you are doing APIs, then you will need Jason and a handful of helpers such as json/2, which receives the connection, data, and renders it as JSON. For queries, you can use Postgrex directly.

Thank you @josevalim for quick reply.

Why would you recommend using Phoenix.Template+Phoenix.HTML instead of plain old EEx? Can’t I just go with EEx for some reason?

And for Postgrex it seemed to me at first that it’s not that easy to use transactions and pooling (need to use ecto-dbconnection for that). Do you have any good guides for that? Also database migrations seem to require ecto-migration.

If you just want to run plain SQL you can use your database driver directly - for example, when you use PostgreSQL, Ecto uses postgrex under the hood. You could also try Erlang’d ODBC, I haven’t used it personally yet though

As for light-weight library suggestions for the HTTP server itself, I’ve recently had good luck when building a simple mnesia benchmarking tool with using Erlang’s built-in HTTP server with mod_esi. You basically need to start :httpd with a config that tells it where to find your Erlang Script Interface (ESI) modules (Erlang Syntax):

    ServiceConfig = [
        {port, 4000},
        {bind_address, {127, 0, 0, 1}},
        {server_name, "mnesia_bench"},
        {document_root, filename:join(Here, "public")},
        {directory_index, ["index.html"]},
        {mime_types, [{"html", "text/html"}, 
                      {"css", "text/css"},
                      {"js", "application/javascript"}]},
        {server_root, "/tmp"},
        {error_log, "error.log"},
        {erl_script_alias, {"/esi", [mnesia_bench_esi]}}
    ],
    {ok, _Pid} = inets:start(httpd, ServiceConfig),

then if the mnesia_bench_esi module exports a function create_table/3, you can call it from your browser at the URL /esi/mnesia_bench_esi:create_table. I found this pretty simple to quickly build something with, and :httpd is pretty configurable, but it won’t compare with Phoenix of course

You can, however template engine used by phoenix first of all is html aware and secondly it generates safe escaped html so you don’t have things like XSS attacks.

Yeah it’s this bit specifically that makes EEx on its own a non starter for any app that will display user data.

An alternative over “raw” postgrex is to still use ecto, but only set up a repo and do migrations with it. You can do Repo.query or Repo.all(from u in "users", ...) and skip all the schema / changeset stuff if you want. This gets you all of the valuable things ecto does from a safety / migration / core ergonomics standpoint.

Thanks for the tip, already checked Phoenix.HTML code and it should be really trivial to take only relevant parts from there. For example form/tag builders are not needed when using “boring technologies”.

This is maybe too low-level already, but good thoughts anyway. I’d prefer Plug since it also offers Plug.Test and other nice things while still being quite low-level, but not too low.

IMO about 80% of the developer effort spent on “keeping things lightweight” is waste; there was a huge fad back in the day of people going to incredible lengths to prove “they didn’t NEED a framework” that led to a lot of hard-to-maintain messes. I’ve worked on at least one $BIGCO codebase where they started by embedding Sinatra “to make an efficient API” then welded every other Rails feature back on.

IMO it’s good for everybody, because people farther along in their coding career should probably be thinking about “how to solve the customer’s problems” and less about “how to shuffle around some files”.

I’m only weighing in because you say you like “boring technologies” and the whole reason I use LiveView is because I consider it a “boring technology”. It gets out of my way more than any other framework I’ve used and is quite a bit simpler than controller+view. There are also fewer things to learn than in other frameworks. If you’re used to building apps with “sprinkles of JavaScript” it even abstracts away most of those sprinkles (what’s less than a sprinkle? lol). Also, LiveView templates are server-rendered. I would at least give it a chance!

You’ll end up reinventing a smaller buggier Phoenix IMO.

I too think Phoenix can be too heavyweight on management – several different files in the right places, magic configurations with several levels of lists and tuples, code generators that historically have ended up producing outdated code you have to manually upgrade, and others I can’t remember right now – so I’ve been in projects where we’ve only used Plug for routing. However, these projects were serving JSON and had zero visual parts.

As much as I feel working with Phoenix is boring and annoying, it’s probably one of the best things we have on the planet in the web area.