Skip to content

Instantly share code, notes, and snippets.

@alloy
Last active August 29, 2015 14:00
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save alloy/11170799 to your computer and use it in GitHub Desktop.
Save alloy/11170799 to your computer and use it in GitHub Desktop.

The Trunk app and other CocoaPods web-services.

As we don’t want to make the launch process even harder, we’re not adding real web-hooks soon, at least not before the launch. So to communicate that new data (new pod or version) is available, we will share the Trunk DB, but start to abstract away details as soon as possible.

We do however have to send some form of web-hook from Trunk to the other web-services, because if we continue to keep using GitHub web-hooks for this then we cannot trust that Trunk has been updated all its data before any of the other web-services tries to query the Trunk DB. (I.e. other services might receive/process the GitHub web-hook earlier than Trunk.)

Soon after launch

  • The other web-services maintain their own tables in the shared DB. This means those apps have the freedom to define their own DB schema migrations, as long as they don’t collide with Trunk’s schema.
  • The other web-services may make foreign-key references to tables belonging to Trunk.
  • Trunk will send a web hook POST to the web-service when data changed, but for now it will not actually contain any data, so it should only be considered a ping with a change ID (this will probably be a datetime).
  • The other web-services can then query the Trunk DB for the changes since the change ID that they’re interested in.

Some time after the launch, as time permits

  • Work on real web-hooks will start for CocoaPods web-services only.
  • Trunk will POST actual data that all the services are interested in. Since Trunk isn't supposed to know all the data, that should still be a fairly small POST.
  • Trunk will have a changes API that takes a change ID so that the web-services can replay changes in case a web-hook failed to deliver or was otherwise not handled.

Distant future

  • Once we've finalised on the details that web-services need from Trunk, we will start opening up to anyone wanting notifications.
@floere
Copy link

floere commented Apr 22, 2014

Trunk will send a web hook POST

Initially, it seems like we could even just go with GH's web hooks. E.g. metrics could have its own metrics table with metrics data but use the GH web hook call to get some data (and trigger polling for data, see more here).

But one issue with this is that with a new pod we will run into a race condition between trunk and metrics (when finding the pod in metrics, and trunk hasn't added it yet).

Just wanted to note this in case somebody wonders why we need webhook calls from trunk.

(This note is now included in the text above)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment