Microservice Design

    In a previous post, I wrote about the pros of using microservice architecture. Now I want to describe the process of creating one useful microservice. Looking ahead, I’ll say that there will be another “microservice” article devoted to the sad result of the pursuit of technology, not meaning.

    Task


    In the test assignments from Wheely, I had to implement authentication through the code in the SMS message. The essence of the process is as follows:
    1. The user is performing an action.
    2. To confirm this action, a code is generated.
    3. The code is sent in an SMS message.
    4. The user specifies a key.
    5. The key is checked for compliance.

    The result was to be an independent application that performs the tasks specified in paragraphs 2, 3 (only imitation), 5 . Pins are no longer relevant 2 minutes after generation. Everything else is up to me.

    I have performed a similar task (with varying degrees of elaboration) twice already, however both times as a monolithic service, trying to use the technologies that were already in the project. In the same task, it was pointed out that special attention during the verification will be given to my choice of tools.

    Sketch


    So, I am writing a microservice that will interact with the main client application through the API. The service is based on two main components: creating a pin and checking it.

    The dashed frame marks the components responsible for the interaction of the service with the main application.

    Instruments


    Database

    Here it is worth paying attention to the low weight and short duration of storage of the pin record. It is also worthwhile to focus on processing a large number of codes.

    The superfast REDIS database is ideally suited for these conditions , since in addition to speed, it also has a wonderful expire option, which sets the record storage time. Thanks to this small option, we get rid of the code that serves the function of “delay”, and also do not load expensive memory with our database useless information.

    Web application

    We need REST, we don’t need views and the redundant (in this case) set of “helpers” that many frameworks offer. Sinatra in this case is a very good option: a lightweight DSL for the web.

    Project


    In this chapter, I will talk specifically about microservice features of development and very superficially describe the principle of operation of application components. If readers have an interest in the process of developing the service itself, then I will try to prepare a separate publication for this.

    First, we decide which parameters will run inside our service:
    1. api_token - application key;
    2. operation_id - unique operation code;
    3. phone - phone number;
    4. code - n-digit confirmation code.

    Now we will write down the algorithm of the components.

    Create a pin

    1. We send a request:

      POST 'https://test.dev/api/v1/pins', api_token: 'zx..d', operation_id: 'cs12', phone: '79..1'
      

    2. We check access by api_token.
    3. We generate a unique code and add an entry to the database (SET pins: $ operation_id $ code) .
    4. We are sending a message with a code.
    5. We return the answer.

    Check

    1. We send a request:

      POST 'https://test.dev/api/v1/pins/cs12/check', api_token: 'zx..d', code: '2213'
      

    2. We check access by api_token.
    3. We verify the received code and the code that is stored in conjunction with the operation -> if successful, delete the record from the database.
    4. We return the answer.


    We generate answers

    In this case, both of our components will return identical answers in structure. If successful, STATUS 200 , otherwise STATUS 403 .

    Summary


    Great, our application accepts data, processes it and returns a response. We can assume that it took place as a microservice :)

    Pros:
    • The main application remains compact.
    • Optimal for implementation (less than an hour).
    • The whole system is easier to maintain and cover with tests.
    • Hypothesis: increased stability. The departure of the microservice offline does not affect the operation of our product in any way, since it simply switches to a spare service.

    Minuses:
    • Delay in communication through the API.
    • Additional resources for deployment.

    I would like to end this publication on a positive note, since in this case the result met all expectations. However, I immediately want to warn the reader that microservice architecture is not suitable for everything. But this is a completely different story.

    UPD. 1. Translated response format from jason to status codes. Thanks f0rk and smileonl for recommendations and clarifications .

    Also popular now: