Lightweight Elixir web framework?

ricosuaveyatusabe

I’ve already used Phoenix several times, but I’m interested in your thoughts about Elixir frameworks similar to https://javalin.io or http://sparkjava.com/ if there is any. I can’t find too much info about this, I only find info about Phoenix.

31 comments

/phoenix #web-frameworks

1 13515 31

2018-07-23 19:41:16 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

alco

Using just Plug as your web server may be enough in a lot of cases.

Most (all?) Elixir libraries designed to be used in a web app provide a plug out of the box. So if you find Plug lacking some functionality you need, it shouldn’t be too hard to find a library that implements it.

Post #1

sneako

You can pass options like --no-ecto, --no-brunch, --no-html to mix phx.new in order to leave out parts of Phoenix you don’t need. What exactly is not lightweight enough for you about Phoenix?

Post #2

ricosuaveyatusabe

Do you think something like this? https://m.alphasights.com/simple-web-servers-with-plug-and-cowboy-34f7a174f252

Post #3

ricosuaveyatusabe

I already used this for implementing a RESTful API using a Neo4j db. Pretty neat. I just wanted to checkout if there was any alternatives out there and give them a try.

Post #4

AstonJ

Phoenix is already a lightweight framework

We do have other frameworks in Elixir, but I would say that generally they exist to offer different styles of development.

Also, in case you didn’t know, Phoenix has been described as ‘more than just a web framework’ in the sense that it can be used as a thin layer inside an Elixir app… multiple times

If that interests you, the legendary Dave Thomas goes into detail about it in his online course.

Post #5

ConnorRigby

Nerves Core Team

I’ve built myself a “lightweight web framework” with plug+cowboy for Nerves devices pretty frequently for things like configuration utilities. Once you build in ecto and templating, you’ve essentially got yourself what you get from mix phx.new --no-ecto --no-brunch but it doesn’t have the same level of maturity/usability as the phx.new version.

That being said it isn’t particularly hard, and it can be kept to about one/two + templates which is nice.

Post #6

idi527

As a note to anyone implementing .eex templating with just plug, don’t use the default eex engine, it’s quite inefficient since it just concatenates binaries – instead, either write your own .eex engine or use phoenix’s one for html to handle the templates as iodata.

It’s also important to understand what exactly is the goal of “lightweight”, if it’s to reduce complexity, then plug won’t offer much against phoenix, especially if you use --no-* flags as people above have mentioned; if it’s to improve performance, then from my benchmarks with tsung for websockets and wrk for http/1.1 from last year, the biggest improvements were not from picking plug or phoenix, but from changing the underlying webserver from cowboy to something, well, more performant (like a modified version of elli).

modified version elli?

The most important modifications in terms of usability and performance that I made were:

for http/1.1: support for plug. Since plug is modeled to work well with cowboy, elli needed to be modified a bit to work both with plug and metrics collection callbacks. A simple way to add plug integration into elli without forking elli would be to “handover” the request to a plug adapter in elli_http:handle_request, but then some request timings would be lost.
for websockets (websockets support is not included with elli, actually, but rather comes in an extension): that extension was again modeled after cowboy and used :inet.setopts(socket, active: :once) which was inefficient for big messages, so instead I :inet.setopts(socket, active: false) the socket whenever a packet arrived, and read it with :gen_tcp.recv “manually” untill it was over, and switched back into active: :once only then. Not sure if the current cowboy’s websockets implementation has this “optimization”. Seems like it doesn’t and stream’s read_body still uses messaging (in addition to then sending messages once again from the socket process to the stream process? not sure) which is quite less efficient than :gen_tcp.recv.

Post #7

Nicd

Also check out Raxx and Raxx.Kit (kind of a boilerplate for Raxx I think). They’re on roughly the same abstraction level as Plug, but have a bit of a different philosophy.

Post #8

Crowdhailer

Creator of Raxx

Agree to, respectfully, disagree.

It may be lightweight for the machine, i.e. performant.
I don’t believe it to be lightweight in terms of concepts to learn or conventions assumed.

Most of the concepts and conventions are very helpful but hard to work around if you are going a different direction. An issue that is standard for anything that hopes to be “batteries included” Frameworks vs libs + from scratch

Post #9

josevalim

Creator of Elixir

I would love to hear examples about this in regards to Phoenix. I.e. something you wanted to take into a different direction and it is getting in your way.

The only one on top of my mind is getting connection parameters in your sockets, but that is being fixed for v1.4.

Post #10

Load more posts (21 remaining)