Designing an uber backend — part I
When designing a complex(maybe not?) backend for a service, often one needs to come across a term called, “subscription.” Learning computer science at college, I personally did not know thoroughly about what it is and how it is being used because I never encountered a design problem like that by taking exams or school projects. But, the logic is integral in designing real service and want to summarize in very easy words and introduce several concepts relating to it.
Before going into the terminology, I want to update my step by step approaches of designing the backend and why I got to the point of needing the subscription. (If you want to know what subscription is, please go ahead to the next paragraph.) Think about Uber system. We have users of two types: a driver and a customer. Those users need to share entities Places and Rides. There are more entities but these four are basic entities of the backend system. If you are a driver, you just need to current location and wait for a request for a customer, and if you are a customer, you need to send that location to the near by drivers. In this instance, you need some sort of logic to catch customer’s request and verify it(you don’t want to notify a driver in Korea for a request of a customer from Japan), finally find near by drivers and notify them. This logic will be waiting for user’s requests and this is when subscription comes in.
Subscription is to listen on something and once you hear something you take actions. So I have to use pubsub in my application for implementing subscription in my service. Pubsub is an asynchronous messaging service that decouples services that produce events from services that process events. What this means is that pubsub allows to receive messages from customers depending on the topics that pub/sub designed.
As you can see, publisher sends messages. Message is a combination of data and attributes sent to a topic. Topic is a named resource of the messages. Subscription is a named resource representing the stream of messages from a single, specific topic, to be delivered to subscribers. Basically, what we need is to have a pubsub ready for incoming messages.
Because my backend is designed with node and graphql, there was a module called pubsub from graphql-yoga. I referenced here to get my subscriptions running.
As you can see, I defined pubsub in context of the graphQL Server. What this does is that, we can have a pub/sub running as a subscribe in graphQL query. For example, we want a driver subscribing to a channel called driverUpdate because driver needs to update his current location. Then, pub/sub will notice the changes and catch the changes.
This picture demonstrates how this query will be subscribed to a channel. So recap! We created a pub/sub and subscribed to a channel called driverUpdate. Then, how publisher sends the messages to a topic or channel?
This is a mutation of gql, updating the user loation. In this file, once everything is verified including updating to the User entity, I publish my information to the channel. Now real running pub/sub is ready on my application.
As you can see, I was able to see the messages published from publisher.
Conclusion
subscription is very vague idea when you first encounter the term. But implementing it in real service lets you understand why and how we use it in order to use publisher/subscriber idea. Yes, the way I implemented it is very simple and easy. This is one of the reasons why I love node + graphQL because I heard(not sure) implementing the subscription model in spring boot is way harder and complicated. Honestly, I think subscription logic is very hard to implement for beginners. Anyways, I hope this article makes it easier for ppl to understand better the idea of publisher/subscription model!
