Сьогодні я розповім про мій невеликий проєкт. Як і багато інженерів, я маю кілька проєктів, і вони для мене не просто хобі — це моя можливість вчитися та розвиватися. Насправді, створення цих проєктів стало початком мого шляху у створенні нових речей: щоб навчатися! Я завжди помічав, що я не найкращий учень, коли просто читаю або дивлюся навчальні відео.
Те, що я вивчаю, не залишається в пам'яті, якщо я не використовую це на практиці. Тому я подумав, чому б не застосувати те, що я вивчаю, на практиці? Саме це я й зробив, і з того часу займаюсь цим постійно.
Ці проєкти стали для мене не просто експериментами. Вони перетворились на мій випробувальний майданчик, допомагаючи мені розвивати навички та здобувати практичний досвід.
Один із цих проєктів навіть допоміг мені отримати першу роботу в Німеччині! Це був той самий крок, який дав мені впевненість, навчив стійкості та дозволив продемонструвати свої можливості світові. Це неймовірно, як щось, що почалося як просте бажання вчитися, стало такою важливою частиною моєї кар'єрної подорожі.
Про що мій проєкт?
Цю ідею я придумав багато років тому під час моїх подорожей Європою. Коли я подорожував різними країнами та містами, я часто стикався з однією й тією ж проблемою: не встигав побачити все, що хотів, за один день.
Час завжди був на моєму боці, а надмірна інформація в Інтернеті тільки погіршувала ситуацію. Коли шукаєш в Інтернеті, що зробити в місті, тебе засипають нескінченні списки, статті та путівники. Мені потрібно було щось просте — додаток, який би сказав, куди йти, в якому порядку і як ефективно керувати часом, при цьому мінімізуючи використання Інтернету.
Тоді мені прийшла в голову ідея створити такий додаток.
Звісно, я знаю, що сьогодні існує безліч рішень, які вирішують цю проблему, і навіть ChatGPT може допомогти спланувати твій день без зусиль. Але цей блог не про мій додаток або те, наскільки він революційний. Це про подорож навчання і самовдосконалення, що прийшла разом із його розробкою. Це про те, як я перетворив звичайну проблему на проєкт, який став для мене викликом, навчив мене і зрештою зробив мене кращим розробником. Тож давайте зануримось і розглянемо уроки та досвід, отримані в процесі реалізації цієї ідеї!
Вибір бази коду
Привіт, це додаток, і я не знаю, чи буду я мати iPhone або Android через 10 років. React Native був досить популярним, коли я починав, і він задовольняв всі мої потреби на той момент. Його крос-платформені можливості означали, що я не мав турбуватись про сумісність в довгостроковій перспективі, і це був ідеальний вибір для побудови інтерфейсу додатка.
На серверній стороні я почав з Node.js, але не хотів обмежуватись лише написанням на JavaScript. Вивчення нових речей завжди було моєю пристрастю. Тому я вирішив включити Rust до проєкту. Швидкість і безпека Rust зробили його відмінним вибором для критичних мікросервісів, таких як авторизація та автентифікація. Говорячи про мікросервіси…
Я колись написав детальну статтю про те, чому мікросервіси не мають сенсу (знайти її можна тут: https://medium.com/@dogabudak/microservices-in-2023-5f9d1f3eba69)..) Але коли я був молодшим і наївнішим, я вірив, що мікросервіси — це відповідь на все. Більше того, у мене була блискуча ідея, що якщо я створю кілька сервісів, які взаємодіють один з одним — сам по собі це складне завдання — я зможу використовувати різні мови програмування для кожного сервісу. Моя логіка була проста: більше мов — більше можливостей для навчання.
Спочатку цей підхід здався захоплюючим і добре працював. Але з часом, коли проєкт зростав, я виявив, що управляю шістьма різними мовами для одного додатка.
Для організацій, які приймають цей перехід, переваги в плані гнучкості, стійкості та інновацій є значними, але так само і виклики. У міру того, як ми поглядаємо в майбутнє, взаємодія цих технологій і методологій DevOps буде продовжувати еволюціонувати, формуючи ландшафт розробки програмного забезпечення на багато років уперед.
Перекладено з: Microservices and Kubernetes in Modern Software Delivery