Lightweight Elixir web framework?

It’s interesting that you brought this up - I’ve been wondering for a long time why Elixir doesn’t have a sinatra clone - almost every language (especially “ruby descendants/inspired” languages) has some some form of sinatra clone.

I’m also perfectly happy with phoenix and think it’s light weight enough, I can restructure folders etc. however I like but I often think about building a sinatra clone for fun and for getting more used to macros :grin:

1 Like

I think it’s precisely because of what José suggested: Phoenix doesn’t really get in your way when you build your application.
It doesn’t force you to write your code a certain way or use specific libraries for things that are unrelated to its core functionality (serving HTTP and Websocket requests).

3 Likes

True that - one of the many reasons I really like phoenix.

Sometimes I still think that a sinatra like library might be nice (although as many people here mentioned you can just use plug instead) - i.e. for teaching or really small projects (let’s say a little chat bot).

I probably underestimate the effort to make a good sinatra clone though :slight_smile:

I think, in a way, Plug.Router already exposes a sinatra-like DSL, so there’s no separate package - most people looking for something like that find it enough.

4 Likes

This might be of interest to you if you want to build something using Plug. German Velasco is a great guy, I used to work with him at thoughtbot, and he breaks it down very nicely:

Build your very own Web Framework in Elixir

6 Likes

Some people might have inferred from the OP’s post that Phoenix wasn’t a lightweight framework, whereas I think the general consensus is that it is :slight_smile:

Had they asked for a ‘simpler’ framework I might have asked in what way since Phoenix itself can be used in various ways; from a simple (albeit more majestic) monolith (so pretty easy for anyone coming from Rails to jump into), to the default (more ideal) path using Contexts and pushing the Phoenix is not your app mantra, and then of course this can be taken to the extreme, where Phoenix is used as a layer (or a number of layers) inside an Elixir app which itself is built as a series of components (as per Dave’s course). I actually really love that Phoenix is flexible like this and I can definitely see me using it in all three of those ways for different kinds of apps :003:

I probably would have also included links to RaxxKit as something worth looking at, but in all honesty I really do not know enough about it other than it seeming to be more like Ruby’s Hanami which is comprised of several micro-libraries (I can see the benefit of something like that in Ruby, but am, as of yet, unsure where it fits in the Elixir world). Perhaps you can help with that - I don’t think you ever got around to answering my questions about it which would definitely help people see why it was created, where it fits into the Elixir landscape, its pros, cons, and when someone might want to use it over other frameworks :023:

1 Like

This might be of interest to you if you want to build something using Plug.

It would be quite less efficient than the default phoenix setup since he used the default EEx engine for templates which just concatenates binaries instead of using iolists. It’s the mistake I’m seeing most often when people try using plug.

Still, a great introduction.

1 Like

The comparison to Hanami is probably quite good as I have been following that projects development . HoweverI’m not trying to make a phoenix vs Raxx case here.

Raxx.Kit obviously has it’s own set of assumptions/conventions and as I mention whenever possible I have been using both in production for over a year now and each has their place.

What I find more curious is the goal of phoenix to be both lightweight and batteries included. Trying to optimise for both has always seamed ambitious to me and prone to compromise even if that compromise is just mixed messaging. Anyway the consensus is not with me here and I am happy to let that continue.

I will answer your question in that thread

1 Like

At work we toyed a bit with just Plug+Cowboy for “HTTP API” style apps, but everything turned out a bit differently. The last couple of projects, we just generated a Phoenix app with all the --without options, then take an axe and kill the foo_web/foo stuff, remove everything else we don’t need, and then have something that - if needed - can grow back into something full-fledged but it simple, minimal, and understandable; developers that just did a Phoenix read-through will know where to find everything but it’s still very light-weight. Just checked one project, cloc says there’s 125 LOC in the Phoenix bits.

One of these days, I’m gonna whip up something that just generates this minimal thing :slight_smile:

4 Likes

What is your ultimate goal though? Smaller .beam files? Performance gains? Easier to recover from exceptions (I don’t quite get that.) Another coding style? (I think we can all agree this is subjective but worth the effort regardless if you find yourself more productive in the end.) I understand the argument for a Plug replacement that deals better with sockets and channels – carrying easily accessible metadata at all times if I got it correctly – but outside of that I seriously can’t understand what is it that Raxx does better (and I think I spotted Jose or Michal saying the next Plug / Phoenix will address these issues Soon™).

I have been reading your posts and comments last month or so and I still cannot understand what is your objection to Phoenix. I am not raining on your parade. Maybe I am just dumb and can’t grasp the idea. Will you help me understand? (I did read your threads here btw, but not your blog.)

Maybe you don’t but you have been repeating that Raxx is better suited for certain use cases and I am yet to see something that will convince me of this claim. Do you have a quick and self-explanatory example that shows when Raxx is a better fit than Plug / Phoenix?

As @cdegroot mentions, you can very easily reduce Phoenix’s generated files and still use most of it (and most of its “boilerplate” are optional convenience helpers anyway, they are not mandatory the way Rails makes most of itself mandatory if you wanna use it).

This is not about democracy or consensus. Give us pieces of info that help people make an informed decision. Alternatives are good, they challenge the thinking of people and make them see new horizons.

2 Likes

I’ve been playing with a toy Phoenix project lately, and manually tore out the Postgres Repo stuff, but kept Ecto because initially I wanted to generate UUIDs and it was convenient for that. Now I’m finding Ecto’s Schema and Changeset modules very convenient for request parameter validation–they let me build up a list of validation errors and send that back to the client.

Phoenix’ modular nature is quite nice for exploration and finding serendipitous uses.

2 Likes

I will try and make the time to add a Goals/motivation section to the Raxx readme in the next few days that I can reuse. For the moment my talk from elixir daze I think is my best explination.

For this conversation maybe I will try approaching from another direction. Quote from the original question.

@ricosuaveyatusabe what was the trigger for you to ask about lightweight alternatives, when you were already familiar with Phoenix?

2 Likes

@Crowdhailer
Doing things really quick for illustrating examples and things like that. Not having to spend time in explaining Phoenix or just assuming the reader already understand Phoenix. Just coding something simple like get("/users) calls i_dont_care.gimme_users(). This helps me coding examples in the most language agnostic way.

1 Like

They’d probably accept a template that is full of commented code that says things like Uncomment this to do Blah <link here> and so forth. :slight_smile:

In the meantime, a colleague scratched our own itch during our last hackday using exgen which seems to be either very unmaintained or very stable - a quickie PR made it work for us and we now have that very minimal phoenix(+statix, +our stuff like circle, nomad job files) core we can build out a service from. Works quite nicely and saves me from going through the trouble of somehow tacking more options on phx.new :wink:

1 Like

Reminds me of this https://pragdave.me/blog/2017/04/18/elixir-project-generator.html

1 Like

Yup, it’s probably the same. The hard part here, of course, is not creating the solution but maintaining the templates :wink:

1 Like

I’ve been thinking about these discussions, and it occurs to me that a good way to describe Phoenix might be as a thin & light framework built over a rich & powerful set of libraries.

That’s a less-verbose and perhaps easier-to-understand way of making the point that Phoenix does not hide things behind “too much” magic, does not have “too much” coupling between components–thus not “too hard” to figure out how components are used, and remove them or tweak the usage of them.

1 Like

I am always about to say “Phoenix is a handful of libraries and some conventions expressed in the skeleton code it generates” but then I’m afraid that “convention” might have bad associations since Rails…

1 Like

Just tried it.

.
./mix.exs
./rel
./test
./test/support
./test/support/conn_case.ex
./test/test_helper.exs
./lib
./lib/api
./lib/api/application.ex
./lib/api/error_view.ex
./lib/api/router.ex
./lib/api/endpoint.ex
./lib/api.ex
./README.md
./config
./config/dev.exs
./config/config.exs
./config/deploy.exs
./config/test.exs

Are the relevant Phoenix parts we spit out. Also, in api.ex we just have the controller and router macros left. cloc counts it at 180 lines of Elixir code.

To me, the best thing is: it’s still Phoenix! And we can grow templating and channels and whatnot right back.

2 Likes