Hi, we are AppUnite, we take care of the businesses from a tech perspective. We build products and teams around them enabling our clients to bring the difference to the world.

We believe in knowledge sharing and software as a tool to improve companies and peoples’ lives. We take lessons from our daily challenges and share that experience and knowledge to help you build better products. 

Let’s talk about products, businesses, and software development!

Let's analyze how a [toggle](https://www.techopedia.com/definition/9740/toggle) button that turns activity on and off can be designed and implemented, on the server-side.

## Lack of idempotency leads to unexpected results
Since it is called a toggle in UI, let's call the interface on the server-side that way. A user clicks the toggle, and the app sends the request:

```elixir
PATCH /api/user/activity_status/toggle
```

and the system runs the following interface:

```elixir
def toggle(user_id) do
  user_status = get(user_id)

  if user_status.active do
    :ok = user_turns_off_active_status(user_id)
  else
    :ok = user_turns_on_active_status(user_id)
  end
  
  :ok
end
```

Does it work? Yes, it does. But what happens when the request is sent twice by accident? How do we want our system to react? Should the user be active or inactive?

First of all, the interface is not idempotent. It means that invoking the function several times doesn't produce the same result. Finally, the name of the interface is deprived of ubiquitous language *[E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, p. 24]* that could indicate what result is expected.

There is one more problem. What if the system automatically turns off the active status after 10 PM? We need to add the **if** statement to verify whether the user is active or not to make them inactive:

```elixir
if UserActivity.get(user_id).active do
  :ok = UserActivity.toggle(user_id)
end
```

Has it helped? Let's see what happens, if at the same time, the user tries to turn off their active status and the system does it too?

![](https://appunite-blog.s3.eu-central-1.amazonaws.com/images/c218ce3c/17ea/dG9nZ2xlIGJ1dHRvbiB1bmV4cGVjdGVkIHJlc3VsdC5qcGVn)

When both requests reach the **if** statement the user is active. Then, the user's request invokes the **toggle/1** function and turns off active status. Right after, the worker runs the same interface. This time the status changes back to active as the user's request has just turned the active status off.

To guarantee the user gets the expected result, we need to do concurrency control by wrapping the logic into the transaction and locking the table. As a result, simple behavior that has been implemented incorrectly forced us to add extra lines of code.

## Using idempotent interfaces to change state
The one way to avoid mentioned problems is to modify endpoint and pass parameters that clearly indicate what results are expected:

```elixir
PATCH /api/user/activity_status

{
  active: true/false
}
```

Then the controller decides which interface should be run based on the value of the active field:

```elixir
def activity_status(conn, %{active: active}) do
  user_id = conn.assigns.user_id

  if active do
    UserActivity.user_turns_on_active_status(user_id) 
  else
    UserActivity.user_turns_off_active_status(user_id)
  end

  # ...
end
```

Names of interfaces say about the end-state, so invoking one of them, you know exactly what happens. Even if you do that several times, the result will always be the same. What's more, they clearly show how the domain works, so you don't need to wonder what the purpose of these interfaces is.

medium_toggle_button.png

small_toggle_button.png

thumbnail_toggle_button.png

toggle_button.png

Let's analyze how a toggle button that turns activity on and off, can be designed and implemented, on the server-side.

Make your system more predictable by using idempotent interfaces | AppUnite Blog

Make your system more predictable by using idempotent interfaces

Well, yes. I want to share with you my experience with working while still studying in High School.

## How did it all begin?
As a kid, I was always interested in computers and especially games, so I spent a lot of time there. In junior high school, I got a bit into programming, I didn’t do much more than a couple of simple C++ console programs, but it was fun. The passion continued, but I got bored of writing console programs and started trying new things. I’ve tried a lot of stuff, like web development, desktop programs, developing games, but I always wanted to write an app that’d run on my phone, as I enjoyed the idea of creating something I could take and show anywhere. I’ve always thought of programming as solving my/people’s problems with code.

About 2 years ago, I found a Flutter Bootcamp from my programming teacher and I decided to give it a try as I played with Flutter before. I didn’t think it’d be possible for me to be admitted there (at the Bootcamp), as I didn’t think I was doing great in programming. I was just having fun. I also wasn’t even 18 at that time. So I was a bit surprised when I got a positive response. After the Bootcamp, I was offered a job and that’s how I started my career there.

## Making career and school work together
I started to work with Paweł on quite a big medical video-conferencing app. We were a small team that contained 2 mobile developers, 1 backend developer, a designer, a QA engineer, and a project manager. I didn’t feel as if I was thrown into deep water or anything. I was given the time to slowly get to know the project and work on some small tasks in the beginning. I appreciate that I was given a code review for every simple thing I did, as it taught me a lot.

I was really surprised that everyone was so friendly and open to talk about anything. It made me feel welcome and a part of the team that we make at AppUnite. If I struggled with anything, there was always someone who tried to help me.

At my first meeting with a client, I barely spoke a word, but something that I understood quickly was that as a developer, we have an impact on the product. We’re developing it, after all.

But I wasn’t participating in all of the meetings I could, as I was in school from the morning till like 2 pm and a lot of them were happening before I arrived at the office. The hours during which I’ve worked have always been weird. People often laughed (in a good way) that they were leaving the office when I was just coming in. But whenever I needed some time to catch up with school or anything, I was given time to do so. There hasn’t been much pressure on me at the beginning.

But it all doesn’t come for free. I often was leaving home early in the morning and coming back during the evening. There wasn't much free time during the day to do anything except school and work. Sometimes it felt as if I wasn’t doing enough and to see the effect of my work, I often needed to spend a whole week working on something to see its impact. I remember talking to my Project Manager about working during the weekends because of that, but I was always told not to do so.

## Pandemic - a blessing in disguise
I’ve got a lot more time during the pandemic. I don’t need to commute daily to school, so it saves me a lot of time. Remote school is also less engaging and less stressful than regular school.

Sometimes I still work from the office, but I tend to work most of the time remotely. It even happened that I was attending school from the office as it’s comfy to work from there.

I couldn’t finish this article without talking about team integration, as I think it’s something AppUnite is great at. Currently, we cannot integrate in bigger groups, but I’m sure that whenever it’s possible, we’ll meet as a whole team and celebrate. It doesn’t stop us from meeting in a smaller group with people who I closely work with now. We meet every few months as they live all around Poland and I think that’s great, especially during COVID when we cannot meet every day in the office, so these small parties do matter.

I hope I’ve given some overview on how it is to work while still being at school. Maybe it will also inspire some of you to make the first steps into your career.


large_Being Developer while in High School.jpg

medium_Being Developer while in High School.jpg

small_Being Developer while in High School.jpg

thumbnail_Being Developer while in High School.jpg

Being Developer while in High School.jpg

https://strapi-appunite.s3.eu-central-1.amazonaws.com/covers-with-text/b95cfcd6-127b-4ac3-85f9-5af7d9f7fc64.png

I'd like to share with you my experience of working while still studying in High School.

Hubert Józwowiak

Junior Dev's first days. From writing to releasing your first commercial code