API & Endpoints

[00:00:00]
>> Jem Young: I went ahead and created the APIs because I think we know how to do that before we're going to walk through slowly, but this is the flow and how I think about designing a system. This is what has kept me from making mistakes often, just having this sort of visibility and maybe I'm too pedantic here. But for me it really helps, especially with the credit app where kind of the API is pretty simple and most of the work is in designing the API correctly.

[00:00:30]
Everything else kind of falls after that, very different from, you know, a logging service or something like that, where the API is going to look very different. So for the API, you know, I look at APIs as just a literal translation of the business requirements into code, which we said is an art, but if you can get from functional requirements and nonfunctional requirements into an API, most of the work is done already for a simple app like this.

[00:01:00]
Then we can lay it out and it's all about getting to the edge cases and the actual details of the system. From there, again, endpoints are optional, but it's something I like to think of and I list them out and say like this is an endpoint, this is an endpoint. This happens when you have, say, an API that is particularly complex, like, I don't know, calculate stock market return of two different ticker symbols or three different ticker symbols, that's probably going to have a different endpoint because that's going to be an expensive calculation.

[00:01:30]
So we're not going to lump it all together. If you're saying yes, we can use GraphQL for this, we could, it would just be one endpoint, but this isn't merit the complexity of needing something like that. And that's something else you want to think about when you're designing a system is, what's the simplest, cheapest thing you can do, not just the most rigorous, overengineered, whatever you want to call it.

[00:01:52]
That's why I list out the endpoints. And when you put them like this, oh, there's only actually three. There's lists, lists, or just lists, task or to-do, and login. It's really it. So all the functional requirements just boil down to about three endpoints, which makes it really easy and reason about the system. So we've already done this. We've identified the entities, we designed the API. We haven't described the data flow yet, but we'll do that this next section we talked about scaling because then we just put all together in one beautiful package instead of switching back and forth a lot.