iTranslated by AI
Developing 'SwimIn', a New Social Media Platform Based on Sleep
Introduction
I discovered programming around September 2023, became obsessed, and have been studying on my own ever since. Thanks to some good luck, I received an offer from a web-based in-house development company around December, and I am set to start working as an engineer next April.
During my job hunting, I built a portfolio (an attendance management app), but looking back now, I realize it wasn't exactly modern development. I used vanilla JavaScript, prepared multiple HTML files, and didn't even know what an O/R mapper was, so I was hard-coding my SQL queries. (I recall seeing that approach on Progate.)
Of course, I know that some professional environments still use that kind of structure, but I really wanted to experience modern, popular development practices. That's why I embarked on a full-stack project and completed "SwimIn" in about a month.
What is SwimIn?
It is a "sleep SNS" that allows you to know if your friends are sleeping.
URL ▶︎ https://swimin-app.com
Service is currently suspended as of 5/27.
Github ▶︎ https://github.com/YutaKakiki/swimIn
To be more specific, it displays information such as:
- When you went to sleep / woke up
- When you plan to wake up (Target wake-up time)
- The difference between the target wake-up time and the actual wake-up time
- Woke up exactly on time
- Overslept by XX hours and XX minutes
- Woke up XX minutes early
- Whether you are oversleeping (based on the target wake-up time)
- Comments
As I will explain in the "Features" section, sleep data is managed via "check-ins" when users go to sleep and wake up. Based on this information, average sleep duration, sleep duration, and target wake-up achievement rates can be visualized on a weekly/monthly basis.
Also, this app is designed for mobile devices only and is not responsive for PC. The assumption is that you wouldn't typically boot up a PC just before going to bed or right after waking up.
Background of SwimIn Development
The motivation behind conceiving this app lies in the shutdown of the location-sharing service "Zenly." Some of you may not be familiar with it, but Zenly had a feature that displayed whether a user was "Sleeping."

Although other location-sharing services have emerged as alternatives, I couldn't find one with a similar feature. I personally loved this functionality, and my friends used to utilize it for things like "Hey, they're asleep, that's why they aren't at school, let's call them to wake them up," so it was quite practical. That's when I decided to build an SNS where you can see when others are sleeping or awake!
The name "SwimIn" comes from the flow: Suimin (sleep) -> Swimin -> Swim In -> SwimIn lol.
Features
Authentication
- Sign up / Sign in / Sign out
- Implemented using devise_token_auth.
Profile Functionality
| User Info Editing |
|---|
![]() |
| - Edit name / email / profile image At this stage, Gravatar is used for profile images. |
Following Functionality
| Friend Search → Add Friend | "Added you" |
|---|---|
![]() |
![]() |
| - Search and add other users via email address | - Displays users who have added you but whom you have not added yet - You can also add users from here |
Core Functionality
| Viewing Friends' Sleep Status | ||
|---|---|---|
| List | Details | |
![]() |
![]() |
![]() |
| - Display sleeping/awake status - Display oversleep alert |
- Target wake-up time - Bedtime |
- Wake-up time - Sleep duration |
Technology Stack
| Category | Technology |
|---|---|
| Frontend | typescript(5.0), React(18.0), Next.js(14.1.4) |
| - Yup (form validation) - MUI (UI components) |
|
| Backend | ruby(3.1.2), rails(7.0.8) |
| - devise_auth_token (authentication) | |
| Database | mySQL2 |
| Infrastructure | AWS ECS Fargate |
| Web Server | Nginx |
| Environment Setup | docker, docker-compose |
| CI/CD | GithubActions |
Architecture

(https://zenn.dev/ddpmntcpbr/books/rna-hands-on/viewer/intro#構成図)
ER Diagram
Reasons for Technology Selection
Started Development from "Technologies I Wanted to Use"
- First, although it might not be the most ideal reason, before proceeding with development, I had a strong desire to "try out modern full-stack development that separates the frontend and backend, which is commonly seen in recent development environments." Ideally, the choices should be based on the content and purpose of the application.
- The article I referred to is as follows. Rather than a reference, I imitated the entire architecture:
【Self-study Portfolio Development Support】 Practical Hands-on Guide: Rails × Next.js × AWS for Beginners - Also, the decision to use Next.js for the frontend was influenced by viewing this article:
-
Next.js Introduction for Rails Engineers
This is a talk from Kaigi on Rails 2021. It was mentioned that while it is possible to build SPA-like features using Hotwire, I had the mindset of "wanting to ride the de facto standard for the frontend." Since I was going to write a frontend, I thought, "Might as well learn Next.js!"
-
Next.js Introduction for Rails Engineers
- The article I referred to is as follows. Rather than a reference, I imitated the entire architecture:
-
Frontend
- React
- Can build SPAs
- Can use UI components
- Next.js as a React framework
- No routing configuration required; structure can be built via directory organization
- Can build SSG for all pages by default (SSR is not used here)
- Pre-renders HTML at build time, so it's fast
- This application uses a CSR+SSG configuration
- typescript
- Can define types for variables, arrays, and objects
- It's not just about safety; it's also easier to understand what data is contained by looking at the defined type aliases
- Can define types for variables, arrays, and objects
- React
-
Backend
- Rails
- Easy to develop in a RESTful manner
- Can use API mode to separate frontend and backend
- Rails
-
docker
- Development environment can be coded, making environment setup easier
- It was nice to complete everything with docker-compose.yml and Dockerfile
- Development environment can be coded, making environment setup easier
-
AWS ECS Fargate
- Serverless containers
- No need for instance type or cluster management
Note: I cannot say I fully understand AWS, but I have a "vague" understanding.
-
GithubActions
- CI/CD workflows can be written as code
- Initially, I didn't even know what CI/CD was, but it was great to learn the benefits of running tests upon pushing to git, automatic deployment, etc.
Ingenuity and Key Improvements
Minimized Page Transitions
- I worked on reducing stress by minimizing page transitions using modals and slides.
How to Record Sleep Time
- It's hard to explain, but for example, if you go to bed at 23:00 on 5/26 and wake up at 7:30 on 5/27, there are also days when you go to bed at 1:00 on 5/27 and wake up at 7:30 on 5/27. In either case, the date of the data needs to be 5/26. Even if you go to bed after midnight on 5/27, it's considered "yesterday" in our perspective.
Sorry, this is hard to explain! Basically, I just mean I put effort into conditional branching.
Instant Status Check for Friends
- I made it easy to distinguish: blue for sleeping, green for awake. Also, users who have recently updated their status are displayed at the top.
Reference Articles
-
【Self-study Portfolio Development Support】 Practical Hands-on Guide: Rails × Next.js × AWS for Beginners
I mentioned this in the main text, but this article was truly excellent. Through this article, I was able to learn and practice full-stack development. I struggled quite a bit with deployment on AWS and can't say I fully understand it, but I'm glad I had the experience. Furthermore, since I could also learn GithubActions, I didn't even know the concept of CI/CD at first, but I thought, "Oh, this is great."
Taking this opportunity, I also learned docker through books. I didn't understand it well at first, but I really felt the benefits of easy environment setup.
Future Prospects
Based on using the app in the production environment and comments from friends who used it, here are the features I would like to add in the future:
- Notifications via LINE
- I realized that "Good Night" and "Good Morning" stamps are very easy to forget. Therefore, by linking with LINE and sending notifications, I think users will be less likely to forget.
- I wonder if it works by hitting the API provided by LINE?
- I realized that "Good Night" and "Good Morning" stamps are very easy to forget. Therefore, by linking with LINE and sending notifications, I think users will be less likely to forget.
- Retroactive application for bedtime and wake-up times
- This is also an improvement related to forgetting to stamp. At the current stage, the usage is to stamp in real-time, and values are calculated automatically, but if retroactive application is possible, sleep records can be kept accurately.
- Incidentally, under the current specifications, the sleep time is 0 if you don't stamp, and it is not included in the average sleep time.
- Direct profile image upload
- Under current specifications, profile image uploads are left to Gravatar. Originally, I planned to use Active Storage, but it didn't go well, so it turned out this way.
- However, having to transition to another service is a stress, so I think I must improve this.
Also, there is still a slight bug in the sleep history graph, which sometimes results in unintended outcomes. This is also a place that needs fixing in the future.
Incidentally, the "You have been added by this friend!" feature was added based on feedback from a friend. After all, you won't see the flaws until you actually use it, so the flow of getting feedback & becoming a user yourself → improving is very important.
I will be stepping away from personal development for a while, but I want to do the above things in the future.
There are other things I want to do, so I might not do it for a while, haha.
Reflection
It took about 5 months to study and understand (of course, not perfectly, but "vaguely" in the basic parts) Ruby, Rails, TypeScript, React, Next.js, Docker, and full-stack development (the aforementioned Zenn article), and it took 1 month for this personal development. The reason for choosing the technologies was, to put it simply, "because they are trendy and I wanted to use them," which feels a bit like a "fanboy," but both Next.js and Rails had, needless to say, a great developer experience and were very enjoyable. Building an API with Rails and hitting it with Next.js was personally thrilling. I was excited during the first health check. Also, when I was building the UI by combining components, it was like Lego blocks, which was fun.
As for the app itself, friends have been using it for a trial period of about a week, and since it costs money, the service is currently stopped.
Although there are surely still rough edges in the app, I think the experience of being able to create an app that can be used has become something of great value.














Discussion