Phoenix Wish List

Phoenix Forum Chat / Discussions
,
1

What is your wish list for Phoenix? I wish Phoenix was easier to deploy.

5 Likes
2

That it would removed some macros that aren’t needed and that it would allow greater customisations.

About deployment - I think it is pretty easy, especially since mix release is a thing. People just need to get used to it as it is different from what they are used to in Ruby/Python, as these releases are more like C# assemblies or Java JARs.

6 Likes
3

I want the community to grow even faster as well as contributions to the development and maintenance of third-party packages. More tutorials also on almost everything. ^^

3 Likes
4

I’ve started a project for deployment using mix releases. Right now it only works with docker to build the releases. Having said that, I opted at the time to use mix tasks but sincerely I’ll probably re-write it fully in erlang using gen_statems instead of adhoc task pipelines, and only then add other functionality. It doesn’t have any procedures to “provision” the server itself. I wrote a small group of chef recipes to do that that I can also share if you’re interested.

The readme is a work in progress…

2 Likes
5

We need more resources/tutorials about deployment.

3 Likes
6

Seems like deployment is a recurring theme. I have a tutorial style blog post on creating Docker containers via Mix releases: https://akoutmos.com/post/multipart-docker-and-elixir-1.9-releases/

It also has some things that I consider being production ready (having observer cli for when you need to introspect a running service).

I am always looking for new topics to write about…so if anyone has anything specific they want me to write a post about feel free to shoot suggestions my way (for example deploying Elixir app to K8s using Helm, deploying to raw VM using hot code upgrades, etc).

4 Likes
7

100% on the macro front!!

I recently rewrote some of my Phoenix servers to not use any of the built in macros that just delegate to other macros and instead use each macro directly - it’s so much more readable.

9

A replaceable router dispatch without needing to rewrite the entire Router and all helpers it generates and all. ^.^;

10

What things specifically are you looking for? I think there are a lot of tutorials on how to deploy Phoenix apps. Specifically, tutorials from Gigalixir, Distillery, and the new mix release docs are very good.

It feels like deployment is pretty well covered at this point. Maybe the issue is that there’s a bit of work that goes into it (not a ton), so it’s not 1-click?

2 Likes
11

This is a pretty good tutorial https://www.digitalocean.com/community/tutorials/how-to-automate-elixir-phoenix-deployment-with-distillery-and-edeliver-on-ubuntu-16-04

1 Like
12

Could you post a before/after example? That’d be really interesting to see.

13

I wish it didn’t merge the URL params into the same map as the parsed body when calling actions, it is quite a small thing but it really annoys me particularly when I want to create an API that doesn’t require PUT/POST requests to nest the entity under the entity name.

14

More Books with more advanced samples.
A Bootcamp online, ir will be great!

15

fyi there is conn.body_params and conn.query_params :slight_smile:

9 Likes
16

You can always do something like that:

      def action(conn, _) do
        name = action_name(conn)
        new_conn =
          conn
          |> put_new_layout({KokonRest.Views.Layout, :app})
          |> put_new_view(unquote(view))

        if function_exported?(__MODULE__, name, 3) do
          apply(__MODULE__, name, [new_conn, conn.params, conn.body_params])
        else
          apply(__MODULE__, name, [new_conn, conn.params])
        end
      end

Which separates query/path params from body params (I use it because OpenApiSpex “removes” body params from conn.params).

4 Likes
17

Thank you for your response. I usually forget about those guys and eventually after a bit of wondering what is going on remember them. As I said it is a really small thing that always annoys me, the reason it always annoys me is it always catches me out, maybe one day it will sink in, really it is more a problem with me being an idiot half the time.

Ah thanks for the snip, I’ll keep this and try experimenting with something along these lines next time :slight_smile:

18

I wish there was a way to filter out log statements from the built in Phoenix logger so that DevOps doesn’t complain at me that hits to /metrics and /health are killing ELK.

(This is very much a shameless plug for my PR https://github.com/phoenixframework/phoenix/pull/3627 :smiley:)

1 Like
19

Just do not handle this in router but in plug before Plug.Telemetry. This will make everything much cleaner and faster.

3 Likes
20

also keep in mind you can handle this yourself via a plug in the router, so maybe a great opp for a hex package? :slight_smile:

2 Likes
21

I second this. As a beginner it is reassuring to see a framework’s ecosystem grow. I would point to the Laravel ecosystem as an example. In that environment you see a lot of 3rd party tools being developed. Some companies even make money on them.

1 Like