Thanks! I agree that using only/except would make inclusion/exclusion property more explicit. I think in this case it should be ecto: [only: [Ecto.Changeset]], right?
sasajuric
Author of Elixir In Action
3
LostKobrakai
axelson
Scenic Core Team
From this call how does Boundary determine what calls are allowed? Does it look at the first part of the module (Ecto) or does it do something else such as look at all the modules in the OTP application that contains Ecto? For example if ecto defined EctoChangeset (instead of Ecto.Changeset) would it still be caught by Boundary?
0
sasajuric
Author of Elixir In Action
First off, based on comments by @LostKobrakai, the interface is now ecto: [only: [Ecto.Changeset]] (or except: [...]).
This means that calls to, Ecto.Changeset as well as Ecto.Changeset.Foo, or Ecto.Changeset.Bar.Baz, etc are allowed.
Suppose you make the call to Ecto.Changeset.Foo.bar. Boundary will compare the callee module (Ecto.Changeset.Foo) with the allowed ones. If any of the allowed modules is a prefix of the callee, the call is allowed. Otherwise (e.g. EctoChangeset) it is reported as a warning (you can see this in the example screenshot I made earlier, where Ecto.Query.from is forbidden).
In the case of except it’s works the same, but if there’s a match the call is reported, otherwise it’s allowed.
0
axelson
Scenic Core Team
But how does Boundary not flag a call to a separate dependency, such as a call to Plug.Conn.assign/3 as a warning. Does Boundary look at all modules contained within a dependency?
0
sasajuric
Author of Elixir In Action
To make it less disruptive, boundary only considers calls to deps (apps) you’ve explicitly listed in the :externals list. So, considering the following example
use Boundary, externals: [ecto: {:only, [Ecto.Changeset]}]
Calls to modules from :ecto app are analyzed. Calls to non-listed deps (phoenix, plug, jason, etc) are always permitted. Finally, in-app calls are always analyzed.
Does that make sense?
1
Exadra37
I would prefer it to be strict, thus to require us to list all external dependencies we want to use.
1
sasajuric
Author of Elixir In Action
FWIW, I’m actively thinking about strict, and would at least like to support it as a per-project opt-in. It would look something like:
defmodule MySystem.MixProject do
def project do
[
boundary: [externals: :strict],
# ...
]
end
end
At which point you’d need to explicitly approve each external dep in every boundary.
I wouldn’t set this as a default b/c I feel it might turn out to be very disruptive and turn away most users. I’d like to keep boundary as relatively low ceremony for people starting with it, but at the same time I’d like to make it possible to introduce stricter rules for teams who want to enforce tighter control.
Another thing I’m considering is combining external boundaries together with regular boundaries. For example, consider the sample web boundary:
defmodule MySystemWeb do
use Boundary,
deps: [MySystem],
externals: [ecto: {:only, [Ecto.Changeset]}]
I’m thinking about turning this into
defmodule MySystemWeb do
use Boundary, deps: [MySystem, Ecto.Changeset]
So basically, we treat stuff from external apps as ad-hoc boundaries (in future we might also leverage deps boundaries meta if such exists, as proposed by @michalmuskala here).
The project-level :externals mode would determine what to do with unlisted boundaries. E.g. if you set externals: :relaxed (default), all calls to other apps are allowed, but if you include some boundaries from another app then only those boundaries are permitted. OTOH if you set externals: :strict, you need to explicitly approve every external dep. In most cases that would mean approving the top-level module (e.g. including Phoenix in the boundary list). Calls to Erlang modules would be completely ignored, at least in this phase of development.
Thoughts?
2
Exadra37
I can live with it ;), and yes I think it’s the most sensible option to go with, relaxed by default, strict by opti-in.
Despite I never used this Library it looks like a sensible approach to go with 
1
axelson
Scenic Core Team
