مت رابل از Okta: چگونه یک هیپستر جاوا شدم

حامی توسعه‌دهنده Okta و مبشر JHipster در مورد توسعه جاوا و جاوا اسکریپت، یکپارچه‌سازی و میکروسرویس‌ها، مقیاس‌بندی نرم‌افزار در مقابل مقیاس‌گذاری افراد، و ایجاد امنیت دوستانه‌تر برای توسعه‌دهندگان بحث می‌کند.

مت رایبل یک مربی معروف جاوا و جاوا اسکریپت با چندین کتاب به اعتبار و تجربه وسیع او در این صنعت. او در حال حاضر وکیل توسعه‌دهنده در Okta است، جایی که او بر روی امنیت تمرکز می‌کند. عضو هیئت مشاوره فناوری JHipster، یک پلتفرم توسعه ترکیبی جاوا و جاوا اسکریپت.

JHipster اساساً یک ابزار ساخت پیشرفته است که توسعه برنامه های کاربردی تمام پشته را که از قسمت های جلویی واکنشی استفاده می کنند ساده می کند. از Spring Boot در قسمت پشتی استفاده می‌کند، از React، Vue، Angular و دیگر فریم‌ورک‌های JS در قسمت جلویی پشتیبانی می‌کند، و شامل داربست‌هایی برای داده‌های رابطه‌ای مبتنی بر JPA و داده‌های NoSQL مانند MongoDB و Cassandra است. می‌توانید راهنمای من در مورد JHipster را اینجا بخوانید.

من این فرصت را داشتم که با Raible درباره JHipster، جاوا، جاوا اسکریپت، امنیت، monoliths در مقابل میکروسرویس‌ها، زیرساخت ابری و موارد دیگر گپ بزنم.

مت رابل

متیو تایسون: شما به مردم کمک می‌کنید تا همیشه درباره کدنویسی بیاموزند. شما در طول این سال ها بشارت های جاوا زیادی انجام داده اید. اکنون شما کمی در مورد چارچوب های جاوا اسکریپت و جاوا اسکریپت صحبت می کنید. چه چیزی باعث شد بیشتر به JS نگاه کنید؟

مت رابل: جاوا اسکریپت اولین عشق من بود. من یکی از آن برنامه نویسانی هستم که زبان اولش HTML بود. به سال ۹۲ برگشت. مدت کوتاهی بعد جاوا اسکریپت و CSS را یاد گرفتم و شروع به ساخت وب سایت کردم. من تا سال ۹۹ شروع به یادگیری جاوا نکردم.

اگرچه توسعه Spring و back-end جالب بود، اما عشق واقعی من نبود. این همیشه رابط کاربری بوده است. من در حدود سال‌های ۲۰۰۷-۲۰۰۸ به توسعه UI بازگشتم و تا سال ۲۰۱۶ یک “معمار UI” برای چندین مشتری بودم.

در سال ۲۰۱۶، صبح برای CA کار می‌کردم و JS را انجام می‌دادم و بعد از ظهر قرارداد دیگری با Stormpath داشتم که جاوا را انجام می‌داد. Stormpath سعی کرد مرا به‌عنوان یک توسعه‌دهنده جاوا به‌طور تمام وقت استخدام کند و من به آنها گفتم: “نه، من واقعاً نمی‌خواهم همیشه جاوا را انجام دهم.” مذاکرات ما برای چند ماه متوقف شد. سپس یک نامه “کار رویایی” نوشتم و برای آنها فرستادم. این شامل حمایت (پست های وبلاگ، سخنرانی و غیره) برای هم جاوا و هم جاوا اسکریپت است.< /p>

Tyson: شما در هیئت مدیره فناوری JHipster هستید، که به عنوان یک اتحاد جاوا و جاوا اسکریپت به نظر می رسد همگرایی عالی از علایق شما باشد. آیا می‌توانید به من بگویید چگونه در آن پروژه شرکت کردید و چه چیزی در مورد آن هیجان‌انگیز است؟

Raible: در تابستان ۲۰۱۴ به طور تصادفی با آن برخورد کردم. من برای یک کلاینت کار می کردم که یک نمونه اولیه سریع از یک API و UI با Python با استفاده از چارچوبی که کارها را آسان می کرد ساخته بود (فراموش می کنم کدام یک). فکر کردم می‌توانم همین کار را در جاوا انجام دهم، JHipster را پیدا کردم و نمونه اولیه مشابهی را در کمتر از ۲۴ ساعت تحویل دادم. تحت تاثیرقرارگرفتم! و اولین برداشت ماندگار است.

من در آن مقطع در بیشتر دوران کاری خود یک مشاور مستقل بودم و می دانستم که بازاریابی مهم است. هر چند وقت یکبار برای سخنرانی در کنفرانس‌ها سفر می‌کردم، اما می‌دانستم که در نوشتن کتاب نیز قدرتی وجود دارد. بنابراین من با InfoQ درباره نوشتن JHipster Mini-Book صحبت کردم و آنها موافقت کرد که کمک کند.

در فرآیند نوشتن کتاب، و ایجاد برنامه نمونه برای آن، اشکالاتی پیدا کردم و مشکلاتی را وارد کردم. برخی از آنها را خودم توانستم حل کنم و PR ارائه کردم. پس از چندین ماه انجام این کار، از من دعوت شد تا به عنوان یک متعهد در پروژه باشم.

سپس به این فکر افتادم که به عنوان یک توسعه دهنده جاوا قدیمی لباس بپوشم تا یک سخنرانی JHipster را شروع کنم و با ادامه صحبت ها به تدریج به یک هیپستر جاوا تبدیل شوم. من این کار را ابتدا در Denver JUG در آوریل ۲۰۱۵ انجام دادم. بهترین عملکرد من از آن سخنرانی در Devoxx بلژیک در سال ۲۰۱۵ بود.

وقتی به Stormpath و بعداً Okta پیوستم، تصمیم گرفتم یکی از بهترین راه‌ها برای اینکه یک حامی توسعه‌دهنده مؤثر باشم، ادغام محصول شرکت در JHipster است. سپس می توانستم به نوشتن و صحبت در مورد JHipster ادامه دهم و همزمان محصول شرکت را به نمایش بگذارم. خیلی خوب کار شده است و اکنون Okta اسپانسر پلاتینیوم JHipster است! ما ۲۵۰۰ دلار در ماه کمک می کنیم.

تایسون: می‌دانید که داشتم به JHipster نگاه می‌کردم، پشتیبانی خارج از جعبه را دیدم و فکر کردم، “اوه خدا را شکر.” من به عنوان یک توسعه دهنده از اعتبار متنفرم، مثل اینجا که دوباره همین کار را تکرار می کنم…

آیا نمی‌خواهید درباره پشتیبانی تأیید اعتبار در JHipster و نحوه ادغام آن با Auth0/Okta با جزئیات صحبت کنید؟

Raible: وقتی برای اولین بار شروع به ادغام auth در JHipster کردم، از طریق ماژول Stormpath که ایجاد کردم بود. از آنجایی که Stormpath در آن زمان از یک تنظیمات تعبیه شده استفاده می کرد، ادغام بیشتر شامل اضافه کردن Stormpath SDK بود. می‌توانید اطلاعات بیشتری درباره آن اینجا بخوانید.

سپس، Okta Stormpath را در فوریه ۲۰۱۷ خریداری کرد. از آنجا که ما API Stormpath را در آگوست ۲۰۱۷ تعطیل کردیم، این ماژول دیگر مفید نبود. در سپتامبر ۲۰۱۷، من شروع به بازسازی اجرای OAuth JHipster کردم. می‌توانید در مورد بیشتر این تلاش‌ها در پست وبلاگ زیر بخوانید: استفاده پشتیبانی OpenID Connect با JHipster.

اجرای OAuth JHipster در آن زمان شامل استفاده از یک سرور مجوز از Spring Security و قرار دادن شناسه مشتری و راز در کد سمت مشتری بود. این یک حفره امنیتی بزرگ بود. در طول یک ماه، ما همه چیز را بازسازی کردیم تا در سمت سرور اتفاق بیفتد و هرگز توکن‌ها را روی مشتری ذخیره نکنیم. پنج سال بعد، هنوز فکر می کنم این تصمیم خوبی بود.

تایسون: من کمی در مورد ضربه زدن به Auth0 از زمینه Node.js اینجا صحبت می کنم. من احساس می‌کنم که راه درازی را طی کرده‌ایم تا امنیت را کم‌هزینه‌تر کنیم و برنامه‌نویس‌ها را دوست‌دارتر کنیم. به نظر شما روندها یا جهت هایی که فضا در آن حرکت می کند چیست؟

رابل: موافقم، اما فکر می‌کنم راه‌هایی برای رفتن داریم.

من دوست دارم امنیت را با آزمایش مقایسه کنم. اکثر توسعه دهندگان می دانند که باید آزمایش کنند و ابزارهای زیادی برای نشان دادن پوشش آزمایشی وجود دارد. اکثر IDE ها حتی از نمایش پوشش آزمایشی کلاس ها پشتیبانی می کنند. در فضای امنیتی به اندازه پلاگین های IDE چیز زیادی برای اشاره به مسائل امنیتی به توسعه دهندگان وجود ندارد. من فکر می کنم همه چیز در حال بهبود است. Snyk یک افزونه IntelliJ برای رفع آسیب‌پذیری‌ها دارد. می‌توانید بررسی‌های OWASP را با Maven و Dependabot GitHub بسیار نرم است.

یک مشکل بزرگ که من می بینم این است که توسعه دهندگان (یا مشتریان آنها) می خواهند SAML را به جای OIDC پیاده سازی کنند. برای نقل قول از دوستم جوئل فرانوسیک، “SAML برای OIDC است همانطور که SOAP برای استراحت.” من نمی دانم. بسیاری از افراد را می بینید که API های SOAP را پیاده سازی می کنند، پس چرا مردم هنوز SAML را پیاده سازی می کنند؟ من فکر نمی‌کنم این تقصیر توسعه‌دهندگان باشد، بلکه تصمیم گیرندگان اطلاعات نادرست دارند.

در رابطه با برنامه‌نویس دوستی، وقتی برای اولین بار Trish را در سال ۲۰۱۰ ملاقات کردم، او یک فروشنده در صنعت امنیت بود. . من با او در کانزاس سیتی به یک کنفرانس امنیت سایبری سفر کردم. او من را به تعدادی از دوستان infosec خود معرفی کرد. وقتی از آنها پرسیدند که چه کار کردم، گفتم: “من یک توسعه دهنده هستم.” یکی از اولین پاسخ‌ها این بود: «شرط می‌بندم می‌توانم چیزهای شما را هک کنم.» این برای من نگران کننده بود.

فکر کردم، “هی، ما تازه با هم آشنا شدیم و تو داری به من توهین می کنی؟!” از آن لحظه به بعد، من شروع به انجام مذاکرات بیشتر در زمینه امنیت کردم تا سعی کنم امنیت را برای توسعه دهندگان دوستانه تر کنم. من صحبت‌های مشابهی را در گذشته انجام داده‌ام و جاوا اسکریپت و فن‌آوری‌های وب را برای توسعه‌دهندگان جاوا توضیح داده‌ام تا سعی کنم به جای نادیده گرفتن آنها با استفاده از JSF [چهره‌های سرور جاوا]، از فناوری‌های وب استفاده کنند.

تایسون: بله. به نظر می‌رسد که اگر زمان زیادی را صرف هک کنید، می‌توانید موارد را بشکنید، و اگر این کار را نکنید، در برابر کسانی که این کار را می‌کنند آسیب‌پذیر هستید.

می‌توانم در مورد چیزهای Spring Native/JHipster که اخیراً منتشر شده‌اند بپرسم؟ غذای اصلی در آنجا چیست؟

Raible: نکته اصلی این است که اگر JHipster Native را ادغام کنید، برنامه JHipster + Spring Boot خود را به جای چند ثانیه در میلی ثانیه شروع می کنید.

ما طرح‌هایی برای Micronaut و Quarkus نیز داریم. آنها دارای پشتیبانی داخلی داخلی هستند، اما ما باید کاری انجام دهیم تا آنها را با JHipster کار کنیم.

نسخه‌هایی برای NestJS و .NET Core نیز وجود دارد، اما آنها هیچ نوع پشتیبانی بومی ندارند.

JHipster Native (و Spring Native) احتمالاً موقتی خواهد بود زیرا Spring Boot 3 به طور پیش‌فرض قصد دارد دارای بومی باشد. هنگامی که ما به آن ارتقاء دادیم (انتشار آن برای پایان سال ۲۰۲۲ برنامه ریزی شده است)، دیگر به JHipster Native نیازی نخواهیم داشت. البته، برنامه‌های موجود مبتنی بر Spring Boot 2.x همچنان به آن نیاز دارند.

تایسون: شما همچنین مقدار زیادی در مورد زیرساخت‌ها نوشته‌اید – میکروسرویس‌ها، Kubernetes و غیره. حس شما از اینکه کارها به کجا می‌روند چیست؟ آیا روند یا پیشرفت جالبی دارید؟

Raible: من پست Kelsey Hightower از سال ۲۰۲۰ درباره نحوه مونولیت ها آینده هستند. من فکر می‌کنم علاقه زیادی به میکروسرویس‌ها از سوی توسعه‌دهندگان وجود دارد، زیرا آن‌ها می‌خواهند درباره همه چیزهایی که میکروسرویس‌ها را تشکیل می‌دهند، رزومه خود را بسازند و از جدیدترین فناوری‌های «هیپ» استفاده کنند. با این حال، به نظر من، مواقع زیادی وجود دارد که یک مونولیت به خوبی کار می کند. زمانی که یکپارچه‌ها خراب می‌شوند، زمانی است که افراد زیادی روی آن کار می‌کنند و باید افراد را مقیاس‌بندی کنید و توانایی فشار دادن سریع کدها را بدون انتظار دیگران داشته باشید.

خدمات خرد اغلب توسط قانون کانوی مانع می‌شوند، زیرا سازمان شما باید این توانایی را داشته باشد. برای ایجاد تیم های محصولی که می توانند ایده هایی ارائه دهند، آنها را ارائه دهند و به طور مستقل از آنها نگهداری کنند. اگر سازمان شما این توانایی را دارد که بدون اتکا به دیگران این کار را انجام دهد، این احتمال وجود دارد که استفاده از میکروسرویس ها برای شما خوب باشد.

مقیاس‌سازی یک مونولیت معمولاً مشکلی نیست، بلکه مقیاس‌پذیری مردم است. زمانی که در سال ۲۰۰۷-۲۰۰۸ در لینکدین کار می کردم، آنها یکپارچه بودند و عملکرد خوبی داشتند. با این حال، آنها فقط پنج شنبه ها مستقر می شدند و این برای سرعت مشکل بود. آنها در نهایت ریزسرویس ها را به دلیل مشکل مقیاس افراد خود اتخاذ کردند، نه به دلیل مشکلات مقیاس فناوری.

من درک خوبی از اینکه کارها به کجا می‌روند ندارم، اما معتقدم Kubernetes به YAML سطح پایین زیادی نیاز دارد تا کارها را انجام دهد. نمی توانم فکر کنم راه بهتری برای پیکربندی چیزها وجود دارد. در حالت ایده آل، نوعی نحو وجود دارد که به اندازه کافی آسان برای حفظ کردن باشد. یا شاید در نهایت چیزی مانند JHipster وجود داشته باشد که بتواند تمام YAML را برای شما ایجاد کند.

تایسون: فوق العاده جالب است. آیا می‌خواهید توضیح دهید که چگونه مقیاس‌پذیری افراد یک گلوگاه است؟ معنای آن را کمی بیشتر توضیح دهید؟

Raible: این روزها همه شرکت‌ها شرکت‌های فناوری هستند و به احتمال زیاد توسعه‌دهنده دارند. هرچه شرکت بزرگ‌تر باشد، توسعه‌دهندگان بیشتری دارد یا به آنها برون سپاری می‌کند. اگر همه آنها روی یک پروژه کار می کنند (معروف به یکپارچه) و هزاران خط کد در ساعت متعهد می شوند، مطمئناً درگیری وجود دارد. هنگام انتشار به یک کابوس ادغام تبدیل می شود. با این حال، اگر هزاران توسعه‌دهنده دارید و تیم‌های کمتر از ۱۰ نفر هستند که روی صدها میکروسرویس کار می‌کنند، احتمال تضاد کمتری وجود دارد. همچنین، با میکروسرویس ها، باید بتوانید به طور مستقل مستقر شده و وابستگی بین تیم ها را به حداقل برسانید.

داستان خنده‌دار مرتبط: وقتی برای اولین بار شنیدم که جیمز فرماندار در مورد اینکه چگونه شرکت‌های وب بزرگ می‌شوند، به فروشگاه‌های جاوا تبدیل شوید. زمانی فکر می‌کردم این به این دلیل است که جاوا زبان بهتری بود و تایپ ثابت مقیاس‌پذیری را آسان‌تر می‌کرد. پس از شنیدن حضوری یکی از صحبت های جیمز، متوجه شدم که این بیشتر به این دلیل است که جاوا بزرگترین اکوسیستم توسعه دهندگان را دارد. وقتی می‌خواهید صدها توسعه‌دهنده را همزمان استخدام کنید تا کسب و کار خود را توسعه دهند، یکی از ساده‌ترین راه‌ها برای استخدام است.

تایسون: این چیز عالی است! خوب، یک سوال آخر برای جمع بندی. من کنجکاو هستم که به عنوان یک توسعه دهنده (مثل خودم) که به اندازه کافی در اطراف بوده ام تا کمی به چیزها نگاه کنم، در مورد زندگی برنامه نویسی نظری دارید.

Raible: چیزی جز افسانه نبود! زمانی که از Pine برای ایمیل استفاده کردیم و Lynx اولین مرورگر من بود، در DU [دانشگاه دنور] به مدرسه رفتم. مشاهده بصری شدن اینترنت با SlipKnot و سپس Netscape 1.0 باورنکردنی بود. من استفاده از Struts 1.0 را بلافاصله پس از انتشار شروع کردم، آن را دوست داشتم و به شدت در جامعه آن درگیر شدم. من با بسیاری از دوستان جدید و راه حل هایی برای مشکلاتی که با آن روبرو بودم پاداش دریافت کردم. سپس وبلاگ نویسی، AppFuse، Spring، کتاب من درباره بهار، صحبت کردن (الهام گرفته از بروس اسنایدر) آمد. ، رنسانس جاوا اسکریپت و بازگشت من به توسعه UI.

چیزی که در کل سواری بیشتر از همه لذت بردم دوستانی هستند که در طول مسیر در جامعه منبع باز پیدا کردم. وقتی به یک کنفرانس می‌روید و با کسی که تقریباً ۲۰ سال است می‌شناسید ملاقات یا هک می‌کنید، واقعاً خاص است. توانایی من برای کار از راه دور از سال ۲۰۰۲ نیز یک موهبت واقعی بوده است. من عاشق آزادی کار از هر جایی که اینترنت خوب است داشته باشم!

تایسون: متشکرم مت، آشنایی با شما عالی بود!

Raible: چت کردن با شما جالب بود!