Description
Context 💭
As a person who uses Apps/Services, I hate it when my data is locked up in a "walled garden".
A service might initially solve a problem for me but I have no control over my data, so when it goes bad (e.g. because the megalomaniac sociopath founder wants all your personal data so they can sell you to ads even though there were no ads when you joined in 2007 to stay in touch with friends ...),
I cannot leave the platform without losing all (or most) of my data!
Sure they might provide an API but it's always limited in scope to what they want you to have.
We want to always ensure that all actions that can be performed in the Web UI can also be done via REST API and all real-time notifications/updates can be subscribed to via WebSocket API1.
That way anyone using our App can always access all of their data and they are not locked-in to using our service(s).
This is in keeping with our Manifesto: manifesto.md#your-data-is-yours
Story 💡
As a person storing lots of important data in the @dwyl App,
I want to be able to access all of my data at any time via an API
So that I can extract, analyse, update or export my data if I chose to.
As people using the @dwyl App ourselves this is what we would expect from a good great App. Ideally we want to have the API from day 1 (MVP) so that people can immediately access and create their data programmatically.
Todo
- Define the scope of the API ("everything" isn't a scope!)
- How will we document our API
- Will we conform to a particular API Spec e.g: JSON Schema What is a JSON Schema and why is it useful? How do I create/use a JSON Schema? learn-json-schema#1
or are we better off just following the good examples that don't conform to a Spec?
see: Ask HN: What is the best API documentation you have ever seen? learn-api-design#39 either way I think it's worth updating our knowledge of APIs https://github.com/dwyl/learn-api-design before embarking on building our API. - Explore Content Negotiation as a way to keep the App and API as the same Phoenix App.
- Tutorial to Consolidate our Understanding: Create Content Negotiation Tutorial phoenix-content-negotiation-tutorial#1
- [SPIKE] Create Content Negotiation Plug: [SPIKE] Create Content Negotiation Plug that *Any* Phoenix App can use! content#1
- Publish
content
Plug to Hex.pm: https://hex.pm/packages/content
1 As noted in our "Why Elixir" thread: dwyl/learn-elixir#102 one of our key reasons for selecting Elixir/Phoenix for our backend tech is for Channels which we feel is one of the "super powers" of the language/framework! Having a scalable Realtime API with presence is one of the key features we need to have for teamwork.