@LuchoTurtle agree with the opening statement. 😄 👍 validation ✅ readability 🙏
Perhaps it's best to consider this from first principals: what 3 types of data are we validating in our
To me, this looks like at most 9 small functions which we can exhaustively test and then use to validate all data.
Not saying I don't think it's worth exploring
goal when we need it.
But adding a tool, that is relatively new and unproven is not the approach I would take.
As I said on our Standup call this morning, https://github.com/martinthenth/goal looks good:
But I'm not going to be the first user (only 1 contributor) ...
v0.1 package is essentially
Alpha testing. ⚠️
Yes, I know this is "harsh". Most of the code we have written for
Alpha. But we have full control over it and can iterate very fast.
I encourage you to think about all technology decisions this way:
Pick the tech/tools you would use to build the life support system for a loved one.
If you don't have clear evidence that a library is worthy of being used in a life support system,
i.e. it will not crash and kill your loved one, then it's not "ready" for us to adopt it.
By all means read the code and understand what it's doing, ⭐ (bookmark) it and then keep searching.
If you want to create a small demo, that's fine.
goal might even solve a very specific problem that we are facing; schema validation.
But given how simple our API is right now (and for the foreseeable future) I don't think we neeeed it, yet.
Elixir and parameter validation on APIs #118
JSONschema validation is usually a must when implementing an API.
When the API is simple, you can probably get away with simple validations but when you have multiple possible query or URI parameters, keeping its validation clean and concise helps with readability.
There is some discussion on how to do this with Elixir/Phoenix:
Ecto.Changesetsis usually the standard. Although I personally use
Changesetsfor validation on a database level, it might be not the same situation for validation on an API-level, where we might want another set of constraints to be met.
Schemaless changesets can (and should!) be actually used for this. But I feel like this produces a considerable amount of boilerplate code.
With this in mind, I've taken a gander and found
goal, which seems to make this process painless and make code much more comprehensible, as errors are returned on an atom-basis.
Just food for thought 🧠