overview of smithy an api descri

Smithy چیست؟

مروری بر Smithy، یک زبان توصیف API از آمازون (Overview of Smithy, an API Description Language From Amazon)

زبان‌های توصیف (Description Languages) روشی بسیار مؤثر و کارآمد برای تعریف چرخه توسعه هستند. این زبان‌ها می‌توانند امکان تکرارپذیری بیشتر، کنترل دقیق‌تر و درک عمیق‌تری از منطق و سیستم‌های زیربنایی ایجاد کنند. یکی از زبان‌های جدید این حوزه، Smithy است که طی زمان اخیر تعداد کاربران آن به‌طور مداوم در حال افزایش بوده است. این زبان توصیف رابط (IDL) که توسط آمازون پشتیبانی می‌شود، یک راه‌حل مدل‌محور، کارآمد و قابل حمل ارائه می‌دهد.

در ادامه به بررسی Smithy می‌پردازیم تا ببینیم چه ویژگی‌هایی آن را متمایز می‌کند. همچنین برخی مزایا و معایب استفاده از آن را بررسی می‌کنیم و نگاهی به نحوه عملکردش در عمل می‌اندازیم.

Smithy چیست؟

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

تیم آمازون Smithy را توسعه داد تا یک سیستم مدل‌سازی مجهز به تولید کد ارائه کند که بسیاری از مشکلات IDLهای مشابه را حل می‌کند. تولید کد معمولاً به پروتکل یا فریم‌ورک خاص وابسته بوده و این وابستگی مانع بزرگی در بسیاری از محیط‌ها محسوب می‌شد. هدف Smithy ایجاد یک راه‌حل بدون وابستگی به پروتکل بود که بتواند در محیط‌های مختلف به خوبی کار کند.

Smithy چگونه کار می‌کند؟

Smithy با ایجاد مدل‌ها عمل می‌کند. این مدل‌ها بلوک‌های اصلی هستند که همه‌چیز بر اساس آن‌ها ساخته می‌شود. ساختار کلی Smithy بر پایه منابع (resources) و عملیات (operations) است؛ مفهومی که برای اکثر توسعه‌دهندگان آشناست.

smithy 1

قابلیت گسترش و سفارشی‌سازی بیشتر از طریق شکل‌ها (shapes) و ویژگی‌ها (traits) در مدل معنایی فراهم می‌شود. Traits می‌توانند عناصر موجود در یک shape را تعریف یا محدود کنند و امکان ساخت مدل‌های دقیق‌تر و قابل کنترل‌تر را فراهم کنند.

ترکیب مدل مبتنی بر منابع و تکامل traits باعث می‌شود Smithy قابلیت تغییر و توسعه بسیار زیادی داشته باشد. Smithy همچنین یک سیستم اعتبارسنجی قدرتمند ارائه می‌دهد تا اطمینان دهد تغییرات مدل همچنان در چارچوب قوانین کلی باقی می‌مانند.

smithy 2

یک ویژگی مهم دیگر، امکان تقسیم‌بندی مدل است؛ بخش‌های مختلف مدل می‌توانند تحت مالکیت تیم‌های متفاوت باشند و این موضوع همکاری را ساده‌تر می‌کند. سیستم Projection نیز امکان ساخت نسخه‌های مختلف از مدل برای مخاطبان گوناگون بدون تغییر مدل اصلی را فراهم می‌کند—مثلاً ساخت نسخه‌ای مخصوص استفاده B2B.

در نهایت، Smithy روی ایجاد یک مدل واحد تمرکز دارد که می‌توان آن را در هر محیطی توسعه داد و گسترش داد—هدف بزرگی که به خوبی با حرکت به سمت میکروسرویس‌ها هماهنگ است. IDL در سه بخش تعریف شده است:

  • Control: نسخه IDL و کنترل‌های فرآیند تولید را مشخص می‌کند.

  • Metadata: متادیتاهای مورد استفاده برای توصیف مدل را تعیین می‌کند.

  • Shapes: ساختارها و traits مدل را تعریف می‌کند.

Smithy در عمل

نمونهٔ زیر از مستندات رسمی ارائه شده و یک سرویس آب‌وهوا را مدل می‌کند:

(کد بدون هیچ تغییر و بدون ترجمه)

$version: "۲"

namespace example.weather

/// Provides weather forecasts.
@paginated(inputToken: “nextToken”, outputToken: “nextToken”, pageSize: “pageSize”)
service Weather {
version: “۲۰۰۶-۰۳-۰۱”
resources: [
City
]
operations: [
GetCurrentTime
]
}

resource City {
identifiers: { cityId: CityId }
properties: { coordinates: CityCoordinates }
read: GetCity
list: ListCities
resources: [
Forecast
]
}

resource Forecast {
identifiers: { cityId: CityId }
properties: { chanceOfRain: Float }
read: GetForecast
}

//”pattern” is a trait.
@pattern(“^[A-Za-z0-9 ]+$”)
string CityId

@readonly
operation GetCity {
input := for City {
//”cityId” provides the identifier for the resource and
// has to be marked as required.
@required
$cityId
}

output := for City {
//”required” is used on output to indicate if the service
// will always provide a value for the member.
//”notProperty” indicates that top-level input member “name”
// is not bound to any resource property.
@required
@notProperty
name: String

@required
$coordinates
}

errors: [
NoSuchResource
]
}

// This structure is nested within GetCityOutput.
structure CityCoordinates {
@required
latitude: Float

@required
longitude: Float
}

//”error” is a trait that is used to specialize
// a structure as an error.
@error(“client”)
structure NoSuchResource {
@required
resourceType: String
}

// The paginated trait indicates that the operation may
// return truncated results.
@readonly
@paginated(items: “items”)
operation ListCities {
input := {
nextToken: String
pageSize: Integer
}

output := {
nextToken: String

@required
items: CitySummaries
}
}

// CitySummaries is a list of CitySummary structures.
list CitySummaries {
member: CitySummary
}

// CitySummary contains a reference to a City.
@references([
{
resource: City
}
])

structure CitySummary {
@required
cityId: CityId

@required
name: String
}

@readonly
operation GetCurrentTime {
output := {
@required
time: Timestamp
}
}

@readonly
operation GetForecast {
input := for Forecast {
//”cityId” provides the only identifier for the resource since
// a Forecast doesn’t have its own.
@required
$cityId
}

output := for Forecast {
$chanceOfRain
}
}

همان‌طور که دیده می‌شود، ابتدا بخش کنترل در بالای کد قرار دارد:

$version: "۲"

و سپس بخش اصلی مدل شامل namespace، سرویس‌ها، منابع و عملیات می‌آید.
تعاریف traits، ساختارها و توابع کمک می‌کنند داده‌ها و رفتار خدمات بدون تغییر در ساختار اصلی مدل کنترل شوند.

مزایا و معایب Smithy

مزایا

  • مهم‌ترین مزیت، عدم وابستگی به پروتکل است.

  • مدل‌محور بودن باعث افزایش خوانایی و قابلیت حمل میان سیستم‌ها می‌شود.

  • مدل‌ها را می‌توان به فرمت‌های دیگر تبدیل کرد و مقایسه آن‌ها ساده است.

  • امکان اتوماسیون و افزایش بهره‌وری.

  • متن‌باز بودن سبب توسعه سریع‌تر و مستقل‌تر می‌شود.

  • قابلیت همکاری تیمی و ساخت projectionهای مختلف.

معایب

  • تولید کد همچنان مانند همیشه چالش‌هایی دارد.

  • Smithy بسیار کامل و چندلایه است؛ برای پروژه‌های کوچک ممکن است بیش‌ازحد سنگین باشد.

  • وابستگی بلندمدت آن به سلامت پروژه‌های آمازون یک ریسک بالقوه است.

  • خطر تبدیل پروژه‌های متن‌باز به مدل‌های تجاری—مثالی مانند Redis یا Linkerd.

جمع‌بندی

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

دیتابیس‌های کراس‌پلتفرم API چه تفاوت‌هایی با هم دارند؟
چرا پرتال‌های توسعه‌دهنده (Developer Portals) باید منحصربه‌فرد باشند تا دیده شوند؟

دیدگاهتان را بنویسید

سبد خرید
علاقه‌مندی‌ها
مشاهدات اخیر
دسته بندی ها