Elixir and parameter validation on APIs

[LuchoTurtle]

JSON schema 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:

• https://www.reddit.com/r/elixir/comments/m63p21/some_thoughts_around_elixir_json_schema_validator/
• https://elixirforum.com/t/whats-the-standard-for-validating-json-bodies-for-an-api/14837

Using Ecto.Changesets is usually the standard. Although I personally use Changesets for 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 🧠

[nelsonic]

@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 MVP?

1. timer.start|stop: DateTime
2. item.id, person_id, tag.id and timer.id: Integer
3. item.text & tag.text : String

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) ... https://hex.pm/packages/goal using a v0.1 package is essentially Alpha testing. ⚠️

Yes, I know this is "harsh". Most of the code we have written for MVP is 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.