Are you interested my work re-writing the django ember adapter / serializer from scratch? about ember-django-adapter HOT 11 CLOSED

I think a re-write would bring a lot of organization and clarity to the project that is sorely needed. It sounds ambitious though, and my fear is that it would never be completed.

We could start a proof-of-concept branch if you want. I still want to bring the code in from toranb's repo for now.

from ember-django-adapter.

You're right that it would never be finished in the way that you could always add more optional DRF functionality (e.g. API file uploads, etc). But I think it's possible to support the basic functionality that's in the documentation at emberjs.com in a relatively short time. Ember-data's RestAdapter does a lot of what we want, it's just a matter of learning to use the ember-data APIs ... although I do admit that can be time consuming.

In any case, I have a minimal adpater / serializer that I'll send in a new pull request for the proof of concept branch. If you don't like my approach, just tell me and I'll just keep it as an update to my existing adapter, which I haven't updated in a while but could also be used to host this work.

https://github.com/benkonrath/ember-data-drf2-adapter/

from ember-django-adapter.

Where should I put the new code? Just replace the adapter in vendor for now?

from ember-django-adapter.

@benkonrath Let's try to follow the addon guidelines from ember-cli:

http://www.ember-cli.com/#developing-addons-and-blueprints

Looks like we'll want an "addon" folder for anything we want to import (this is probably where most of your new code would go) plus the structural app/blueprints folders which I already have in place.

I've created a version 1.0 branch for us to get started. This way we can try to collaborate and work incrementally. If you can get a basic structural PR put together, I can accept that and then start working on tests while you get the rest of the logic hashed out. What do you think?

from ember-django-adapter.

That sounds good. I'm new to ember-cli but I'll read the page you posted to figure it out. Thanks.

from ember-django-adapter.

Hi, Just stumbled over this. Is there a reason why the two of you prefer to build an adapter on the ember side as opposed to the DRF side? It seems to me that there is less complexity to building an adapter on the backend - especially with the new changes in DRF 3. Regardless, I am very interested in being part of the discussion going forward for the new adapter and based on my experience over the last year with the existing adapter I think a rewrite could go a long way.

from ember-django-adapter.

My main reasoning is that there might be cases where users can't modify the API which means there would be need to a client-side solution even if there were a nice DRF / server-side solution that's easy to share. I also think that a client side solution with Ember CLI will make it easier to get an Ember / Django project up and running and Ember CLI makes it easy to share a common solution for Ember / Django. I know you share code easily in Python / Django as well so maybe the last point isn't much of an advantage.

Ember Data is designed for the exact situation were in: we need to extend / override the adapter / serializer for the specific flavor of REST that DRF uses. The Ember Data have come a long way since Toran's adapter was created and I think we can make something that's designed well and stays in the ember world.

I do think that we'll be adding features that require users to design their APIs in a specific way but I hope those feature can be kept as optional so make a simple API with DRF and the adapter just works for CRUD operations.

That all said, I'd like to hear your point of view. What's coming in DRF 3 that will help out with a server-side solution to this problem? - I haven't been following DRF lately. Your experience will be definitely useful. I'm hoping to get a first (small) PR out later this evening or tomorrow.

from ember-django-adapter.

Your points are well taken and as you say many users who have a legacy DRF api will looking for a ED adapter no matter what.

On my own project I have more or less decided that I am going to build a DRF Adapter. I'll try to summarize my thoughts, more or less in order of importance:

1. I tend to think that side-loading is a better serialization strategy than nesting. If you have 100 fruits that belong in 3 baskets, an API response structured like {fruits: [...], baskets: [...]} will be materially smaller than an API response structured like [{id: <fruit_id>, basket: {id: <basket_id>}}, ...]. In the latter case you might opt to instead use an async strategy, making an initial request to /api/fruits/ and then a request to /api/baskets/?ids=1,2,3 however that results in two requests instead of one. If you already have all the baskets loaded into the store from another point in your app then you would end up with one request, however you still need to use a promise structure for all logic that uses that async property which I find really annoying (though there has been mention of ED moving to all async properties in which case we will have to use promises everywhere no matter what).
2. ED is in constant development. DRF is very stable. If I can write a good DRF adapter I will probably find myself updating it and maintaining it much less than an ED adapter.
3. ED is a lot more complicated than DRF. Based on my preliminary read through of the new DRF3 serializer class, an adapter could be implement with two hooks. DRF does not wrestle with the complexities of a stateful application, making it much easier for an adapter to cover all possible use cases.

To respond to some of your points:

1. I think ED and DRF are both well designed for customizing in the way we are contemplating.
2. As you say, the app ecosystem is strong in python (and getting strong in Ember). That said, I still find myself struggling to manage javascript dependencies with npm whereas I have never had an issue with pip.
3. As I mentioned, I have done some preliminary work on figuring out a course for a DRF3 adapter and it looks quite straightforward. I am hoping to try to write some code this week.

from ember-django-adapter.

Thanks for your input - it's really great to get your perspective and I've raised some interesting points and made me think about my plan a little. Great stuff. :)

Just a quick response to your points:

Re your point 1: I'm using the async strategy with 2 requests as your example demonstrates. That works fine for my application (for now anyway). I do hope that I'll be able to get the client-side adapter to work with embedded records in the json. I'm pretty sure you can do this in DRF and the ED developers have extracted the embedded code as a mixin, which I hope makes it easier to use. But I can see why you like the server-side solution as it's more concrete than my plan which I haven't fully researched / investigated thoroughly yet.

Re your point 2: I agree that ED is not stable but I'm hoping that we're at the tail end of the instability. Again, I can definitely see why basing a solution on DRF is more attractive than basing a solution on ED. For me this is most compelling point. But in the end if ED changes, you may have to adjust the server-side implementation as well.

Re your point 3: I totally agree, ED is more complex to navigate than DRF. Part of that, for me at least, is that I spend more time working with Django / Python than I do with Ember / JavaScript so I don't want to discredit ED as too complex to work with just yet.

If I had some spare time to work on my ideal solution, I would probably implement a client and server-side solution by implementing HAL with DRF and ED. But I don't have the kind of time so I'm just trying to extract some of the client-side code that I'm using in my projects with the hopes of creating a shared solution that is designed and implement well and peer reviewed.

Ultimately @dustinfarris and I just agreed to try things out in a branch see how far we get. I think there is actually room for both a client and server-side solution. Worst case, we'll have two different approaches to the solving the same problem. As long as we take the time to document the differences so that potential users aren't confused and can make informed decisions about which to use, I think it will be ok. We might also find that one of the solutions is better and then we'll just settle on the one approach. What do you think?

from ember-django-adapter.

Thanks for your responses. I am going to get to work right away on a DRF Adapter and see how it goes. I think that having both approaches can't hurt. I'll try to keep involved in the discussion on your rewrite and contribute if I can - at the end of the day I might decide to keep my project on an ED Adapter and use pure DRF. I'll try to get something on github soon so you can keep track of what I'm working on as well if you are interested.

from ember-django-adapter.

Yeah, I'm definitely interested. Please do let me know when you have something up. Thanks.

from ember-django-adapter.