Two queries for the back-end product managers, please.
Please advise.
Whatever consumer-facing front end products use your backend should extend into your analytics. I would also track backend/API response times, which influence how quickly customers experience the front end.
@JesusRojas, you make a valid point about the front-extension end’s consuming the back-end.
I might have a stock trading application, let’s say. I am keeping an eye on the core trading service, which streams financial products and their pricing in real-time via a Kafka cluster and is connected to a market data source on the back end. This core service receives buy and sell orders from the trading core service while also being connected to an outside broker.
The users access market data through the FE and also submit their buy and sell orders there.
Let’s suppose that I am in charge of the BE’s key trading service. To ensure that you improve the trade engine with the consumer in mind, how would you translate from the FE to the BE and produce BE appropriate customer-centric measurements?
The three APIs’ response times would be the primary focus of the measurements.
API that allowed FE and BE to communicate.
API that allowed for communication between a real-time market data supplier and the core trading service.
API that enabled communication between the external broker and the core trading service.
Do you agree?
Your metrics should focus on availability, price, and speed. Always keep in mind that you are supporting the front end.
MVPs shouldn’t differ all that much from the front end either. What is the simplest product you can create to meet the criteria and establish the foundation for larger ones in the future?
@DonovanOkang, How do you evaluate the cost factor? Please elaborate on that.
@MartyRoss, Utilization of servers, resource allocation (questionable, but worth mentioning), and downtime costs are some of the factors to estimate the costing.
From a technical perspective
Get some practical Postman experience, at least to begin with.
Use Charles to record the traffic from the client to your API. Describe how clients use/abuse the API and a typical request and response flow. Even the http headers that they submit should be of interest.
Finding the discrepancies between how a client uses your API and how you want them to use it is always enlightening. When you see the disparities, ask “Why?”
Hello Prowess. I’m new to the community.
Could you explain how you set up and use Charles?
Hello @AnthonySmith. Welcome to the Prowess Community.
For detailed directions, it’s definitely worth a few Google searches, but here are some points.
Warning: If this is unfamiliar ground, be aware that it may be labor intensive. However, if you really want to get into the experience of your normal consumer, I’d advise doing this a few times a year. I compare this procedure to if you were a website PM and investigated Fullstory flows for your users.
When I monitor a mobile app, I usually run Charles on my Mac, a debug app build on my iOS or Android device (without certificate pinning), and I use a proxy to forward all traffic from my device to the IP address of my computer. When setting this up for the first time, it might be somewhat overwhelming. Ask engineering or QA for assistance.
Another choice is to hire someone to record all of the traffic for you. They could even create a video of themselves using the Charles client and capturing traffic before sending you the Charles session file. You can watch the video as many times as you wish while walking through the traffic.
Additional challenging queries:
Q: Why not just rely on the logging tools the technical team has in place; you ask as a backend PM?
A: Since most network logging software only records partial responses and requests, it might be challenging to evaluate the traffic coming from a single client if they aren’t always giving the correct credentials with each connection. You may record a complete network connection, replay it numerous times, export requests to Postman or curl to experiment with, and quickly search through ALL traffic from a typical Restful API client using a program like Charles (or Wireshark or mitmproxy).
Q: How can I track traffic using https?
A: This can be challenging. You can instruct the client’s app or device to trust a certificate if the client has a mobile app or website. However, you might need to speak with your client or technical team to get them to put you in the proper route or to give you a customized build for network traffic monitoring.
Excellent answer, @FlaviaBergstein. Thank you so much for the reply and also for the warm welcome to the Prowess community.
No problem @AnthonySmith. As long as the client doesn’t proxy their requests through their own backend, inspect the traffic. If they do, you’ll have to analyze your own engineering team’s logs.
PM for an API might be similar to planning for a freeway system. You can take a helicopter up from time to time and watch rush hour traffic and see how things are flowing. Or you can place a GPS device on a car and experience a single journey.
Welcome to Prowess @AnthonySmith. Excellent quest and really awesome replies by @FlaviaBergstein.
My opinion for OP’s concern is thus:
Backend PM is similar to any other PM. obtaining both qualitative and quantitative input from API users, reviewing the API design, and keeping track of clearly stated KPIs. In particular, for KPIs, it’s critical to follow the customer journey and identify outliers with poor experiences in addition to typical response times and mistake rates.
With an API, you could occasionally find that a small percentage of users are requesting it in a way that degrades performance. Possibly even worse if they are your star clients.
Other KPIs could include things like discussion rates and retention rates, depending on the service. How many people engage with your API at first, but then stop using it altogether or just utilize a few endpoints.
Thank you for all the responses!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.