எனவே இது RAML அல்லது OAS (Swagger)?

மைக்ரோ சர்வீஸின் மாறும் உலகில், எதையும் மாற்றலாம்-எந்த ஒரு கூறுகளையும் வெவ்வேறு கட்டமைப்புகள் மற்றும் கட்டமைப்பைப் பயன்படுத்தி வேறு மொழியில் மீண்டும் எழுதலாம். உள் உருமாற்றங்களைப் பொருட்படுத்தாமல், மைக்ரோ சர்வீஸ் சில நிரந்தர அடிப்படையில் வெளியில் இருந்து தொடர்பு கொள்ளக்கூடிய வகையில் ஒப்பந்தங்கள் மட்டும் மாறாமல் இருக்க வேண்டும். ஒப்பந்தங்களை விவரிப்பதற்கான வடிவமைப்பைத் தேர்ந்தெடுப்பதில் உள்ள எங்கள் சிக்கலைப் பற்றி இன்று பேசுவோம் மற்றும் நாங்கள் கண்டறிந்த கலைப்பொருட்களைப் பகிர்ந்துகொள்வோம்.

போஸ்ட் தயார் அன்னா மெலெகோவா и விளாடிமிர் லாபடின்

நுண் சேவைகள். அக்ரோனிஸ் சைபர் கிளவுட்டை உருவாக்கும் போது, ​​அவர்களிடமிருந்து தப்பிக்க முடியாது என்பதை உணர்ந்தோம். மைக்ரோ சர்வீஸின் இடைமுகத்தைக் குறிக்கும் ஒப்பந்தத்தை முறைப்படுத்தாமல் மைக்ரோ சர்வீஸை வடிவமைப்பது சாத்தியமற்றது.

ஆனால் ஒரு தயாரிப்பு ஒன்றுக்கு மேற்பட்ட கூறுகளைக் கொண்டிருக்கும்போது, ​​ஒப்பந்த மேம்பாடு வழக்கமான செயலாக மாறும் போது, ​​செயல்முறை மேம்படுத்தல் பற்றி சிந்திக்கத் தொடங்குவதைத் தவிர்க்க முடியாது. இடைமுகம் (ஒப்பந்தம்) மற்றும் செயல்படுத்தல் (மைக்ரோ சர்வீஸ்) ஒன்றுடன் ஒன்று பொருந்த வேண்டும், வெவ்வேறு கூறுகள் ஒரே மாதிரியான விஷயங்களைச் செய்ய வேண்டும், மேலும் இந்த முடிவுகள் அனைத்தையும் மையப்படுத்திய முடிவெடுக்காமல், ஒவ்வொரு அணியும் கட்டாயப்படுத்தப்படும் என்பது தெளிவாகிறது. அவற்றைப் பெற மீண்டும் மீண்டும் நேரத்தைச் செலவிடுங்கள்.

Amazon microservices வரைபடம் இருந்து ட்வீட் வெர்னர் வோஜெலிஸ், CTO அமேசான்
இக்கட்டான நிலை என்ன? உண்மையில், மைக்ரோ சர்வீஸ்களை தொடர்பு கொள்ள இரண்டு வழிகள் உள்ளன - Google வழங்கும் HTTP Rest மற்றும் gRPC. கூகுளின் தொழில்நுட்ப அடுக்கில் சிக்கிக்கொள்ள விரும்பாமல், HTTP Restஐத் தேர்ந்தெடுத்தோம். HTTP REST ஒப்பந்தக் குறிப்புகள் பெரும்பாலும் இரண்டு வடிவங்களில் ஒன்றில் விவரிக்கப்படுகின்றன: RAML மற்றும் OAS, முன்பு Swagger என அறியப்பட்டது. எனவே, ஒவ்வொரு மேம்பாட்டுக் குழுவும் தரநிலைகளில் ஒன்றைத் தேர்ந்தெடுக்க வேண்டிய அவசியத்தை எதிர்கொள்கிறது. ஆனால் அது மாறிவிடும், இந்த தேர்வு செய்வது மிகவும் கடினமாக இருக்கும்.

குறிப்புகள் ஏன் தேவை?

சிறுகுறிப்பு தேவைப்படுகிறது, இதன் மூலம் வெளிப்புறப் பயனர் தனது HTTP இடைமுகத்தின் மூலம் உங்கள் சேவையில் என்ன செய்யலாம் என்பதை எளிதாகக் கண்டறிய முடியும். அதாவது, ஒரு அடிப்படை மட்டத்தில், சிறுகுறிப்பில் கிடைக்கக்கூடிய ஆதாரங்களின் பட்டியல், அவற்றின் HTTP முறைகள், கோரிக்கை உடல்கள், அளவுருக்களின் பட்டியல், தேவையான மற்றும் ஆதரிக்கப்படும் தலைப்புகளின் அறிகுறி, அத்துடன் திரும்பக் குறியீடுகள் மற்றும் மறுமொழி வடிவங்கள் ஆகியவை இருக்க வேண்டும். ஒப்பந்த சிறுகுறிப்பின் மிக முக்கியமான அம்சம் அவற்றின் வாய்மொழி விளக்கம் ("கோரிக்கையுடன் இந்த வினவல் அளவுருவைச் சேர்த்தால் என்ன நடக்கும்?", "எந்தச் சந்தர்ப்பத்தில் குறியீடு 400 திரும்பப் பெறப்படும்?")

இருப்பினும், அதிக எண்ணிக்கையிலான மைக்ரோ சர்வீஸ்களை உருவாக்கும் போது, ​​எழுதப்பட்ட சிறுகுறிப்புகளிலிருந்து கூடுதல் மதிப்பைப் பிரித்தெடுக்க வேண்டும். எடுத்துக்காட்டாக, RAML/Swagger அடிப்படையில், நீங்கள் கிளையன்ட் மற்றும் சர்வர் குறியீடு இரண்டையும் ஏராளமான நிரலாக்க மொழிகளில் உருவாக்கலாம். மைக்ரோ சர்வீஸிற்கான ஆவணங்களை நீங்கள் தானாகவே பெறலாம் மற்றும் அதை உங்கள் டெவலப்பர்-போர்ட்டலில் பதிவேற்றலாம் :).

கட்டமைக்கப்பட்ட ஒப்பந்த விளக்கத்தின் எடுத்துக்காட்டு

ஒப்பந்த விளக்கங்களின் அடிப்படையில் மைக்ரோ சர்வீஸ்களை சோதிக்கும் நடைமுறை குறைவாகவே உள்ளது. நீங்கள் ஒரு சிறுகுறிப்பு மற்றும் ஒரு கூறு இரண்டையும் எழுதியிருந்தால், பல்வேறு வகையான உள்ளீட்டு தரவுகளுடன் சேவையின் போதுமான தன்மையை சரிபார்க்கும் தானியங்கு சோதனையை நீங்கள் உருவாக்கலாம். சிறுகுறிப்பில் விவரிக்கப்படாத மறுமொழிக் குறியீட்டை சேவை வழங்குகிறதா? இது வெளிப்படையாகத் தவறான தரவைச் சரியாகச் செயலாக்க முடியுமா?

மேலும், ஒப்பந்தங்களை மட்டுமல்ல, சிறுகுறிப்புகளைக் காட்சிப்படுத்துவதற்கான கருவிகளையும் உயர்தர செயல்படுத்தல் மைக்ரோ சர்வீஸ் மூலம் வேலையை எளிதாக்குகிறது. அதாவது, கட்டிடக் கலைஞர் ஒப்பந்தத்தை தரமான முறையில் விவரித்திருந்தால், அதன் அடிப்படையில், வடிவமைப்பாளர்கள் மற்றும் டெவலப்பர்கள் கூடுதல் நேர செலவுகள் இல்லாமல் பிற தயாரிப்புகளில் சேவையை செயல்படுத்துவார்கள்.

கூடுதல் கருவிகளை இயக்க, RAML மற்றும் OAS ஆகிய இரண்டும் தரநிலையால் வழங்கப்படாத மெட்டாடேட்டாவைச் சேர்க்கும் திறனைக் கொண்டுள்ளன (எடுத்துக்காட்டாக, OAS இல் இது இவ்வாறு செய்யப்படுகிறது).

பொதுவாக, மைக்ரோ சர்வீஸுக்கான ஒப்பந்தங்களைப் பயன்படுத்துவதில் படைப்பாற்றலுக்கான நோக்கம் மிகப்பெரியது... குறைந்தபட்சம் கோட்பாட்டில்.

முள்ளம்பன்றியை பாம்புடன் ஒப்பிடுதல்

தற்போது, ​​அக்ரோனிஸ் சைபர் பிளாட்ஃபார்ம் மேம்பாடுதான் அக்ரோனிஸில் உள்ள முன்னுரிமை மேம்பாட்டுப் பகுதி. அக்ரோனிஸ் சைபர் பிளாட்ஃபார்ம் என்பது அக்ரோனிஸ் சைபர் கிளவுட் மற்றும் ஏஜென்ட் பகுதியுடன் மூன்றாம் தரப்பு சேவைகளை ஒருங்கிணைப்பதற்கான புதிய புள்ளிகள் ஆகும். RAML இல் விவரிக்கப்பட்டுள்ள எங்கள் அக API களில் நாங்கள் மகிழ்ச்சியாக இருந்தபோதிலும், API ஐ வெளியிட வேண்டியதன் அவசியத்தை மீண்டும் தேர்வு செய்யும் கேள்வியை எழுப்பியது: எங்கள் பணிக்கு எந்த சிறுகுறிப்பு தரத்தைப் பயன்படுத்துவது சிறந்தது?

ஆரம்பத்தில், இரண்டு தீர்வுகள் இருப்பதாகத் தோன்றியது - மிகவும் பொதுவான முன்னேற்றங்கள் RAML மற்றும் Swagger (அல்லது OAS). ஆனால் உண்மையில் குறைந்தது 2 மாற்று வழிகள் இல்லை, ஆனால் 3 அல்லது அதற்கு மேற்பட்டவை உள்ளன.

ஒருபுறம் RAML உள்ளது - ஒரு சக்திவாய்ந்த மற்றும் திறமையான மொழி. இது படிநிலை மற்றும் பரம்பரை நன்கு செயல்படுத்துகிறது, எனவே இந்த வடிவம் நிறைய விளக்கங்கள் தேவைப்படும் பெரிய நிறுவனங்களுக்கு மிகவும் பொருத்தமானது - அதாவது ஒரு தயாரிப்பு அல்ல, ஆனால் ஒப்பந்தங்களின் பொதுவான பகுதிகளைக் கொண்ட பல மைக்ரோ சர்வீஸ்கள் - அங்கீகார திட்டங்கள், அதே தரவு வகைகள், பிழை அமைப்புகள் .

ஆனால் RAML இன் டெவலப்பர், முல்சாஃப்ட், ஓபன் ஏபிஐ கூட்டமைப்பில் சேர்ந்துள்ளார், இது உருவாகி வருகிறது. ஸ்வாகர். எனவே, RAML அதன் வளர்ச்சியை நிறுத்தியது. நிகழ்வின் வடிவமைப்பை கற்பனை செய்ய, முக்கிய லினக்ஸ் கூறுகளை பராமரிப்பவர்கள் மைக்ரோசாஃப்ட் நிறுவனத்தில் வேலை செய்ய விட்டுவிட்டார்கள் என்று கற்பனை செய்து பாருங்கள். இந்த சூழ்நிலையானது ஸ்வாக்கரைப் பயன்படுத்துவதற்கான முன்நிபந்தனைகளை உருவாக்குகிறது, இது மாறும் மற்றும் சமீபத்திய - மூன்றாவது பதிப்பில் - நெகிழ்வுத்தன்மை மற்றும் செயல்பாட்டின் அடிப்படையில் நடைமுறையில் RAML ஐப் பிடிக்கிறது.

ஒன்று இல்லை என்றால்...

அது மாறிவிடும், அனைத்து திறந்த மூல பயன்பாடுகளும் OAS 3.0 க்கு புதுப்பிக்கப்படவில்லை. Go இல் மைக்ரோ சர்வீஸுக்கு, மிகவும் முக்கியமான விஷயம் தழுவல் இல்லாதது செல்ல-அடக்கம் தரநிலையின் சமீபத்திய பதிப்பிற்கு. இருப்பினும், Swagger 2 மற்றும் Swagger 3 இடையே உள்ள வேறுபாடு மிகப்பெரிய. எடுத்துக்காட்டாக, மூன்றாவது பதிப்பில் டெவலப்பர்கள்:

• அங்கீகார திட்டங்களின் மேம்படுத்தப்பட்ட விளக்கம்
• முடிந்தது JSON ஸ்கீமா ஆதரவு
• எடுத்துக்காட்டுகளைச் சேர்க்கும் திறனை மேம்படுத்தியது

நிலைமை வேடிக்கையானது: ஒரு தரநிலையைத் தேர்ந்தெடுக்கும்போது, ​​நீங்கள் RAML, Swagger 2 மற்றும் Swagger 3 ஆகியவற்றை தனித்தனி மாற்றாகக் கருத வேண்டும். இருப்பினும், OpenSource கருவிகளுக்கு ஸ்வாகர் 2 மட்டுமே நல்ல ஆதரவைக் கொண்டுள்ளது. RAML மிகவும் நெகிழ்வானது... மற்றும் சிக்கலானது, மற்றும் ஸ்வாக்கர் 3 சமூகத்தால் மோசமாக ஆதரிக்கப்படுகிறது, எனவே நீங்கள் தனியுரிம கருவிகள் அல்லது வணிக தீர்வுகளைப் பயன்படுத்த வேண்டும், அவை மிகவும் விலை உயர்ந்ததாக இருக்கும்.

மேலும், ஸ்வாக்கரில் ரெடிமேட் போர்டல் போன்ற பல நல்ல அம்சங்கள் இருந்தால் editor.swagger.io, நீங்கள் ஒரு சிறுகுறிப்பை பதிவேற்றி அதன் காட்சிப்படுத்தலை விரிவான விளக்கம், இணைப்புகள் மற்றும் இணைப்புகளுடன் பெறலாம், பின்னர் மிகவும் அடிப்படையான மற்றும் குறைவான நட்பு RAML க்கு அத்தகைய வாய்ப்பு இல்லை. ஆம், நீங்கள் GitHub இல் உள்ள திட்டங்களில் ஏதாவது ஒன்றைத் தேடலாம், அங்கு ஒரு அனலாக் கண்டுபிடித்து அதை நீங்களே வரிசைப்படுத்தலாம். இருப்பினும், எந்தவொரு சந்தர்ப்பத்திலும், யாராவது போர்ட்டலைப் பராமரிக்க வேண்டும், இது அடிப்படை பயன்பாடு அல்லது சோதனைத் தேவைகளுக்கு மிகவும் வசதியாக இல்லை. கூடுதலாக, ஸ்வாக்கர் மிகவும் "கொள்கையற்றது" அல்லது அதிக தாராளமயமானது - இது குறியீட்டில் உள்ள கருத்துகளிலிருந்து உருவாக்கப்படலாம், இது நிச்சயமாக API முதல் கொள்கைக்கு எதிரானது மற்றும் எந்த RAML பயன்பாடுகளாலும் ஆதரிக்கப்படாது.

ஒரு காலத்தில் நாங்கள் RAML உடன் மிகவும் நெகிழ்வான மொழியாக வேலை செய்யத் தொடங்கினோம், இதன் விளைவாக நாமே நிறைய விஷயங்களைச் செய்ய வேண்டியிருந்தது. எடுத்துக்காட்டாக, திட்டங்களில் ஒன்று பயன்பாட்டைப் பயன்படுத்துகிறது சிதைவுகள் யூனிட் சோதனைகளில், இது RAML 0.8 ஐ மட்டுமே ஆதரிக்கிறது. எனவே நாங்கள் ஊன்றுகோல்களைச் சேர்க்க வேண்டியிருந்தது, இதனால் பயன்பாடு RAML பதிப்பு 1.0 ஐ "சாப்பிட" முடியும்.

நீங்கள் தேர்வு செய்ய வேண்டுமா?

RAML க்கான தீர்வுகளின் சுற்றுச்சூழலை முடிப்பதில் பணிபுரிந்த பிறகு, RAML ஐ Swagger 2 ஆக மாற்ற வேண்டும் மற்றும் அதில் அனைத்து ஆட்டோமேஷன், சரிபார்ப்பு, சோதனை மற்றும் அடுத்தடுத்த தேர்வுமுறைகளை மேற்கொள்ள வேண்டும் என்ற முடிவுக்கு வந்தோம். RAML இன் நெகிழ்வுத்தன்மை மற்றும் ஸ்வாக்கரின் சமூக கருவி ஆதரவு ஆகிய இரண்டையும் பயன்படுத்த இது ஒரு சிறந்த வழியாகும்.

இந்தச் சிக்கலைத் தீர்க்க, ஒப்பந்த மாற்றத்தை வழங்கும் இரண்டு OpenSource கருவிகள் உள்ளன:

1. oas-raml-converter தற்போது ஆதரிக்கப்படாத பயன்பாடாகும். அதனுடன் பணிபுரியும் போது, ​​அதிக எண்ணிக்கையிலான கோப்புகளில் "பரவப்பட்ட" சிக்கலான RAMLகளில் பல சிக்கல்கள் இருப்பதைக் கண்டறிந்தோம். இந்த நிரல் ஜாவாஸ்கிரிப்ட்டில் எழுதப்பட்டுள்ளது மற்றும் தொடரியல் மரத்தின் சுழல்நிலை பயணத்தை செய்கிறது. டைனமிக் டைப்பிங் காரணமாக, இந்த குறியீட்டைப் புரிந்துகொள்வது கடினமாகிறது, எனவே இறக்கும் பயன்பாட்டிற்காக பேட்ச்களை எழுதி நேரத்தை வீணாக்க வேண்டாம் என்று முடிவு செய்தோம்.
2. வெபாபி-பாகுபடுத்தி - எதையும் மற்றும் எல்லாவற்றையும், எந்த திசையிலும் மாற்றத் தயாராக இருப்பதாகக் கூறும் அதே நிறுவனத்தின் ஒரு கருவி. இன்றுவரை, RAML 0.8, RAML 1.0 மற்றும் Swagger 2.0 ஆகியவற்றுக்கான ஆதரவு அறிவிக்கப்பட்டுள்ளது. இருப்பினும், எங்கள் ஆராய்ச்சியின் போது, ​​பயன்பாடு இன்னும் இருந்தது மிகவும் ஈரமான மற்றும் பயன்படுத்த முடியாத. டெவலப்பர்கள் ஒரு வகையை உருவாக்குகிறார்கள் IR, எதிர்காலத்தில் புதிய தரங்களை விரைவாகச் சேர்க்க அவர்களை அனுமதிக்கிறது. ஆனால் இதுவரை அது செயல்படவில்லை.

இது நாம் சந்தித்த கஷ்டங்கள் எல்லாம் இல்லை. எங்கள் பைப்லைனில் உள்ள படிகளில் ஒன்று, விவரக்குறிப்புடன் ஒப்பிடும்போது களஞ்சியத்திலிருந்து RAML சரியானதா என்பதைச் சரிபார்க்க வேண்டும். நாங்கள் பல பயன்பாடுகளை முயற்சித்தோம். ஆச்சரியம் என்னவென்றால், அவர்கள் அனைவரும் வெவ்வேறு இடங்களில் மற்றும் முற்றிலும் மாறுபட்ட கெட்ட வார்த்தைகளால் எங்கள் சிறுகுறிப்புகளை சத்தியம் செய்தனர். மற்றும் எப்போதும் புள்ளி இல்லை :).

இறுதியில், நாங்கள் இப்போது காலாவதியான திட்டத்தில் குடியேறினோம், அதில் பல சிக்கல்கள் உள்ளன (சில நேரங்களில் அது நீல நிறத்தில் செயலிழக்கிறது, வழக்கமான வெளிப்பாடுகளுடன் பணிபுரியும் போது சிக்கல்கள் உள்ளன). எனவே, இலவச கருவிகளின் அடிப்படையில் சரிபார்ப்பு மற்றும் மாற்றத்தின் சிக்கல்களைத் தீர்ப்பதற்கான வழியை நாங்கள் கண்டுபிடிக்கவில்லை, மேலும் வணிக பயன்பாட்டைப் பயன்படுத்த முடிவு செய்தோம். எதிர்காலத்தில், OpenSource கருவிகள் மிகவும் முதிர்ச்சியடையும் போது, ​​​​இந்தச் சிக்கலை எளிதாக தீர்க்கலாம். இதற்கிடையில், வணிகச் சேவையின் விலையை விட "முடிப்பதற்கு" உழைப்பு மற்றும் நேரச் செலவுகள் எங்களுக்கு மிகவும் முக்கியத்துவம் வாய்ந்ததாகத் தோன்றியது.

முடிவுக்கு

இவை அனைத்திற்கும் பிறகு, நாங்கள் எங்கள் அனுபவத்தைப் பகிர்ந்து கொள்ள விரும்புகிறோம் மற்றும் ஒப்பந்தங்களை விவரிப்பதற்கான ஒரு கருவியைத் தேர்ந்தெடுப்பதற்கு முன், அதில் இருந்து நீங்கள் என்ன விரும்புகிறீர்கள் மற்றும் எந்த பட்ஜெட்டில் முதலீடு செய்யத் தயாராக இருக்கிறீர்கள் என்பதை நீங்கள் தெளிவாக வரையறுக்க வேண்டும். OpenSource பற்றி நாங்கள் மறந்துவிட்டால், சரிபார்க்க, மாற்ற மற்றும் சரிபார்க்க உதவும் ஏராளமான சேவைகள் மற்றும் தயாரிப்புகள் ஏற்கனவே உள்ளன. ஆனால் அவை விலை உயர்ந்தவை, சில சமயங்களில் மிகவும் விலை உயர்ந்தவை. ஒரு பெரிய நிறுவனத்திற்கு, இத்தகைய செலவுகள் தாங்கக்கூடியவை, ஆனால் ஒரு தொடக்கத்திற்கு அவை பெரிய சுமையாக மாறும்.

நீங்கள் பின்னர் பயன்படுத்தும் கருவிகளின் தொகுப்பைத் தீர்மானிக்கவும். எடுத்துக்காட்டாக, நீங்கள் ஒரு ஒப்பந்தத்தைக் காட்ட வேண்டும் என்றால், அழகான API ஐக் கொண்ட Swagger 2 ஐப் பயன்படுத்துவது எளிதாக இருக்கும், ஏனெனில் RAML இல் நீங்கள் சேவையை உருவாக்கி பராமரிக்க வேண்டும்.
உங்களிடம் அதிகமான பணிகள் இருந்தால், கருவிகளின் தேவை அதிகமாக இருக்கும், மேலும் அவை வெவ்வேறு தளங்களுக்கு வேறுபட்டவை, மேலும் எதிர்காலத்தில் உங்கள் செலவுகளைக் குறைக்கும் ஒரு தேர்வு செய்ய, கிடைக்கக்கூடிய பதிப்புகளை உடனடியாகப் பற்றி அறிந்து கொள்வது நல்லது.

ஆனால் இன்று இருக்கும் அனைத்து சுற்றுச்சூழல் அமைப்புகளும் அபூரணமானவை என்பதை அங்கீகரிப்பது மதிப்பு. எனவே, நிறுவனத்தில் RAML இல் பணிபுரிய விரும்பும் ரசிகர்கள் இருந்தால், "இது உங்களை மிகவும் நெகிழ்வாக எண்ணங்களை வெளிப்படுத்த அனுமதிக்கிறது" அல்லது மாறாக, ஸ்வாக்கரை விரும்புகிறது, ஏனெனில் "இது தெளிவாக உள்ளது", அவர்களை வேலை செய்ய விடுவது நல்லது. எந்த வடிவங்களின் கருவிகளும் ஒரு கோப்புடன் மாற்றியமைக்கப்பட வேண்டியிருப்பதால், அவை என்னவாக இருக்கின்றனவோ அதற்குப் பழகிவிட்டன, அதை விரும்புகின்றன.

எங்கள் அனுபவத்தைப் பொறுத்தவரை, பின்வரும் இடுகைகளில், எங்கள் RAML-Swagger கட்டமைப்பின் அடிப்படையில் என்ன நிலையான மற்றும் மாறும் சரிபார்ப்புகளை நடத்துகிறோம், அத்துடன் ஒப்பந்தங்களிலிருந்து என்ன ஆவணங்களை உருவாக்குகிறோம், அது எவ்வாறு செயல்படுகிறது என்பதைப் பற்றி பேசுவோம்.

பதிவு செய்த பயனர்கள் மட்டுமே கணக்கெடுப்பில் பங்கேற்க முடியும். உள்நுழையவும், தயவு செய்து.

மைக்ரோ சர்வீஸ் ஒப்பந்தங்களை விளக்குவதற்கு நீங்கள் எந்த மொழியைப் பயன்படுத்துகிறீர்கள்?

• RAML 0.8

• RAML 1.0

• ஸ்வாக்கர் 2

• OAS3 (aka)

• புளூபிரிண்ட்

• மற்ற

• பயன்படுத்துவதில்லை

100 பயனர்கள் வாக்களித்தனர். 24 பயனர்கள் வாக்களிக்கவில்லை.

ஆதாரம்: www.habr.com