n8n, NocoDB, Appsmith და Retool ერთ კვირაში: სად მთავრდება low-code და იწყება საკუთარი კოდი

ერთ კვირაში ოთხი კონსტრუქტორის რელიზი გამოვიდა, რომლებსაც მცირე კომპანიები იყენებენ, და პლატფორმების ორი შედარება. თუ ზედიზედ წაიკითხავთ, ერთი და იგივე ჩანს: ცხრილი „რა არის ხელმისაწვდომი უფასო ვერსიაში“, ფუნქცია, რომელიც გამორთეს, და წვდომის უფლებები, რომელთა აპლიკაციიდან მონაცემებში გადატანაც გახდა საჭირო. მფლობელისთვის ეს პასუხია კითხვაზე, სად წყვეტს კონსტრუქტორი იაფობას და როდის დგება საკუთარი კოდის შეკვეთის დრო.

რა გამოვიდა კვირაში

n8n-მა 23 ოქტომბერს პატჩი 2.45.3 გამოუშვა ერთი შესწორებით: ტექსტის კონტრასტი რედაქტორის ღია თემაში. პატჩები ხშირად გამოდის, და ვინც n8n-ს საკუთარ სერვერზე ინახავს, მისთვის განახლება რეგულარულ მოვალეობად იქცევა.

რამდენიმე დღით ადრე, 20 ოქტომბერს, n8n-მა ახსნა, რატომ შეცვალა ლოგო, შრიფტი და ფერები 14 ოქტომბრის კონფერენციაზე In The Loop. ტექსტში ჩემთვის ორი სტრიქონია მნიშვნელოვანი: Community Edition რჩება, მოდელის არჩევანი რჩება. დანარჩენი ბრენდზეა.

კიდევ უფრო ადრე, 16 ოქტომბერს, n8n-მა გამოაქვეყნა დიდი კომპანიებისთვის ავტომატიზაციის 12 პლატფორმის შედარება. იქ კრიტერიუმებია სასარგებლო: სად ინახება მონაცემები, არის თუ არა SSO, RBAC და აუდიტის ჟურნალი, რა შეუძლიათ აგენტებს და როგორ ითვლება ფასი, მომხმარებელზე თუ ამოცანაზე. საკუთარ თავზე n8n წერს: კოდი წასაკითხად ხელმისაწვდომია, საკუთარ სერვერზე დაყენება შეიძლება, 1000-ზე მეტი ინტეგრაციაა, და Code node იმ შემთხვევებისთვის, რომლებიც არ არის დაფარული. დანარჩენებს მოკლედ და n8n-ის სასარგებლოდ აღწერენ.

NocoDB-მ 23 ოქტომბერს 2026.10.0 გამოუშვა. ადამიანების დატვირთვის აღრიცხვა Timeline View-ში, სადაც ზეგანაკვეთური სამუშაო წითლად ინიშნება, მხოლოდ ფასიან გეგმებშია. ყველა ვერსიაში, Community-ის ჩათვლით, შეიძლება workflow-ის წინა გაშვების ნაბიჯ-ნაბიჯ გამეორება. ავტომატიზაციის ღილაკით გაშვება ღრუბელში უფასოა, Community-ში კი არ არის. რელიზში ხელმისაწვდომობის ცხრილი პატიოსანია, და ის პირველ რიგში ღირს წასაკითხად.

Appsmith-მა 21 ოქტომბერს 2.5.1 გამოუშვა, და მთავარი იქ შეხსენებაა: ჩაშენებული Appsmith AI 2026 წლის 30 სექტემბერს დაიხურა, მისკენ ძველმა მოთხოვნებმა მუშაობა შეწყვიტა ვერსიის მიუხედავად, და საჭიროა გადასვლა OpenAI-სთან, Anthropic-თან ან Google-თან პირდაპირ მიერთებაზე.

Workato-მ 20 ოქტომბერს გამოაქვეყნა Boomi-სთან შედარება GigaOm-ის 27 სექტემბრის ანგარიშის მიხედვით: 29 ტესტი, ჯამი 1363 1058-ის წინააღმდეგ, მათგან ექვსი ტესტი აგენტებსა და MCP-ზეა, 370 220-ის წინააღმდეგ. ანგარიში თავად Workato-მ შეუკვეთა, და ეს ტექსტში წერია. Boomi წინაა შეცდომების დამუშავებასა და მომხმარებლების მართვაში.

Retool-მა 22 ოქტომბერს წარადგინა Data Access Enforcement: ცხრილებზე, სვეტებსა და სტრიქონებზე უფლებები ერთხელ ეწერება მონაცემთა წყაროზე და ყველა აპლიკაციაზე, workflow-სა და აგენტზე ვრცელდება. ნაგულისხმევად ყველასთვის დახურულია, ადმინების ჩათვლით, ხოლო მოთხოვნა მომხმარებლის იდენტობის გარეშე იბლოკება. საჯარო ბეტა მხოლოდ Enterprise-ისთვის და მხოლოდ Postgres-ისთვისაა. ეს მნიშვნელოვანი ზღვარია: როცა უფლებების აპლიკაციებიდან მონაცემებში გადატანა გახდა საჭირო, კონსტრუქტორი აღარ არის „დავხატე და მუშაობს“.

მაგალითი: სერვისული კომპანია კონსტრუქტორზე

ავიღოთ სერვისული კომპანია. საიტიდან განაცხადები n8n-ით ცხრილში ხვდება, ცხრილი Appsmith-შია ნაჩვენები, მენეჯერები იქიდან მუშაობენ. ნახევარი წელი ყველაფერი კარგადაა. შემდეგ ბუღალტერმა ფასდაკლების სვეტი არ უნდა დაინახოს, ქვეკონტრაქტორმა კი მხოლოდ თავისი განაცხადები უნდა დაინახოს. მფლობელი ითხოვს: „უბრალოდ დამალეთ სვეტი“. ინტერფეისში დამალვა შეიძლება, მაგრამ ცხრილის API-ით სვეტი მაინც ჩანს. შემდეგ ან უფლებები ყოველ აპლიკაციაში თავიდან, ან ის, რაც Retool-მა გააკეთა: წესები მონაცემების დონეზე.

კონსტრუქტორის ზღვარი იქ გადის, სადაც მონაცემების წესები ეკრანის გარეთ უნდა სრულდებოდეს. რაც უფრო ადრე შეამჩნევთ ამას, მით უფრო იაფია გადასვლა.

ჩემი ზღვარი: 2015, 2017 და AppSheet

2015 წელს მარკეტინგული სააგენტო გავხსენი და მისთვის CRM-სა და ავტომატიზაციებს no-code-ზე ვაწყობდი. პროგრამირება 2017-ში დავიწყე, როცა ჩემს კომპანიებს ისეთი სისტემები დასჭირდა, რომლებიც მზა სახით არ არსებობდა. კონსტრუქტორებს არ ვაკრიტიკებ: ჩემი გზა მათით დაიწყო.

აშშ-ში PDR-ის სფეროს კომპანიაში იგივე ზღვარი ჩემს თვალწინ გაივლო. 2021 წელს მონაცემები Google Sheets-ში ინახებოდა, რომლებზეც მეორე დეველოპერი AppSheet-ში აპლიკაციებს აწყობდა, და ცხრილები პროცესებს ანელებდა. 2023 წელს შევთავაზე SQL-ბაზაზე გადასვლა სიჩქარისა და მონაცემების ერთიანი ფორმატისთვის, იდეას მხარი დაუჭირეს, და MariaDB-ზე გადასვლის შემდეგ ახალ სერვისებს ერთმანეთის მიყოლებით ვაერთებდით. ახლა React Native-ზე სუპერ-აპლიკაცია, რომელსაც კომპანიის დეველოპერებთან ერთად ვაკეთებთ, AppSheet-ს ცვლის: მას უკვე იყენებენ ოფისი, გამყიდველები და მფლობელი. AppSheet ამასთან დარჩა: მეორე დეველოპერი მას უძღვება და მასში ბევრი აპლიკაცია გააკეთა.

2021-დან 2025 წლამდე Upwork-ით Google Sheets-ის გარშემო ამოცანები მომდიოდა. წესი იქაც იგივეა: სკრიპტი ცხრილში კარგია, სანამ პროცესი Google Sheets-ში ცხოვრობს და მისი ცალკე სისტემაში გადატანა ადრეა. როცა მონაცემების მოცულობა, მომხმარებლების რაოდენობა ან უფლებების მოთხოვნები იზრდება, ბაზაზე საუბრის დროა.

რას გავაკეთებდი

კონსტრუქტორის არჩევამდე წავიკითხავდი რელიზის ხელმისაწვდომობის ცხრილს და წლის განმავლობაში მოხსნილი ფუნქციების სიას. Appsmith-ის ჩაშენებულმა AI-მ დიდხანს არ იცოცხლა.

შევამოწმებდი, სად სრულდება უფლებები: ეკრანში თუ მონაცემებში. თუ ეკრანში, დავითვლიდი, რამდენი ეკრანის შესწორება მოგიწევთ პირველივე ცვლილებისას.

ლოგიკას, რომელიც კომპანიისთვის ღირებულია, საკუთარ სერვერზე შევინახავდი. საწარმოო კომპანიისთვის მთელი გაანგარიშება Node.js-ზე გადავიტანე, რომ პროგრამის კოპირება ინტერფეისთან ერთად შეუძლებელი ყოფილიყო.

როდის აღარ ყოფნის ცხრილები, აღვწერე სტატიაში როდის სჭირდება ბიზნესს სისტემა ცხრილების ნაცვლად. ადრე ვწერდი, სად იწყება მზა კონექტორთან თქვენი პროცესის ლოგიკა და როდის სჭირდება შიდა სისტემა ჩატებში მართვის ნაცვლად. იმავე თემაზე: Gemini Google Sheets-ში და უნარებისა და MCP-ის კატალოგები. მიმართულებები: პროცესის ავტომატიზაცია და ბიზნესი როგორც ერთიანი სისტემა. ქეისები: ტექნიკური პარტნიორობა PDR-კომპანიასთან და Google Sheets და Apps Script Upwork-ზე. თუ თქვენი კონსტრუქტორი უფლებებს ან მოცულობას მიებჯინა, მომიყევით, რა არის მასში ახლა აწყობილი. ამოცანის განხილვა.