Toward a roadmap for our API

Product Development
52

Summary of findings so far:

1) The existing Rest API gives us a significant head start on meeting our API needs

No surprises that working from our existing REST API provides a significant head start on some specific use cases of our API. There are considerations about whether the head start will be more costly later.

2) The needs of instances/users of the API are different to the needs of the app

The needs of instances/users are focused around two main goals - to integrate with other tools or to enable flexibility of CRUD operations on OFN data. This is much more focused than the needs of the app to totally support dogfooding.

3) Reactive Rails is preferred in the team

The advantages of faster dev and more flexibility in scaling the team back if necessary seemed to be preferred over the alternative advantages of dogfooding our API and using a more established framework. A five year minimum estimate on ReactiveRails support felt like a sufficient horizon. Being able to easily reduce the dev team if funding became scarce was a key advantage.

4) The DFC approach better fits our vision.

The DFC is more difficult to develop, but has a much higher value when considered alongside our vision and values.

Proposal

1. We commit to Reactive Rails

Overall my interpretation is that the group is leaning to ‘fast dev, flexible team’ over ‘established best practice’ which, again in my interpretation, feels fitting to our current market position.

I know that the community agreed this in the past and it was mostly my realisation that we would cease to be dogfooding our API that has slowed this down. I know I was not alone in wanting to investigate this further but I hope this is increasingly a less controversial proposal.

2. We define a product strategy for our API

With the above decision the API becomes a product independent of the app. This means that it needs an independent product strategy. Given our current starting point of two APIs the need for a clear strategy to avoid duplication of tasks and bugs is incredibly important.

When considering the needs around the API two key themes emerge:

  • We need to have the ability to work in a bespoke, granular way with our data/models
  • We need to be able to interoperate with external tools and services

Conveniently we also have two APIs with specialisations toward these different needs.

I would like us to spend our session on Thursday unpacking this further.

API Meeting 2

8pm GMT Thursday 28th Jan

Agenda Point 1 - A decision on our FE Framework Strategy

See above and here for background.

Agenda Point 2 - Towards our API Product Strategy

The key to our API strategy will be in understanding if we have two sufficiently different usages for our API to warrant two different products. Or should we be seeking to converge on a single API in the near future?

To try and tease this out we can explore the following questions:

  1. What is the purpose of the API?
  2. Who is the target user? OFN Support Teams, OFN Users, General Public.
  3. What problem is it solving?

I’ll add some facilitation prep to this Miro board in preparation for the session.

Next Steps

  • Understanding the API business goals (product team)
  • Prioritising API use cases (community + delivery team)
  • Defining criteria we need to meet to make API endpoints live (delivery team)
3 Likes