Make Your Back End Layer as Thin as Possible
I strongly disagree with the advice in this article. There are many reasons. I’ll name a few.<p>Your DB is likely to contain internal state that has no business being sent to the client. Over time applications change and fields can change meaning, become deprecated, or become dependent on other fields through business logic.<p>If you do this, any business logic not captured in your backend has to be duplicated in each front end. Imagine needing to write and maintain the same business logic in a JavaScript framework, Java for Android, and Swift for your iOS app.<p>How do you make breaking DB changes if you take on this strategy of API design?<p>In most cases in my professional career, making a choice to have a thin RESTful API that corresponds closely to the DB structure has been a mistake that only time made clear. RPC-like APIs fared much better.<p>This advice may be good for a proof of concept, a prototype, or an early version which stands a good chance of getting rewritten. I would not recommend it for anyone wishing to build a lasting architecture.<p>Don’t take my word for it. Take a look at your favorite famous internet company and look at their API and try to deduce if they follow this advice or not.