That's definitely something we considered doing at DoorDash. I've heard bad things about it as you want more control over deployment/package upgrades, etc. how has that played out for you?
I'm also curious if any large projects use it. We tried it out for a couple weeks - it worked fine but we felt overly constrained by the configuration rules and ended up rolling our own solution.
We use it at Mi9 to run some of Australia's highest trafficked websites, like ninemsn.com.au (and family of new sites) and jumpin.com.au. Also Stan.com.au (Australian Netflix competitor) runs their micro service architecture on Elasticbeanstalk
We thought about this approach. This would mean that we'd have to have fine-grain permissions logic every time we used that resource. An analogy to this is like having to sanitize literal strings for every user input from a web form; if you forget to sanitize (or in the API case forget to filter the fields) at any point, you have a security bug in your code.
You're still doing filtering. The difference I see is your database request code is duplicated. Conceptually the condition is moved but it is bound to exist somewhere. This is IMO a semantics question. Thanks for your input anyway, you gave me a new perspective to wonder.
You can also say privacy is about protecting people's information, which is what abstraction allows us to do. It's also a matter of where to make the permissions decisions, at the view level or at the API resource level? At DoorDash, we've found that making that choice at the API resource level was the right decision.
In software there are usually multiple places to accomplish the same thing. I usually ask, "where do I put the work?" I'm usually thinking of the database vs. the framework on the server vs. the client.
The post is a great explanation of the choices and why the API resource was the way to go. Inspired us to take a look at how we put our API together.
