I asked a question some time ago about Django/DRF with Ember.
One thing I learned in the discussion there is that I have the option of using a client side adapter, or using a server side adapter. As this is the first single-page-app that I’ve built, and being new to Ember, I don’t have any guess at what the advantages/disadvantages this decision are.
Can anyone offer insight into this decision? I’m not interested in comments on the particular libraries mentioned in the other question, I’m interested in the general principles that would apply when designing an API/single-page-app regardless of back-end technology.
I’m pro-client-side adapter, mostly. I believe that API “consumers” should more or less conform to the structure given by API “providers”—not the other way around.
I work with mobile partners often and I prefer to have them conform to my API spec; sometimes I’ll have multiple consumers (web app, mobile, third-party), and I don’t think any one of them should dictate what my API looks like. I see my API as a more permanent fixture of my project than the front-end framework. Tomorrow I may want to swap Ember out for React, or something else. Breaking my API periodically if this ever occurred would be counter-intuitive in my book.
I believe Ember, while opinionated, understands that it needs to be adaptable to various API styles. That is why Ember Data explicitly makes it possible to write your own adapters. This Ember ability is not hidden beneath the surface. It is well documented and encouraged.
DRF, on the other hand, is not so easily tailored. Most of the server-side solutions I’ve seen sort of monkey-patch parts of the renderer to force a certain JSON style. While many of these work well, they often feel brittle to me. I’ve mentioned working on better adaptability on the DRF server-side to @tomchristie, who is interested, but says it is not an immediate concern.
All that said, there are certain things you can do easily with DRF that are not so intrusive and make writing a client-side adapter a lot easier. My end-game consists of configuring DRF with Ember in mind, while leveraging a client-side adapter to fill in the gaps.
1 Like
Hi,
Sorry for the late reply. I agree with everything Dustin has said and if were building an API that I knew would have multiple consumers I would probably use a client side adapter myself. If you know your api will only have one consumer (Ember) then some of Dustin’s points are not applicable.
The one major conceptual reason to use a client side adapter is that DRF does not support sideloading. Depending on your data structure, sideloading can be a very powerful tool to optimize your api requests. Having used sideloading and embedded records in Ember-Data now, I would actually recommend you use embedded records as they work a lot more consistently, however in some data structures sideloading can massively increase the efficiency of your API.
Most of the other reasons I use a client side adapter are all specific to the characteristics of DRF and Ember Data. While Ember Data aims to be extensible, there are still a lot of assumptions that are baked into the code that cause it to break down when you adapt it in certain ways. I think there are a lot less of these now than 3 months ago when I was still using a client side adapter but they still exist. Django Rest Framework is much more stable than Ember Data and I think in a lot of ways it is much more straight forward and easy to extend. And finally, I massively prefer writing python code to writing javascript.
Cheers,
Gordon
2 Likes