silvadanilo
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 · GitHub.
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!
Where Next?
Trending in Announcing
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #elixirconf-us
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync. Next: ElixirConf EU 2027
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
katafrakt
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.
silvadanilo
Thank you for your comment!
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
executemethod, you can run the query.katafrakt
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.