API Strategy Meeting
8pm GMT on Thursday Jan 21st.
Thanks to everyone that has signed up to this meeting. The topic we are discussing is quite complex and very deeply technical so I am going to write some notes of preparation here. In this meeting we simply won’t have time to explain everything from first principles to everyone attending. I will propose at the end of this post ideas for getting basic tech understanding up to speed in advance.
What this meeting is not…
This meeting will not be a place in which we prioritise which API endpoints or functions we will work on in the coming months. We will not be looking at the different things we want from our API and putting them into the work plan. While there will be some space in which we will choose important endpoints, the goal of this exercise is to gain a snapshot of the cost of implementation of 4 different API strategies. It is not about choosing endpoints that we will implement.
This meeting will not be a recap of all API conversations that have happened so far. While we’ll need to do a lot of discussing on this highly technical topic I beg everyone attending to take the time to read this post and, in fact, this whole thread. Also take a look at this thread for a little more context.
This meeting will not be about making decisions. Period. We are not choosing which API strategy. We are not choosing which front end framework. We are simply gathering information about the Ease and Value of the four different approaches across 3 high level questions and 6 endpoint examples. Ease is a metric we can use to guess the cost of implementation. Value is a metric we can use to estimate benefit to users and opportunities unlocked.
This is not a place to campaign for your preferred options. By far the most value will come from this meeting if anyone with favourites puts aside their babies and tries to think openly and expansively about the implications of each of the four strategies.
The Four API Strategies
In this meeting we will explore four different potential strategies for our API with the goal estimating the ease (ie cost of implementation) and value (ie to users/potential users) across a range of questions.
The last post says three, but I have added a forth for completeness. The four potential API Strategies are:
1. Frontend consumes our API for the data. Continue using and prioritise extending the existing JSON API. The DFC consumes the JSON API.
This approach is most similar to what we are doing now, however we will become more disciplined if we make this a clear strategy. Being more disciplined will likely mean we use a frontend framework like React meaning that the front end of our application becomes completely separate from the backend of our application. Our API will therefore offer everything that the FE of the application requires. When there are other requirements from users then we will extend our API to offer them. Under this scenario it would be wise for the DFC to sit on top of the JSON API, such that data consistency is easier to maintain.
Pros
- As this approach is most similar to what we are already doing we have a BIG headstart here.
- The little bit of functionality that has already been built consuming our API external to the app can continue to be used
- We will be dogfooding our API meaning that it will be heavily used, tried and tested.
Cons
- The DFC is a side product rather than our primary API
- We have quite a bit of legwork to update our API to enable our FE rewrite.
2. Frontend consumes our API for the data. The DFC becomes our primary API and all OFN functions are served over the DFC
Before any technical people read this and judge, I am including for completeness after it was raised as a question in a meeting. Under this scenario we migrate away from our existing JSON API and use the DFC to serve all OFN requests and responses. We will therefore offer everything that the FE of the application requires by converting to the DFC data structure and then back again to the OFN FE.
Pros
- The DFC is our primary API
- We will be dogfooding our API meaning that it will be heavily used, tried and tested.
Cons
- The OFN data models are very specific to OFN so converting to the DFC structure and then back to OFN for every call between FE and BE might be prohibitively onerous (financially and computationally)
3. Use a full stack framework and don’t consume our API between FE & BE. Keep, extend and streamline the JSON API. DFC consumes JSON API.
Under this scenario we keep our existing JSON API as our primary API, though we will not be using it ourselves. This will mean that many of the existing endpoints be unused as we stop consuming them between FE and BE, and we’ll soon be streamlining and refactoring the API to suit our needs. The DFC will (at least in the short term) consume the OFN API.
Pros
- We continue to use our existing API which has a lot of functionality already
- The little bit of functionality that has already been built consuming our API external to the app can continue to be used
Cons
- We won’t be dogfooding our own API a higher chance of unused endpoints failing to be maintained.
- We’ll be maintaining two APIs, meaning bugs, maintenance etc on both API products
4. Use a full stack framework and don’t consume our API between FE & BE. Rewrite our API to follow the DFC standard.
Under this scenario we will no longer use our API between the FE and BE of the app and our strategy will be to abandon the existing JSON API. We will focus API development on creating our prioritised endpoints to the DFC standard.
Pros
- Our API will be fully DFC compliant. We’ll only be maintaining one API product
- Developing based on our own needs means we’ll continue to dogfood in a way - externally to the app but through the scripts and tools we build from our API in meeting the needs of our users.
Cons
- Any existing API usage will be phased out and replaced by the new API
The Meeting Structure
We’ll be asking the following questions:
Under each API Scenario rank them in terms of ease and value (using an ease value matrix) in terms of:
- Rewriting our frontend
- Growing the delivery/dev team
- Scaling the application
- Implementing six selected endpoints
We’ll be doing this in Miro and you can see the facilitation board (WIP) here.
Some final notes:
I want to be clear that I do not have a preference at this stage. For transparency, there are two options that I see as less viable and two options that I see as more viable, but I am genuinely interested in seeing how each of the options plays out against each other. I have volunteered to facilitate this process. If there is anyone that feels uncomfortable with me facilitating please do say and we can explore if someone else might be better.
In this meeting I want us to limit our engagement with the specific FE frameworks we might use. I understand these topics are inextricably linked. However I intend to keep us away from debating FE frameworks and focus on the API. We have one question in the process in which we look at the ease/value of rewriting our frontend under each API strategy. This should cover most of the thinking that is specific to FE frameworks.
As we won’t have much time to go into the technical detail in this meeting I invite folks to DM me on Slack if you would like a chat about the technical detail in advance. If there are a few people interested I will aim to organise a prep session with those folks and a dev. So please get in touch if this is you.
Finally, if you want to share other pros or cons at this stage for the 4 methods, go for it. But please try to remain impartial. It might not always be easy - but it won’t help our process by just coming out and saying all the reasons one option is bad/good. I’m really trying to lay the groundwork for an unbiased, unemotional meeting because this is an absurdly emotional topic. So please please please I would so very much appreciate if you could join me in this quest to be unemotional 
Sorry for the long post. Thanks for reading 