Ecto_command - a toolkit for mapping, validating, and executing commands

Hello guys,

I often find myself working on projects where I accept commands from external sources (usually via HTTP APIs, but they could also come through the shell or other means).
The input data needs to be validated before it can be used, and after trying out various validation libraries, I have come to the conclusion that it is probably best to leverage Ecto’s validation feature for this task.

However, I find Ecto a bit cumbersome and verbose when it comes to specifying fields and how they should be validated. For these and other reasons, I have created this library: GitHub - silvadanilo/ecto_command.

This library allows you to specify which fields are available for a particular command, how they should be validated, and if the input data is valid, it allows the execution of that specific command.

I would appreciate any feedback and suggestions on how to improve the library. Please take a look at the GitHub repository and share your thoughts.

Thank you in advance for your support and contributions!


I’ve seen it somehow few weeks ago and I think it’s pretty cool implementation, if someone uses commands. I agree with you that Ecto input validation is great, but it’s tied a bit too much to persistence layer (at least conceptually) and is much harder to use outside of persistence contexts. This, in turn, lead to database-driven development. It’s freat to have an abstraction to overcome this.

1 Like

Thank you for your comment! :pray:

Yes, I named it ‘Command’ because I’m really bad at coming up with names, and yes, using the CQRS pattern is the first thing that came to my mind. However, in this context, I consider anything that your software can receive as a ‘command,’ whether it’s a POST/PUT/DELETE request or even a query (GET). On the query side, you might need to validate input parameters, and in the execute method, you can run the query.

Oh, I absolutely don’t mind the name. I use the name “command” for a wide variety of things, basically every self-contained unit of code that makes a change to the system state.

I wouldn’t, however, use your library for queries probably. I know some people would - and it’s fine. But for me personally queries are usually better off without this kind of abstraction.