ibmstocktrader / broker Goto Github PK

Today if you do a GET /broker/, that returns all of the brokers that exist. That's fine if you only have a few, but if you had thousands or more, this isn't a good idea, as we could run the server out of memory, response time could be too long, etc. Need to add a way to ask for the first 20 or 100 or whatever, then ask for the next page in a separate REST call, etc. Of course, this means the downstream microservices, like Portfolio and Account, would similarly need such pagination. We'd probably also need to add some kind of "order by" support, to make sure we get the same first 100 from Portfolio that we get from Account.

Today all of our calls are synchronous - that is, we make a call and sit and wait on the work to happen before returning. For some calls, that's unavoidable; if someone asked to see the details for a particular portfolio, we do in fact have to wait on all of those details (like the details for each stock owned) to return from the downstream microservices before returning the result back to the client. As an aside, there are things we can do, like using a CQRS pattern, to speed up queries, so that the GET calls return faster. But putting that aside for now, there's no reason we need to wait on the other calls that request some work happen in the system, such as creating a new portfolio, or deleting one, or updating one (like to buy or sell stock).

Those could be made using the asynch REST call pattern (as my co-author explains in chapter 4 of our book: https://www.amazon.com/Practical-Cloud-Native-Java-Development-MicroProfile/dp/1801078807, or at this blog: https://openliberty.io/blog/2019/01/24/async-rest-jaxrs-microprofile.html). The only caveat is that if the client immediately attempts to view stuff - like if it shows all portfolios in the system immediately after creating a new one - the list might not show the newly created one (it would be a race condition as to whether it was in place in time to show up in the quickly issued query). Same with buying stock; if we make that asynch, but the client immediately shows details of the given portfolio, the newly bought stock might not show up. We could potentially code in a sleep for 100 milliseconds or whatever, or other approaches to not make it be the query is happening the very next millisecond after the create/update/delete.