import { json, type LoaderFunctionArgs } from "@remix-run/node";
import { authenticate } from "../shopify.server";
export const loader = async ({ request }: LoaderFunctionArgs) => {
const { admin, session, billing } = await authenticate.admin(request);
// Verifică planul de plată obligatoriu înainte de randare
const hasActivePayment = await billing.check({
plans: ["Basic Monthly Plan"],
isTest: process.env.NODE_ENV !== "production",
});
if (!hasActivePayment.hasActivePayment) {
await billing.require({
plans: ["Basic Monthly Plan"],
isTest: process.env.NODE_ENV !== "production",
onFailure: async () => billing.request({
plan: "Basic Monthly Plan",
isTest: process.env.NODE_ENV !== "production",
}),
});
}
const response = await admin.graphql(`
#graphql
query getShopDetails {
shop {
name
myshopifyDomain
}
}
`);
const { data } = await response.json();
return json({ shop: data.shop, shopDomain: session.shop });
};Dacă vrei să scoți o aplicație publică pe Shopify App Store în 2024, stack-ul Remix + Polaris recomandat de ei este de departe cea mai rapidă cale să nu primești reject la UI. Totuși, CLI-ul lor îți dă un boilerplate care arată bine pe localhost, dar are câteva capcane urâte când treci la producție.
Am lansat recent o aplicație de analytics care a ajuns la vreo 350 de merchants activi. Am trecut prin două runde de reject de la echipa de review Shopify până să fie aprobată. Vă las aici notițele mele ca să nu pierdeți două săptămâni pe aceleași greșeli.
Setup-ul de Remix și capcana bazei de date
Comanda npm create @shopify/app@latest îți generează un proiect Remix configurat cu @shopify/shopify-app-remix, Prisma și App Bridge v4. Problema e că vine default cu SQLite configurat local.
În secunda în care urci app-ul pe Fly.io, Railway sau un container pe ECS cu mai multe instanțe, sesiunile OAuth se rup dacă nu muți imediat session storage-ul pe PostgreSQL sau Redis. Prisma funcționează impecabil aici, dar trebuie să schimbi providerul în schema.prisma din prima zi. Altfel, când Shopify încearcă să verifice token-ul offline și dă de un nou container, merchantul e trimis într-o buclă infinită de login.
Polaris: de ce merită chiar dacă e rigid
Polaris are o grămadă de limitări dacă vrei un design ultra-custom. E greoi, componentele de layout (BlockStack, InlineGrid) cer ceva obișnuință, iar stilizarea custom peste Polaris CSS e o luptă continuă cu specificitatea.
Trade-off-ul? Reviewerii Shopify au un checklist vizual strict. Dacă folosești componente native Polaris, App Bridge TitleBar și loading states din platformă (s-page, s-button sau Polaris Spinner), bifezi automat 80% din cerințele de UX. Merchantul simte că app-ul tău e o extensie firească din Shopify Admin, nu un iFrame aruncat la întâmplare.
Unde pică majoritatea la review-ul Shopify
Review-ul manual durează cam 5-10 zile lucrătoare la prima trimitere. În experiența mea, cele mai dese motive de reject sunt:
- Webhook-urile obligatorii de GDPR:
customers/data_request,customers/redactșishop/redact. Dacă aceste endpoint-uri întorc 404 sau nu răspund cu status 200 în mai puțin de 2000ms, primești reject instant fără să se mai uite la restul aplicației. - Billing API & Free trial handling: Dacă app-ul tău e cu plată, flow-ul de billing trebuie să ruleze direct prin
billing.require()din Remix loader. Dacă lași utilizatorul să intre în dashboard fără plan selectat sau dacă UI-ul se blochează la redirect, e reject. - Lipsa stărilor goale (Empty States): Când un magazin nou instalează aplicația și nu are date, pagina nu are voie să fie albă sau să arunce erori de consolă. Trebuie să ai componenta
EmptyStatedin Polaris cu un call-to-action clar.
Polaris + Remix îți iau mult din munca de infrastructură OAuth și embed, dar trebuie să respecți regulile lor de ecosistem. Voi ce folosiți pentru app-uri embedded: template-ul oficial sau mergeți pe Node/Go separat cu frontend React?