Axnify
Izstrādātājiem

Ecommerce platforma, pret kuru nav jācīnās

Beidz skrūvēt workaround-us pie melnās kastes SaaS. Axnify izvada katru primitīvu caur REST, sūta webhook-us katram notikumam un ļauj rediģēt tēmas kodu tieši. Go backend-ā, Next.js frontend-ā, atvērti API visur.

Kāpēc lielākā daļa ecommerce SaaS platformu ir naidīgas pret izstrādātājiem

Izvēlies jebkuru no top 10 commerce SaaS platformām un apskati to API dokumentāciju. Tad apskati to admin UI. Funkcionalitāte nesaskan. Admin var darīt lietas, ko API nevar. Sliktāk, platformas piegādātājs to zina — un uzskata to par feature, nevis bug. Spēju aizslēgšana aiz admin ir tas, kas tevi tur uz to platformas. Brīdī, kad vari visu izdarīt caur API, vari arī aiziet.

Tā ir fundamentālā spriedze. Lielās SaaS platformas (Shopify, BigCommerce, Wix Commerce) optimizē ne-tehniskiem tirgotājiem, jo viņi veido lielāko daļu TAM. Kad izstrādātāji prasa webhook konkrētam notikumam, veidu, kā reģistrēt pielāgotu checkout soli, vai rakstīšanas piekļuvi iepriekš read-only resursam, atbilde parasti ir „jauniniet uz enterprise tier“ vai „izmantojiet Zapier“.

Axnify ir uzbūvēta savādāk, jo tās backend ir tam strukturēts. Katra domēna ir mikropakalpojums (product, order, cart, theme, billing, asset, customer, payment, shipping utt.) ar savu datubāzes shēmu un savu HTTP API. Admin UI ir frontend, kas runā ar šiem API — tieši tāpat kā tavs kods. Nav admin-only spēju. Nav „iekšēja endpoint-a“, ko nevarētu izsaukt. API virsma IR platforma.

Šim dizaina lēmumam ir sekas. Tas nozīmē, ka Axnify ir godīgāka par to, ko tā atbalsta un ko ne: ja tā nav API, tā neeksistē. Tas nozīmē, ka breaking change-i tiek pieķerti ātrāk — nevar nosūtīt admin feature, nesūtot arī API. Un tas nozīmē, ka tu kā izstrādātājs, kas integrējas pret platformu, nekad neesi pozīcijā, kur jāraksta screen-scraper, jo admin var kaut ko, ko tavs kods nevar.

Kāpēc izstrādātāji pamet lielās SaaS platformas

Read-only API, kas nesaskan ar admin UI

Var listēt produktus, bet nevar atjaunot krājumus; var lasīt pasūtījumus, bet nevar piepildīt fulfillmentu no sava ERP. Katrs workaround pārvēršas par Zapier cilpu, manuālu CSV eksportu vai screen-scraperu, kas saplīst brīdī, kad platforma pārveido savu admin.

Tēmas kods aizslēgts aiz enterprise tier-iem

Shopify aizslēdz Liquid + JS tēmas rediģēšanu aiz £2 300/mēn Plus plāna. Vēlies pieskarties HTML uz £29 plāna? Izmanto viņu drag-and-drop, kā visi citi. Wix neatklāj tēmas kodu nevienā tier-ā. BigCommerce sēž vidū, bet iekasē per-instance par tēmas koda labojumiem.

Webhook-i palaiž garām notikumus, kas tev patiesi vajadzīgi

Vispārējās platformas izsūta ~15 webhook tipus. Notikums, ko vēlies — checkout solis pabeigts, atstāts grozs notīrīts, tēma publicēta, custom field atjaunots, lietotnes tiesība mainīta — parasti nav viens no tiem. Beidzas ar polling-u, kas nozīmē rate-limit galvassāpes un novecojušus datus.

Headless maksā papildus un viegli saplīst

„Headless commerce“ vairumā platformu nozīmē atsevišķu enterprise SKU (Shopify Hydrogen, BigCommerce Stencil), citu API virsmu nekā tā, ko izmanto standarta admin, un nulles dokumentācijas paritāti ar admin UI. Bieži vien headless API ir mēnešus atpalicis no admin funkciju pārklājumā.

Ko izstrādātāji iegūst ar Axnify

REST API katrai primitīvai

Produkti, varianti, krājumi, klienti, pasūtījumi, grozi, tēmas, lapas, sadaļas, iestatījumi, webhook-i, lietotnes, faili, nodokļi — viss CRUD, viss dokumentēts, viss aiz viena Bearer tokena. Lapošana, filtrēšana un kārtošana ievēro konsekventas konvencijas katrā endpoint-ā.

Webhook-i katram notikumam, katrā plānā

Pasūtījums izveidots, samaksāts, izpildīts, atmaksāts; grozs izveidots / atstāts / atgūts; produkts / variants / krājums atjaunots; tēma publicēta; darbinieks uzaicināts; lietotne instalēta. Webhook piegāde ar atkārtošanām (10 mēģinājumi 48 stundu laikā), HMAC paraksti un piegādes žurnāls admin-ā.

Iebūvēts tēmas koda redaktors

Rediģē tēmas failus (HTML / CSS / JS) tieši admin tēmas redaktorā. Versiju vēsture katrai saglabāšanai. Priekšskatījums pirms publicēšanas. Side-by-side diff pret pēdējo publicēto versiju. Rollback ar vienu klikšķi, ja deploy kaut ko salauž.

Headless-draudzīgs pēc noklusējuma

Katrs storefront endpoint, kas apkalpo oficiālo commerce-ui, atgriež JSON caur publisko API. Izmanto Next.js, SvelteKit, Astro vai savu pielāgoto frontend, kas norāda uz api.axnify.com. Tas pats API darbina mūsu noklusējuma storefront — nav otrās klases headless API virsmas.

Pielāgoto lietotņu marketplace

Izveido lietotni, ievietot to marketplace-ā, paņem 80% revenue share. OAuth-flow reģistrācija, scoped tiesības, iegultas UI paneles tirgotāja admin-ā, webhook abonementi per lietotnes instalāciju, dedicēti app dashboard-i lietošanas analītikai.

Multi-tenant no pirmās dienas

Uzbūvēts kā multi-tenant SaaS, nevis single-store instalācija ar piesietu tenant_id. Tenant izolācija iet caur PostgreSQL row-level security policy-ām, per-tenant object-storage bucket-iem, per-tenant Redis namespace-iem un per-request tenant atrisinājumu kopīgajā middleware.

Go backend, mūsdienīgs stack

pgx, sqlc, Gin. PostgreSQL glabāšanai, Redis kešošanai, S3-saderīgs object-storage asset-iem, Traefik routing-am. Nav PHP, nav Rails monolīta, vispār nav monolīta — vairāk nekā 20 mikropakalpojumi, katrs neatkarīgi deploy-jams, katrs ar savām migrācijām un testiem.

Stabils, versionēts publiskais API

Katra primitīva izvadīta caur REST adresē api.axnify.com — produkti, varianti, krājumi, pasūtījumi, grozi, tēmas, klienti, webhook-i. Dokumentēts, versionēts un tā ir tā pati virsma, ko izsauc oficiālais admin un storefronts. Nav internal-only endpoint-u, nav otrās klases headless tier-a.

Ar ko Axnify arhitektūra atšķiras no monolītām commerce platformām

Klasiskā ecommerce platformas arhitektūra — Shopify, Magento, WooCommerce — ir vienots monolīts codebase, kas darbojas pret vienu datubāzi. Tas padara platformu ātri uzbūvējamu sākumā un viegli saprotamu maziem veikaliem. Tas nozīmē arī, ka katra funkcija dala to pašu runtime, to pašu datubāzes savienojumu pulu un to pašu release ciklu. Kad platformas komanda nosūta jaunu funkciju, katrs tirgotājs to saņem (vai bug-u, kas ar to nāca) tajā pašā dienā.

Axnify izvēlas pretēju pieeju. Katra commerce domēna dzīvo savā Go mikropakalpojumā. product pakalpojums pieder produkti, varianti, opcijas un krājumi. order pakalpojums pieder pasūtījumi, line items un fulfillments. cart pakalpojums pieder aktīvie grozi. asset pakalpojums pieder failu glabāšana. theme pakalpojums pieder tēmas, lapas, sadaļas un bloki. Kopā ir vairāk nekā 20 šādu pakalpojumu, katrs ar savu PostgreSQL shēmu, savu migrāciju direktoriju, saviem testiem, katrs neatkarīgi deploy-jams.

Pakalpojumi sazinās caur HTTP, izmantojot internal-key autentifikāciju service-to-service izsaukumiem un JWT/X-Tenant-ID gala lietotāja izcelsmes izsaukumiem. Kopīgās rūpes (auth, tenant atrisinājums, rate limiting, logging, metrics, error tracking) dzīvo kopīgā middleware paketē, ko importē katrs pakalpojums. PostgreSQL ir kopīga, bet shēmas ir izolētas; pakalpojums var JOIN pret cita tabulām caur views, bet rakstīšanas iet caur īpašnieka pakalpojuma API.

Tev kā izstrādātājam, kas integrējas pret platformu, šai arhitektūrai ir praktiskas sekas. API ir stabili per-pakalpojums: product API attīstās savā tempā, order API savā. Webhook-i nāk no pakalpojuma, kam pieder notikums, ar bagātīgiem metadatiem par to, kurš pakalpojums ko izsūtīja. Veiktspēja ir ierobežota per-domēns: lēna atskaites query analytics pakalpojumā nevar bloķēt tavu order-create izsaukumu. Un debug ir vieglāks, jo katrs request nes request ID, kas tiek logots katrā pakalpojumā, kuru tas skar.

Ko izstrādātāji būvē uz Axnify

Pielāgoti checkout flow-i

Pilnībā izlaid noklusējuma checkout. Vadi pielāgotu React/Vue checkoutu no cart un payment API-iem, vēl arvien izmantojot Axnify krājumiem, nodokļiem un fulfillment-am lejpus straumes. Cart API dod tev pilnu kontroli pār to, kas notiek katrā solī.

ERP / OMS integrācijas

Divvirzienu sync ar NetSuite, SAP B1, Dynamics 365. Webhook-driven inkrementāli atjauninājumi push jaunus pasūtījumus uz tavu ERP reālajā laikā; bulk REST endpoint-i apstrādā nakts sajeglas. Idempotency atslēgas katrā rakstīšanā, lai retry-i būtu droši.

Iekšējie tirgotāja rīki

Uzbūvē admin paneles, ko tava CS komanda patiesi vēlas lietot. Izmanto staff API tokenus ar scoped tiesībām; tirgotāja admin un tavi pielāgotie rīki eksistē kopā. Read-only views var piešķirt atbalstam, kam nevajadzētu būt pilnai admin piekļuvei.

Multi-frontend deployment-i

Tas pats produktu katalogs, vairāki storefront-i (web, mobilā lietotne, in-store kiosks, balss asistents). Katrs patērē to pašu API; Axnify ir patiesības avots. Cache invalidation notikumi izšaujas, kad produkts mainās, lai katrs frontend varētu re-fetch.

Bieži uzdotie jautājumi no izstrādātājiem

Vai ir GraphQL API?

Šodien tikai REST. Mēs nosvērām GraphQL arhitektūras laikā un izvēlējāmies REST cacheability (HTTP semantika, CDN-friendly), vienkāršāku klientu bibliotēku un vieglāka debug dēļ. Ja GraphQL ir stingra prasība tavai komandai, Saleor vai Vendure ir labākas izvēles šodien.

Kādi ir API rate limit-i?

1 000 req/min uz API tokenu Starter, 10 000 Pro, neierobežoti (tikai fair-use) Business+. Bulk endpoint-i (piem., produktu imports) ir atbrīvoti no per-minute cap un rate-limit-ēti pēc kopējiem baitiem stundā vietā. Rate-limit headers (`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`) tiek atgriezti katrā atbildē.

Vai Axnify ir open source vai self-hostable?

Nē — Axnify ir pilnībā managed SaaS. Mēs darbinām un uzturam platformu, lai tu varētu koncentrēties uz sava veikala un savu integrāciju veidošanu. Katra spēja ir izvadīta caur publisko REST API un webhook-iem adresē api.axnify.com, tāpēc tev nav vajadzīga servera piekļuve, lai to paplašinātu vai integrētu.

Kā tiek apmaksāti lietotņu abonementi?

Klients abonē caur tirgotāja admin → Stripe pārvalda billing → Axnify ņem 20% platformas maksu → 80% tiek izmaksāts uz tavu pieslēgto Stripe kontu nedēļas. Atmaksas un chargeback-i plūst atpakaļ pa to pašu ceļu. Lietotņu izstrādātāji redz savus ienākumus dedicētā dashboard-ā ar izmaksu vēsturi.

Kā es autentificēju pret API?

Izveido Personal Access Token admin sadaļā Developers → API tokens. Padod to kā `Authorization: Bearer <token>` katrā pieprasījumā. Tokeni nes scoped tiesības (read-only, read-write, admin), beidzas pēc tava izvēlētā grafika un var tikt nekavējoties atsaukti no tā paša ekrāna.

Kādā valodā / framework-ā tēmas ir rakstītas?

Tēmas ir JSON-definēti bloku koki, ko renderē kopīgs TypeScript renderer (commerce-ui). Noklusējuma bloku bibliotēka aptver ~40 widget tipus; vari piegādāt pielāgotus widget-us, rakstot React komponenti un reģistrējot to caur lietotni. Tēmas kods ir rediģējams per-tirgotājs admin tēmas redaktorā.

Vai varat man palīdzēt pārvietot manus datus no citas platformas?

Noteikti. Raksti uz support@axnify.com ar eksporta failu no tavas pašreizējās platformas — mēs pieņemam Shopify, WooCommerce, Etsy, Squarespace, Big Cartel, Gumroad, Sellfy un vairākumu citu izplatītu formātu. Mūsu komanda vada tavu produktu, variantu, klientu un pasūtījumu migrāciju end-to-end, bez maksas standarta importiem.

Beidz cīnīties ar savu ecommerce platformu

Reģistrējies bez maksas, saņem API tokenu 60 sekundēs, sāc integrēt.