3 ms·

Actually, there is a simple and good way to think about this. We often espouse the "onion model of applications" describing the responsibilities of different l

Actually, there is a simple and good way to think about this. We often espouse the "onion model of applications" describing the responsibilities of different layers of applications. Just apply that here - some API endpoints should be backend "system APIs" offering as much access to entities as possible - think "data layer APIs". When you want to expose data to consumers for use in a UI, these are "experience APIs". These are APIs that might be built as part of the backend that directly interacts with the frontend. Mulesoft talks about this a lot [1]. I am a user of it at work, not necessarily a big fan, but I think their architecture idea is applicable anywhere and helpful for thinking about layers of APIs in a large system. It's similar to the onion model, just applied to APIs. Now, if you are building a smaller system this might all seem overkill. For a small system it might be true, unless you believe it will scale and need to be architected like this from the beginning. I think scale of the end result should always be factored into architecture decisions, because not one size fits all. I think personally there is a model out there that hasn't been expressed fully/fully realized, that integrates ideas of APIs, GraphQL, CQRS, microservices and the onion model. [1] https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/ https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-conne...

silviogutierrez 6y ago
I'll have to give this a read. Many of these technologies (GraphQL) seem like layers on top of layers. Really, I just want a page with 3 fields specific to that page. They may come from 3 different tables. GraphQL's original solution to this was to batch the request to 3 different resources, but the underlying problem was still there. Of course, you can make ad-hoc GraphQL equivalents to a random REST ad-hoc /api/get-info-for-my-profile-page/. The problem becomes especially noticeable when you want to update nested resources. Say, a profile's subscription status. Instead, in "MVC" world, I would just bump up the subscription status to be a first class field on that view. So no profile->subscription->status. Just "subscription_status". Hope that makes sense. So far, I've reverted to using Django Forms (across tables) and breaking them down to JSON to use them in a SPA. My endpoints are still very much domain specific, but I can use XHR/fetch to make the page interactive.

silviogutierrez 6y ago

I'll have to give this a read. Many of these technologies (GraphQL) seem like layers on top of layers. Really, I just want a page with 3 fields specific to that page. They may come from 3 different tables. GraphQL's original solution to this was to batch the request to 3 different resources, but the underlying problem was still there. Of course, you can make ad-hoc GraphQL equivalents to a random REST ad-hoc /api/get-info-for-my-profile-page/. The problem becomes especially noticeable when you want to update nested resources. Say, a profile's subscription status. Instead, in "MVC" world, I would just bump up the subscription status to be a first class field on that view. So no profile->subscription->status. Just "subscription_status". Hope that makes sense. So far, I've reverted to using Django Forms (across tables) and breaking them down to JSON to use them in a SPA. My endpoints are still very much domain specific, but I can use XHR/fetch to make the page interactive.