انتخاب یک معماری صحیح برای پیاده سازی یک اپلیکیشن میتواند تاثیر بسیار زیادی روی فرایند توسعه و نگه داری نرم افزار شما باید. در این مقاله بررسی می کنیم که چه زمانی باید از اپلیکیشن های تک صفحه ای استفاده کنیم. و چ زمانی از معماری سنتی چند صفحه ای. به این منظور این مقاله به دو بخش تقسیم می شود.
- چه زمانی باید از اپلیکیشن های تک صفحه ای (SPA) استفاده کنیم.
- چه زمانی باید از اپلیکشن های چند صفحه ای استفاده کنیم.
چه زمانی باید یک معماری سنتی را انتخاب کنید؟
دلایلی که در ادامه مقاله ذکر شده اند به شما در جواب دادن به سوال بالا کمک می کنند. و مشخص می کنند ک شما چرا و چه وقت باید به سراغ معماری سنتی بروید.
وقتی اپلیکیشن شما ساده و قسمت کلاینت ساید آن خیلی نیاز به تغییرات ندارد
Many web applications are primarily consumed in a read-only fashion by the vast majority of their users. Read-only (or read-mostly) applications tend to be much simpler than those that maintain and manipulate a great deal of state. For example, a search engine might consist of a single entry point with a textbox and a second page for displaying search results. Anonymous users can easily make requests, and there is little need for client-side logic. Likewise, a blog or content management system’s public-facing application usually consists mainly of content with little client-side behavior. Such applications are easily built as traditional server-based web applications which perform logic on the web server and render HTML to be displayed in the browser. The fact that each unique page of the site has its own URL that can be bookmarked and indexed by search engines (by default, without having to add this as a separate feature of the application) is also a clear benefit in such scenarios.
When to choose SPAs
The following is a more detailed explanation of when to choose a Single Page Applications style of development for your web app.
Your application must expose a rich user interface with many features
SPAs can support rich client-side functionality that doesn’t require reloading the page as users take actions or navigate between areas of the app. SPAs can load more quickly, fetching data in the background, and individual user actions are more responsive since full page reloads are rare. SPAs can support incremental updates, saving partially completed forms or documents without the user having to click a button to submit a form. SPAs can support rich client-side behaviors, such as drag-and-drop, much more readily than traditional applications. SPAs can be designed to run in a disconnected mode, making updates to a client-side model that are eventually synchronized back to the server once a connection is re-established. You should choose a SPA style application if your app’s requirements include rich functionality that goes beyond what typical HTML forms offer. Note that frequently SPAs need to implement features that are built-in to traditional web apps, such as displaying a meaningful URL in the address bar reflecting the current operation (and allowing users to bookmark or deep link to this URL to return to it). SPAs also should allow users to use the browser’s back and forward buttons with results that won’t surprise them.
Your application must already expose an API for other (internal or public) clients
If you’re already supporting a web API for use by other clients, it may require less effort to create a SPA implementation that leverages these APIs rather than reproducing the logic in server-side form. SPAs make extensive use of web APIs to query and update data as users interact with the application.
Decision table – Traditional Web or SPA
The following decision table summarizes some of the basic factors to consider when choosing between a traditional web application and a SPA.