اقدامات سرور، پایگاه های داده و آینده مدیریت داده ها

در Xata ما بر روی بهبود نحوه مدیریت دادهها توسط برنامههای کاربردی مدرن متمرکز شدهایم. بنابراین طبیعتاً ما در مورد آینده React هیجان زده هستیم. در نتیجه افزایش سرعت همزمانی در React و درک گستردهتر اجزای سرور React، داستان واکشی دادهها از نظر بهبود پیشرفتهای چشمگیری داشته است.
به عنوان توسعه دهندگان، ما در حال تجربه یک تغییر هیجان انگیز در نحوه ادغام داده ها در برنامه هایمان هستیم. استفاده از الگوی «واکشی سپس رندر» در مؤلفههای ما، تجربه لذتبخشتری را برای توسعهدهندگان فراهم میکند و آوردن دادهها به یک برنامه را آسانتر میکند، و در نتیجه یک تجربه کلی روانتر ایجاد میکند.
توجه داشته باشید که ما از پایگاه داده مستقیماً از تابع رندر کامپوننت پرس و جو می کنیم. این شگفت انگیز است! علاوه بر آن، ما حتی میتوانیم اجزای خود را در یک مرز تعلیق قرار دهیم و اجازه دهیم دادهها در صورت لزوم جریان پیدا کنند.
export async function Movie({ slug }) {
const movie = await xata.db.movies.filter({ id: slug }).getFirst()
return (
<>
<header className="grid place-items-center">
<Image
className="rounded-br-2xl rounded-tl-2xl"
src={movie.poster}
width={600}
height={300}
alt={movie.title}
/>
<h1 className="text-6xl text-center py-8 ">{movie.title}</h1>
</header>
<article className="max-w-prose w-full mx-auto prose">
<p>{movie.overview} </p>
</article>
</>
)
}
قطعه کد بالا را در قالب XMDB ما بررسی کنید
// app/page.tsx
async function SERP() {
searchParams
}) => {
return (
<main>
<Suspense fallback={<Loader />}>
<SearchResult searchTerm={searchParams.search} />
</Suspense>
</main>
)
}
در حالی که داخل SearchResult
، می توانیم واکشی کنیم، منتظر بمانیم و رندر کنیم. علاوه بر این، ما حتی میتوانیم قول معلق را به عنوان یک تصویب کنیم prop
. داستان واکشی دادهها بسیار متنوع است و میتواند به جای نوشتن منطق در چارچوب قوانین خاص، انتزاعات و قراردادها، با منطق تجاری سازگار شود. ما منطق خود را می نویسیم و می توانیم آن را به بهترین شکل ممکن و بدون راه حل زیادی انجام دهیم.
اقدام بر روی سرور
می توان استدلال کرد که جدای از جزئیات انجام واکشی داده ها بر اساس هر جزء، داستان قبلاً به خوبی تعریف شده بود. ما قبلاً قابلیتهای مشابهی داشتیم (البته با ادغام کتابخانهها یا ابزارهای اضافی)، اما میتوانستیم به نتایج مشابهی برسیم. با این حال، قطعه گم شده، داشتن این قابلیت در چارچوب بود که داستان جهش را باز می کند. این جنبه بین پشته های مختلف فناوری بسیار متفاوت است و تصمیم مهمی را ایجاد می کند که تیم ها باید بگیرند، با فضای زیادی برای اشتباهات.
ریمیکس با استفاده از توابع اکشنی که امکان مکانیابی مشترک واکشی و ارسال دادهها با منطق رندر را فراهم میکند، بر اساس هر نمایش، با داستان جهش مقابله میکند. چارچوب به طرز ماهرانه ای اهداف کاربر را بر اساس روش HTTP تعیین می کند (معمولا GET
یا POST
، اما به طور کامل از دیگران نیز پشتیبانی می کند). تنها کاری که باید انجام دهیم این است که متد مناسب را در صفحه خود صادر کنیم و روش صحیح را در صفحه خود تنظیم کنیم <form>
عنصر
export const action = async ({ request }: ActionArgs) => {
const xata = getXataClient();
const { intent, id } = Object.fromEntries(await request.formData());
if (intent === "delete" && typeof id === "string") {
await xata.db.remix_with_xata_example.delete(id);
return json({
message: "delete: success",
data: null,
});
}
if (intent === "create") {
const newItem = await xata.db.remix_with_xata_example.create(LINKS);
return json({
message: "create: success",
data: newItem,
});
}
return json({
message: "no action performed",
data: null,
});
};
const Task: TaskComponent = ({ id, title, url, description }) => {
const fetcher = useFetcher();
return fetcher.submission ? null : (
<li key={url}>
<a href={url ?? ""} rel="noopener noreferrer" target="_blank">
{title}
</a>
<p>{description}</p>
<fetcher.Form method="post">
<input type="hidden" name="id" value={id} />
<button type="submit" name="intent" value="delete">
<span role="img" aria-label="delete item">
🗑
</span>
</button>
</fetcher.Form>
</li>
);
};
الگوی رسمی Xata را در این نمونه ریمیکس بررسی کنید.
React Server Components با معرفی سطح بالاتری از جزئیات، قدمی فراتر گذاشته است. Next.js از user server
دستورالعملی برای تعریف روشهای اقدام سرور در بدنه یک جزء. این امکان تعریف تقریباً هر منطق انحصاری سرور را فراهم می کند.
بنابراین اکنون، مؤلفه جستجو، که تعاملی مانند یک مؤلفه مشتری معمولی دارد، میتواند یک جستجوی پایگاه داده را وارد کند و از داخل بدنه خود شلیک کند.
'use client';
import { useTransition } from 'react';
import { addUser } from '~/db/actions';
function SaveSomeData() {
let [isPending, startTransition] = useTransition();
return (
<>
...
<button onClick={() => startTransition(() => addUser(data))}>
Save!
</button>
</>
);
}
اکشن ما آن داده را مستقیماً از پاسخ تماس رویداد دریافت میکند و به سرور ما فشار میدهد، دقیقاً مانند این:
'use server';
export async function addUser(data) {
const user = await xata.db.users.create(data)
return Boolean(user) ? 'great success' : 'oops'
}
چیزهای زیادی برای دور زدن وجود دارد و هنوز چیزهای زیادی تحت پرچم های آزمایشی هستند، اما آینده برای داستان های داده ما روشن به نظر می رسد. حتی این امکان وجود دارد که انتقال های خوش بینانه را در کامپوننت خود با a پیاده سازی کنید useOptimistic
قلاب.
پرس و جو در اجزای داخلی
البته این یک گلوله نقره ای نیست و در حالی که ما با آن جشن می گیریم ما میتوانیم، ما هنوز باید در مورد اینکه (و چه زمانی) باید از این استفاده کنیم یا نه، آگاه و آگاه باشیم. مانند خود سباستین مارکباگه گفت:
پرس و جوهای DB در مؤلفه ها/عملکردهای شما واقعاً به این معنا نیست که کل صنعت چگونه همه چیز را انجام می دهد، اما فکر می کنم فراموش کرده ایم که چقدر به نمونه سازی، موارد خاص موقت و بهینه سازی ها کمک می کند. ما نیاز به یادآوری داشتیم که گاهی اوقات این ابزار مناسبی است.
ما ابزار دیگری در اختیار داریم و این میتواند املاک ذهنی بیشتری را برای فکر کردن به تجربیات کاربر محور آزاد کند. پرس و جو از پایگاه داده از درون منطق مؤلفه شما به طور جادویی برنامه شما را به خودی خود بهتر یا سریعتر نمی کند، اما به شما این امکان را می دهد که در مورد زمانی که برای ایجاد ویژگی ها و ارزش برای کاربران خود صرف می کنید کارآمدتر، سازنده تر و عمدی تر باشید. و آیا تجربه توسعهدهنده این نیست؟ توانمندسازی توسعه دهندگان برای ایجاد ویژگی های بهتر با تسهیل راه حل ها!
راه حل های تمام پشته و سپس برخی
بنابراین اکنون که میتوانیم از داخل اجزای خود به سرورهای خود وارد و خارج شویم و میتوانیم مرز شبکه (خط بین سرور و کلاینت) را همانطور که مناسب ماست حرکت دهیم – زمان آن رسیده است که از این راهحلها برای رفع انسداد استفاده پیچیدهتر استفاده کنیم. موارد
همانطور که سوزن از رفع انسداد درخواست های کاربران دور می شود، در Xata بلافاصله به فکر تولید بیشتر توسعه دهندگان افتادیم. به همین دلیل است که آخرین راهاندازی ما در سراسر جهان بوده است گردش کار توسعه.
اگر پروژه ای به یک پایگاه داده متصل شود، پس از اینکه طرحواره منشعب شد، شاخه Xata را با شاخه GitHub، در صورتی که نام یکسانی داشته باشند، مطابقت می دهد، و بنابراین یک پیش نمایش Deployment ایجاد می کند که مستقیماً به آن مهاجرت متصل می شود. هنگامی که درخواست کشش شما ادغام شد، Xata به طور خودکار یک مهاجرت طرحواره را راه اندازی می کند (با زمان خاموشی صفر!) و مطمئن می شود که طرح شما با کد مطابقت دارد.
آینده ای هیجان انگیز
از آنجایی که داستان داده ما در جلو و در مرکز توسعه چارچوب مورد علاقه ما قرار می گیرد، می توانیم به آینده نگاه کنیم و ایده ها و ویژگی های جدید را طوفان فکری کنیم. دادههای خود را شاخهبندی کنید، اثبات مفاهیم سریع ایجاد کنید، همه چیز را آزمایش کنید، تکرار کنید، و همه چیز را در سطوحی از کارایی که قبلاً ممکن نبود، ادغام کنید.
آینده برای توسعه وب و بدون سرور هیجان انگیز است و ما کاملاً برای آن اینجا هستیم!
در مورد شما چطور؟ چه چیزی شما را بیشتر از همه این تغییرات آتی در چشم انداز پشته ما هیجان زده می کند؟ به ما اطلاع دهید توییتر، یا در Discord به ما بپیوندید!