My biggest concern is that this group ends up bikeshedding and/or attempting to boil the ocean and solve a million theoretical problems. My biggest hope is that we deliver a killer app for front-end developers looking to build their implementation. If we can do that, it will force us to do a lot of other smart things, and enable millions of others to put their innovation "on top" of ours.
To that end, I'd like to propose a goal that's pragmatic, provides value, and will help keep the discussion and work focused.
We should create several JS client implementations that can accomplish a common demo.
What I imagine would be similar to how TodoMVC functions in the world of JS Frameworks. Not for nothing, but the WordPress API group is doing this too, and it's helping them get traction.
The basic demo would be something like:
- Page/Article CRUD
- Extend the data model for content
- User auth/operations
- Drupal admin operations?
We should be focusing on making it really easy and really elegant to do these things for front-end developers who don't know Drupal from a hole in the ground.
We can start by making sure we can do it ourselves. With these demos "in the wild" we can attract new contributions and help jumpstart a new generation of development and innovation.
UPDATE: See comments below. It occurs to me that we should not limit the implementations to JS. Having a Guzzle implementation, a Python implementation, a Ruby implementation, heck even a CURL implementation would all be excellent and helpful.
Comments
A woefully incomplete example
Here's what I was able to whip up this afternoon for Angular:
http://dev-headless-drupal-8.gotpantheon.com/
This is build on Alpha 12 so not the latest; hopefully we can address some of the shortcomings as the Beta comes out!
Where I feel blocked:
Where I feel annoyed
{{ node.title[0].value }}
instead of just{{ node.title }}
.More to come!
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Reference Implementation
I agree that we need a reference implementation of some kind to benchmark against, or at least one to test assumptions against real-world implications that don't arise until we try to just do it.
We need an engine
I agree with you Josh.
A great way to solve this would be to package it up into an engine that can not only map entities to hypermedia formats, but also provide a way to add additional information such as actions, relations, and authentication.It can also handle submissions and handle translating back to Drupaly Content. As a bonus if we can add some machine readable profiles (like ALPS), we could have a fully functional Hypermedia API system. At the least though, we should translate the content and get a strong authentication method.
We need clients
Hey Kris,
I hear all your points, but I feel like this is the kind of discussion — loading up on backend requirements — that I'm trying to steer away from, at least on this thread. My point is that we should put work into building clients, and let that guide further work.
For instance, if Cookie auth worked well it would be fine (superior even) for a "headless front-end" implementation in various Javascript frameworks. Since the user-agent is the operating system for the client, it's quite natural: Login via XMLHttpRequest (or /user/login), get cookie, get X-CRF-Token, keep on rockin'.
Similarly, before we start coming up with more API requirements (for other systems consumption) we should make sure we have a client use-case in mind — if only an example! — so that our decisions are informed by the actual needs of someone implementing said API.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
data abstraction layer
@skriptable Re:
This comment describes the mapper I was talking about at the NYCCamp planning meeting. If there isn't already something like this for D8, adding that could help this issue.
Serialization API
Agreed. I think we can implement this using the Serialization API in D8.
Great to see that!
Suppose for now demo could use basic auth and then contrib could implement others.
It would be great to share the code in some sandbox/github also I think having install profile for the demo is really needed.
PS: I'd like to help here but not idea how. Wscci initiative lacks of feedback and attention from real usage
Github Coming
I will have this up in a open repo this week. Demoing it tomorrow at SFDUG
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
SFDUG
Hmmm.. might have to come down (I am in Marin). When/where?
Tonight @ Pantheon
It's tonight!
http://www.meetup.com/SFDUG-San-Francisco-Drupal-Users-group/events/1657...
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
I will come. If you like, I
I will come. If you like, I have a D7 app that is a couple of months in I can show you. (no end time showing for the meetup, might need to leave early to catch the ferry)Can't make it. Hope to see the video, though. Love to hear about what you all are up to!
Great idea. Glad to see
Great idea. Glad to see movement away from the bikeshedding. Have you seen https://github.com/angular-app/angular-app?
"The idea is to demonstrate how to write a typical, non-trivial CRUD application using AngularJS. To showcase AngularJS in its most advantageous environment we've set out to write a simplified project management tool supporting teams using the SCRUM methodology. The sample application tries to show best practices when it comes to: folders structure, using modules, testing, communicating with a REST back-end, organizing navigation, addressing security concerns (authentication / authorization)."
The thing to take away from the example best practices app is to build in a modular way (seems familiar, huh?). Instead of having a folder for controllers, one for services, one for directives etc, group code together that can be reused. I will start a thread for angular best practices, tips, and tricks.
Make Drupal a Backend for Angular App?
I was not aware of that. Thanks for the link.
Do you think making Drupal a solid/easy backend for angular-app could be one of the goals?
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
It would be difficult
It would need to somehow transform the array hell to an easily consumable json format. I doubt that will happen in the core. I have been using the alters and menu items to produce the response to the client. For example:
function mymodule_node_view_alter(&$build) {
switch($build['#bundle']) {
case 'online_book':
$node_wrap = entity_metadata_wrapper('node', $build['#node']);
$response = array();
$response['build'] = $build;
$response['nid'] = $node_wrap->getIdentifier();
$response['pageTitle'] = $node_wrap->title->value();
$response['slug'] = $node_wrap->field_book_slug->value();
$response['body'] = $node_wrap->body->value->value();
$response['cover'] = render($build['field_book_cover']);
$response['authors'] = $node_wrap->field_authors->value();
$flag_counts = flag_get_counts('node', $response['nid']);
$response['likes'] = $flag_counts['like'];
$response['categories'] = array();
foreach($build['field_book_genre']['#items'] as $index=>$item) {
$response['categories'][] = array(
'tid' => $item['tid'],
'name' => $item['taxonomy_term']->name,
);
}
drupal_json_output($response);
drupal_exit();
}
}
Same thing for forms where I set the values to provide a more client side friendly (and much lighter) model. I tried just taking the form array as given by drupal, but it seemed easier to just provide the response. entity_metadata_wrapper has been extremely helpful for this.
Plus there are weird things like image handling that will be difficult. In my case I am using an AWS S3 and the drupal s3fs module. I could not just get the s3 URL, so I had to render the image element. There is more iinfo about that in this issue: https://www.drupal.org/node/2322943
btw, $response['build'] =
btw,
$response['build'] = $build;
is in there for debugging. Kind of like a client side dpm(). That would be removed once everything is solid.For D7, I worked on a mapping
For D7, I worked on a mapping layer for RESTful Web Services - letting you map Drupal-structured data to a set schema (eg schema.org, etc):
https://github.com/scottrigby/restws_schema
This was helpful for allowing our AngularJS to use the same templates generated by an in-browser frontend prototyping tool of our choice (whether https://github.com/north/generator-style-prototype, http://patternlab.io, etc).
Also - yeah - we have been working on a step-by-step guide (using Yeoman etc) to building an Angular app for this backend... I agree with Moshe this is an important conversation to get going - thanks Josh! Looking forward to what comes out of it
D7 Demos Welcome
I think getting knowledge out there about how people do this already in D7 is just as valuable. I'd love to have those examples in any showcase as well.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Can't we talk to Drupal without the mapping?
I worked with Scott, providing the Angular App. What I built was created using aaronallport's angular require generator, which is an Angular Yeoman generator that uses RequireJS to load scripts. This gist: Angular service to talk to Drupal, shows how we used Restangular to make REST calls and the code follows the file-created format of angular-require.
Anywho...what I found, after Scott Rigby set up his Drupal + Mapping POC, was that it was fairly simple to get data out of Drupal and inject it into the Angular App.
Right now, I'm working on creating an angular-app/dev environment combo - similar to a number of generators out there - but with the various needs we'll have for development and exporting for Production.
Scott, your mapping layer is fantastic for it's normalization, but aren't we able to make Drupal REST calls without it? Wasn't there a single module which you turned on that opened up Drupal's REST and made it a service? Did that open up the images as well? I remember you had galleries in your data...
Yes and no
@scottnath restws_schema just helps restws serve an arbitrary schema rather than Drupal's Entity schema. There are other ways to provide REST via Drupal 7, but I chose to build it on top of restws because it is similar to REST in D8. I'm still interested in how https://github.com/Gizra/restful differs from restws (restful was not available when I made restws_schema).
The concept of RESTful is
The concept of RESTful is here https://github.com/Gizra/restful/blob/7.x-1.x/README.md#concept
In short: versionable api, endpoints in expected places (e.g. api/v1/articles), but most important -- each resource is declared explicitly - so no Drupalism is exposed.
Checkout the blog posts and example modules.
Oh great
@amitai From the concept description this sounds very similar to what we've been working on - I'll reach out again about looking at these together - thanks!
Sure, my offer for a Skype
Sure, my offer for a Skype still stands :)
Have a look at the code, and examples -- you'll see that RESTful is taking a very different approach than RetWs.
This would be great for JS devs
I really like the idea of this (restws_schema) module. A JS dev could come in and setup the mapping through a UI. However, I went to install the module(s) but don't see them working (at least the UI one). Is the project just in its early stages or should it be working? I added a couple of issues to the github project with details: https://github.com/scottrigby/restws_schema/issues
Developers need to provide a schema
I realize the README could be more explicit on this point. I'll update that soon.
In the meantime, I replied to your github issue, but here is the response in case it's helpful to anyone else:
Thanks for getting this
Thanks for getting this conversation going. And kudos for following through with some code.
It took many months of hard work to get the rest responses into core. We need another wave of conributors. This effort could be a great catalyst. Go team!
images: Provide the current requested display's image style URL
I see the link about image fields is about POST/PATCH, but what about a GET? I would like to see the response as either a simple object (url, width, height, alt, title) or even just the correct current requested display's URL to the image.
Also, how will this work when using a CDN? In D7 there seems to be a problem getting the correct URL. See https://www.drupal.org/node/2322943
Thanks for the link!
The Image issue seems mostly to be about POSTing new data. I suppose there's additional work to be done to get GET requests working?
I'll start keeping track of these issues as a way to try and drive more activity. Adding this to the body of my post. :)
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
RESTFul 8
fyi, RESTful is being ported now to D8...
Sweet!
I'll have to work on that for another demo. :)
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Here's a good first step:
Here's a good first step: Todo app with RESTful backend -- http://www.gizra.com/content/todo-restful-backend/
I agree with you that we need
I agree with you that we need a reference implementation of some kind to benchmark against, or at least one to test assumptions against real-world implications that don't arise until we try to just do it.
My name is insomniaku