BYUN Kyuhyun

When comparing UI Bakery and Retool for operating in-house data and creating dashboards with charts, both platforms offer strong capabilities but have some key differences. Let’s examine how they compare in these specific areas: Data Handling and Integration Retool Retool excels in data handling and integration, making it a strong choice for operating in-house data[1][4]. It offers: Powerful integration with external data sources, including APIs, databases, and cloud services Support for SQL/NoSQL databases and services like Firebase, MongoDB, and PostgreSQL Real-time data syncing between the UI and data sources UI Bakery ...

It’s difficult to definitively say one is “better” than the other, as each has its strengths and is suited for different use cases. However, I can provide a comparison of their key features and performance to help you make an informed decision: Performance and Scalability Appwrite consistently outperformed Supabase in stress tests, especially when scaling up to handle more users[1][4]. For example: On a €5/month self-hosted server, Appwrite handled up to 2,000 users per day comfortably, while Supabase struggled with larger loads[1]. On a more powerful €30/month server, Appwrite managed up to 250 simultaneous users, while Supabase hit its limit at only 45 users[1]. In breakpoint tests, Appwrite reached 6,800 virtual users, processing 100,000 requests with an average 3-second response time. Supabase reached its breakpoint at 3,000 virtual users, with 59,000 requests and a 6-second average response time[4]. Ease of Use Appwrite offers a smoother self-hosting experience with fewer restrictions and less setup complexity[1][3]. Supabase can be more challenging to configure in a self-hosted environment and has some features restricted or limited when self-hosted[1][3]. Features Both platforms offer similar core features, including authentication, databases, storage, and serverless functions. However, there are some differences: ...

Connection Mode (Session Mode) Each client maintains a dedicated connection to the database for the entire session duration[2]. The connection is only released back to the pool when the client disconnects from the database[2]. This mode replicates a direct connection to PostgreSQL and supports all PostgreSQL features and mechanisms[2]. It’s safer and more compatible with all PostgreSQL clients[2]. Does not significantly reduce the load on database resources[2]. Transaction Mode The connection to PostgreSQL is maintained only for the duration of a transaction[2]. When the transaction completes, the connection is returned to the pool and can be reused by other clients[2]. Allows for a higher number of client connections (up to 10,000) with a smaller pool size[2]. Reduces the load on DBMS resources, especially beneficial for a large number of low-load client connections[2]. More efficient in terms of resource utilization, as idle connections are released back to the pool[3]. Key Differences Connection Duration: ...

Summary “고언어 프로젝트 가이드 A-Z"라는 주제로, 작은 프로젝트부터 엔터프라이즈 애플리케이션까지 Go 언어를 사용한 개발 방법론에 대해서 공유해보았습니다. 작은 프로젝트와 큰 프로젝트의 차이점을 설명하고, 작은 프로젝트에 적합한 간단한 코드 패턴을 소개하고, 기능 단위의 프로젝트를 위한 코드 패턴으로 Handler와 HandlerFunc 방식을 비교하고 각각의 장단점을 설명합니다. 엔터프라이즈 애플리케이션을 위한 코드 패턴으로 Domain Driven Design (DDD) 접근 방식을 소개하고, 각 레이어(Presenter, Handler, Usecase, Service, Repository, Recorder)의 역할과 장점을 설명합니다. NoSQL 데이터베이스 (DynamoDB) 사용 시의 모델링 방법을 간략히 소개합니다. 그리고 각 레이어에서의 테스트 코드 작성 방법과 모킹 도구인 counterfeiter의 사용법을 설명합니다. 애플리케이션 릴리즈를 위해 필요한 도구들(APM, 에러 모니터링, 메트릭 수집, 로그 서비스)을 소개하고 그 중요성을 강조합니다. ...

Summary Gophercon Korea 2023에서 발표한 “Go 도입 후, 4년 간의 기록"이라는 주제로 공유했습니다. Go를 도입하여 높은 트래픽을 처리하고 있으며, 주요 이슈와 해결 방법을 공유하고, Go를 통해 더 효율적이고 안정적인 서비스를 제공하기 위한 고민들을 공유합니다. Youtube Slideshare Go 도입 후 4년 간 기록 from Kyuhyun Byun

의사결정과 업무 진행은 프로덕트를 사용하는 고객관점에서 시작한다. 고객관점이라는 말은 많이 하지만 실제로 이게 왜 사용되어야 하는지 두 가지 방면에서 설명한다. 1. 조직에서의 의사결정 측면 이런 상황은 자주 발생했을 것이라 생각한다. 서로의 팀원(혹은 조직)의 생각이 달라서 벌어진 상황이다. 각 팀원은 수단에 대해서 집착을 하게 되고 이야기가 평행선을 달리게 된다. 이때 어떻게 이야기를 하면 문제를 해결할 수 있을까? 고객이 겪는 문제 상황에 대해서 먼저 정확히 이해하는 게 필요하다. 혹은 고객에게 꼭 필요하다고 생각하는 것에 대한 정의가 필요하다. 이를 문서 최상위에 “목표”로 정의를 한다. ...

The word “burnout” is being heard from all directions. It is being expressed as a reason for quitting, changing jobs, taking vacations, and as a way to express difficulties in life. I think everyone has heard it at least once, and I believe there have been times when you’ve wondered if you are experiencing burnout. When I hear people talking about burnout, I often feel a deep sense of sympathy, but I also feel that there is little I can do to help. I can suggest various things to try, but those who are experiencing burnout often don’t seem to hear those suggestions. So, while contemplating what to do, I decided to write this. ...

번아웃이라는 말이 사방에서 들리고 있다. 퇴사 사유로, 이직 사유로, 휴가 사유로, 인생에 대한 어려움을 표현하는 방법으로 표현되고 있다. 다들 한 번씩은 들어봤을 거라 생각한다. 그리고 내가 번아웃인 상태가 아닌지 생각해본 적이 있을 거라 생각한다. 옆에서 번아웃 이야기를 들을 때, 정말 안타까운 마음이 들면서도 크게 도와줄 방법이 없다고 느낀 적도 많다. 여러가지 시도해볼 수 있는 이야기를 하지만 번아웃에 빠진 사람은 이야기가 들리지 않는다. 어떻게 해야할까 고민을 하다가 이렇게 글을 써본다. “나는 번아웃이 온 적이 없다.” ...

배경 AWS re:Invent 2023에서 “A career journey for serverless and container cloud developers” 라는 공통주제로 발표를 준비했다. 여기서 중요하게 다루고자 했던 것은 소프트웨어 엔지니어가 이전의 프로그래머 시대와 어떤 부분에서 노력할 지에 대한 방향이었다. “소프트웨어 엔지니어의 덕목” 이라는 주제로 시장이 변화해감에 따라 엔지니어의 다른 역량들을 더욱 필요로 한다는 점을 표현하고 싶었고, 이런 관점을 공유함으로써 다양한 엔지니어의 성장에 조금이나마 기여하려 하였다. 발표 자료 및 영상 References https://youtu.be/gdqgk17T2Xw?si=sPEVjrg7rIFmeI4S

배경 아우쓱콘(https://festa.io/events/3504)에서 발표 요청이 왔고, 주니어 엔지니어에게 하고 싶은 이야기를 해달라고 하였다. 덕분에 지난 시간을 되돌아볼 수 있었고, 작게나마 이야기를 정리할 수 있었다. 무슨 이야기를 하면 도움이 될까 고민을 했다. 주니어 때 가졌던 고민을 무엇이었나. 이런 상황들이 있었다. 쏟아지는 상황에 지쳐있었다. 앞이 보이지 않는 상황에 지쳐있었다 새로운 지식을 미친듯이 공부하고 있었다. 찍먹하면서 다양한 지식을 습득하고 있었다. 무작정 해보고 잘 안된다고 생각하고 있었다. 이런 상황에서 다양한 선택들을 해보고 방법을 찾아보았다. 그중에서 배운 방법들이 있었고, 잘 동작한다고 느꼈다. 이를 공유하는 것을 목표로 삼고, 이를 본 많은 사람들 중 한 명이라도 도움이 되었으면 하면서 발표를 준비하였다. ...