Is there a public API for Monzo? I’ve been knocking up a personal finances app in my spare time - and it would be cool to hook it up to my Monzo account.
There is and there is quote a lot of talk about it
Cool - I can’t find a link to the docs?
I haven’t been across it recently, but there was due to be a complete rewrite of the API, so anything built currently may break at some point if/when v2 comes along. It seems that this still hasn’t completely happened yet so the health warning seems to still be there.
Ok - cool… so not worth touching at the moment until some stability is reached. I wonder if they plan to go the GraphQL route. Just ported our API to it - and its WAAAAY easier to maintain - also more future proof.
Here’s the landing page, for others and future reference:
You might find interesting this list of things that people have already done, despite the ‘instability’
I wonder if they plan to go the GraphQL route
Why? To me the only advantage of GraphQL is to minimise the number of HTTP requests for mobile devices (although HTTP/2 should make this irrelevant).
For server-to-server communications this isn’t an issue and REST seems a lot better.
I disagree that the advantage lies there. I would argue that if you really understand the use cases of your REST API, you can design it in such a way to mitigate over fetching / many HTTP requests. In other words - before designing a REST API (and I mean a proper REST API - most ‘REST APIs’ aren’t actually REST) you really need to understand your users needs.
To me, the advantage of GraphQL is that you can defer this understanding of how your users will use your API. You can profile queries, evaluate their complexity and do away with all this V1/V2 nonsense… you can continually evolve and improve your API with fewer or no compatibility issues. In this respect, GraphQL is more flexible.
At the moment, it sounds like Monzo are still figuring out the use cases… in this case, I would argue that GraphQL is advantageous over REST.
Very impressed Cheers - will pull some of these tomorrow
Within the constraints of the schema https://www.apollographql.com/docs/apollo-server/v2/essentials/schema.html
However, that’s where the fewer http requests come from - you can grab all that you need in fewer (often one) hits. Downside is, no real cacheing…
Exactly… it’s not really a viable cache solution. However, for our purpose, it was a reasonable tradeoff
specify exactly what data you wanted
This makes me really uncomfortable. Too much risk of exposing something I shouldn’t (potentially due to a bug in the GraphQL server library).
I’ll stick to REST where I can define the format of the responses directly. It’s also much simpler to implement (you don’t even really need a server library) so less risk for something to go wrong.
Only if your schema allows it… you can control which resource / data is made available. You can even restrict access to resources based on user. There are a lot of misconceptions about what GraphQL is.
Yeah I’ve been holding off until the stable version is released. The last update was in January, and references waiting for the final Open Banking API, which the official site for seems to suggest is already in operation in the largest banks.
I’ve tried asking on the Dev Slack if anyone has any information on v2, but radio silence so far…
You’re much more likely to return too much data with REST than you are with GraphQL. In GraphQL you have to specifically pick which fields will be returned in the schema, whereas with REST you can return whatever the code says to return.
We’ve just finished moving all of our 40+ microservices over to be united under a single GraphQL endpoint (which is called both from the UI and from other microservices) and we’ve been seeing massive benefits already.
The area where GraphQL is weakest is that it only really revolutionises querying, not modifying data. Mutations aren’t mind-blowing, although they’re no worse than REST already is for that sort of thing.