[Discussion] Apps: Actions / Events / Notifications #2364

Closed
ErisDS opened this Issue Mar 8, 2014 · 15 comments

6 participants

@ErisDS
Ghost member

During the last public meeting it was discussed that there is a concept for apps that isn’t properly covered by the intended APIs & Filter mechanism.

Filters are for changing the behaviour, input or output of Ghost in some way by hooking into data, settings, etc and changing (filtering) the information in some way. A good example being filtering the meta data provided by the {{ghost_head}} helper.

The data API allows Apps access to the CRUD methods of the JSON API.

However, it is considered that Apps may also wish to hook into, or be notified of when an event happens in Ghost - for example when a new post is published. These are ‘Fire and Forget’ notifications where there is no guarantee or knowledge of when all apps have finished responding, and no concept of priority (filters provides both these things).

In WP there is the concept of filters (again for changing data) and actions which are like events but PHP. In JavaScript we have real events.

The first question is shall we call this feature Actions, Events or Notifications?

The second is how to implement it, and what to do about considerations like permissions? Do these things still have enough information (i.e. what the current user is) to have access to things which require permissions?

Thoughts on a postcard please :)

@ErisDS ErisDS added this to the 0.5 milestone Mar 8, 2014
@ErisDS ErisDS added the apps label Mar 8, 2014
@gotdibbs
Ghost member
  1. I personally would go with events. An event is a very easy concept to grasp in my opinion. As well, given our basis on Node, I think it is perfectly fitting. Side note: if you go with events, you'd have a pretty good acronym of F.E.D. (Filters, Events, and Data API) which is much better than F.A.D. or F.N.D. :P
  2. There are two potential layers to the permissions for events as I see it, the current user's permissions and the app's permissions. I don't see any reason why both couldn't be accounted for. I would expect you should be able to hook into any event emitted by Ghost from any app. I would only question whether or not you'd want an app to be able to publish its own events and how that would be handled.
@hillct
@javorszky
Ghost member

Events. In javascript land it's called events, let's keep housekeeping to a minimum :). Also, this could totally be used for this: http://nodejs.org/api/events.html (on top of, in conjunction with, or buried under the permission system).

FED++

@hillct
@ErisDS
Ghost member
@gotdibbs
Ghost member
Question: can an app that doesn't have publish permission subscribe to the publish event?

I would think yes. Just because you can't publish, shouldn't mean that you can't listen for something to be published and do something else. I've got a fair bit of experience with a couple enterprise permission/security models and that appears pretty conventional.

I think you're suggesting that each event be given a context object for its arguments? I think that is fine to some degree. I would give only the most basic information (user id, record id/type, etc) and let the app access all other data through the Data API. I may not entirely understand the Data API, but from what I've heard that sounds reasonable?

@javorszky
Ghost member

In WPland, events (or actions over there) are given relevant info. If a new user is created, the event is given the new user's id, if a new post is created, it's given the new post id. It is then up to the whatever to make use of that id given their permissions.

What I hate about it in WPland is that the actions can be given variable number of arguments, and I always need to pay attention to that. Could we make it so that when an event is published, the argument is one object populated with all the different info? :)

@gotdibbs
Ghost member

@javorszky What I'm hearing is that you're looking for consistency in the event arguments right? So would what I mentioned work? Example: you have a bunch of events like publish, create, update which when fired off, all events receive something like this for the event args:

{
  userId: 'currentUserId',
  recordId: 'publishedRecordId',
  updateTime: 'timeActionOccurred'
}
@javorszky
Ghost member

@gotdibbs , yup, that would totally work. And then whatever app that subscribes to that event can then dissect the argument. 👍

@julien51

Events would be awesome :)
The complexity comes when you want to differentiate between the "fire and forget" events or something that can actually change the workflow/output. I would probably focus on the first ones before addressing the 2nd ones!

Also, I afree with @gotdibbs that events should probably first be restricted to a couple verbs (CRUD?) applied to a scope (blog, post, page, ... etc).

@gotdibbs
Ghost member

@julien51 Yeah I don't think events should be able to change the output of a process. Events are "fire and forget" whereas filters would be the mechanism with which you would alter inputs/outputs as they flow through the pipeline. @ErisDS please correct me if I'm wrong.

@ErisDS
Ghost member

That's spot on. We use filters to allow people to modify Ghost's behaviour (inputs / outputs / whatever) they're probably more useful than fire and forget events - they've certainly been around as a concept for much longer.

@julien51

Ok, well, as soon as something is available, I'll happily finish my implementation of #PubSubHubbub for the #RSS feeds. I have a first commit up at 98c18f4 in our branch.

Based on what I just read, I think the first step would be to trigger events at the requestHandler level in the api, but that probably means that the api needs to be a little more than just a {}.

@ErisDS ErisDS modified the milestone: 0.6 Apps Sep 2, 2014
@cdax

Use case: For a while now, I've been hacking on my local Ghost so that it updates a remote ElasticSearch index whenever a post is added/edited/destroyed. Events for these (add/edit/destroy), will allow me to take the indexing functionality out of Ghost core and into an app.

@ErisDS ErisDS added the later label Jun 26, 2015
@ErisDS
Ghost member

Temporarily closing all of the app specific issues (tagged with later). Will review & reopen those that are still relevant when we kick off that project, which should be shortly after Zelda lands.

@ErisDS ErisDS closed this Jun 26, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment