Should we Separate Ecto From Phoenix in Umbrella App?

Thank you very much @kelvinst. I wasn’t aware of this generator. This will be good for beginners that are looking for the “best patterns”. :slight_smile:

1 Like

Update: so yeah we did end up separating Ecto from Phoenix, and it was easy to do and easy to work with. There’s only some mild annoyances when running generators and stuff like that.

Now building my second Elixir project the same way. This time it’s a GraphQL API (using Absinthe) so there’s not even an HTML layer or controllers, making Phoenix a very thin layer for organising plugs and GraphQL schemas in a standard way really.

Here’s my short cheat sheet for starting projects this way: http://noamswebsite.com/wiki-main/computers/phoenix_no_ecto/

8 Likes

Did you try config :phoenix, :generators, model: false? I am not sure if it will work, but it is worth trying.

5 Likes

That does it, thanks :slight_smile:

following this set up, does it mean that the ecto schema and changesets are in the DB application? Or are they in the main business logic

1 Like

I am currently working with an umbrella app (one for business logic including ecto and on for phoenix) and it works fine.

But now I am thinking that it would be nice to put the BL and ecto back to the phoenix app. There are two reasons

  1. I really like to work with my test cases and code coverage to find spots where I need more tests and possible find dead code that is not used anymore. With the umbrella app my controller or hound tests will not recorded for my business app. Thats really bad.
  2. Lots of my code is vuejs/frontend stuff living in apps/web_app/web/static/js/whatever. So the dir structure of the whole project is getting more complex than it has to be (personal opinion)

So is there a strong point in staying with the umbrella app?

1 Like

I would also like to know the answer for this, since changesets can be used in both domains - Phoenix for rendering validation errors to users and with Ecto for validating data when inserting.

Maybe I am thinking about this wrong, still in the mindset of the tradition MVC application.

1 Like

I would put any shared data into it’s own library (or application if you are using an umbrella, I prefer libraries as there is a more strict separation and file deps update in realtime anyway), then just have both the DB work and the main application depend on that.

1 Like

I very like your approach, but there is a technical issue.
Basically phoenix context is a very convenient thing, it gives you separation of DB schema and business logic.
Once we separate DB, business logic and phoenix into 3 apps, will you say we basically might want to phx.gen.context and then move files to appropriate apps?