단일 페이지 응용 프로그램 : 장단점

단일 페이지 응용 프로그램 : 장단점

---

SPA에 대해 읽었으며 이점이 있습니다. 나는 대부분 설득력이 없습니다. 내 의심을 불러 일으키는 3 가지 장점이 있습니다.

질문 : SPA를 옹호하는 사람으로서 처음 세 가지 진술에 대해 내가 틀렸다는 것을 증명할 수 있습니까?

                              === ADVANTAGES ===

1. SPA는 반응이 빠른 사이트에 매우 적합합니다.

서버 측 렌더링은 모든 중간 상태에 대해 구현하기 어렵습니다. 작은보기 상태는 URL에 잘 매핑되지 않습니다.

단일 페이지 앱은 HTML을 검색하기 위해 서버 왕복을 요구하지 않고 UI의 일부를 다시 그릴 수있는 기능으로 구별됩니다. 이는 데이터를 처리하는 모델 계층과 모델에서 읽은 뷰 계층을 가짐으로써 데이터 표시에서 데이터를 분리함으로써 달성됩니다.

비 SPA 용 모델 계층을 보유하는 데 어떤 문제가 있습니까? SPA가 클라이언트 측에서 MVC와 호환되는 유일한 아키텍처입니까?

2. SPA를 사용하면 서버에 추가 쿼리를 사용하여 페이지를 다운로드 할 필요가 없습니다.

아, 그리고 사이트를 방문하는 동안 얼마나 많은 페이지를 사용자가 다운로드 할 수 있습니까? 둘, 셋? 대신 다른 보안 문제가 발생하므로 로그인 페이지, 관리자 페이지 등을 별도의 페이지로 분리해야합니다. 차례로 SPA 아키텍처와 충돌합니다.

3. 다른 장점이 있습니까? 다른 소식은 듣지 마십시오 ..

                            === DISADVANTAGES ===

1. 클라이언트는 자바 스크립트를 활성화해야합니다.
2. 사이트에는 하나의 진입 점이 있습니다.
3. 보안.

추신 : 나는 SPA 및 비 SPA 프로젝트에서 일했습니다. 이해를 깊게해야하기 때문에 그런 질문을합니다. SPA 지지자들에게 해를 끼치려는 의도는 없습니다. SPA에 대해 조금 더 읽어달라고 부탁하지 마십시오. 나는 그것에 대해 당신의 고려 사항을 듣고 싶습니다.

---

가장 인기있는 SPA 사이트 중 하나 인 GMail을 살펴 보겠습니다.

1. SPA는 반응이 빠른 사이트에 매우 적합합니다.

서버 측 렌더링은 URL에 #hash를 유지하는 것과 같은 간단한 기술이나보다 최근에는 HTML5pushState 와 같은 단순한 기술로는 어렵지 않습니다 . 이 방법을 사용하면 웹 앱의 정확한 상태가 페이지 URL에 포함됩니다. Gmail에서와 마찬가지로 메일을 열 때마다 특수 해시 태그가 URL에 추가됩니다. 다른 브라우저 창에 복사하여 붙여 넣은 경우 정확히 동일한 메일을 열 수 있습니다 (인증 할 수있는 경우). 이 접근 방식은보다 전통적인 쿼리 문자열에 직접 매핑되며 차이점은 단지 실행에 있습니다. HTML5 pushState ()를 #hash사용하면 첫 번째 요청에서 서버에서 확인한 다음 후속 요청에서 ajax를 통해로드 할 수있는 완전히 클래식 한 URL을 제거 하고 사용할 수 있습니다.

2. SPA를 사용하면 서버에 추가 쿼리를 사용하여 페이지를 다운로드 할 필요가 없습니다.

내 웹 사이트를 방문하는 동안 사용자가 다운로드 한 페이지 수 ?? 메일 계정을 열 때 읽은 메일 수 한 번에> 50을 읽습니다. 이제 메일의 구조는 거의 동일합니다. 서버 측 렌더링 체계를 사용하는 경우 서버는 모든 요청 (일반적인 경우)에이를 렌더링합니다. -보안 문제-사이트 구조에 전적으로 의존하는 관리자 / 로그인을위한 별도의 페이지를 유지해서는 안됩니다. paytm.com을 가져 가십시오. 예를 들어 웹 사이트 SPA를 만드는 것도 모든 엔드 포인트를 여는 것을 의미하지는 않습니다. 사용자는 스파 웹 사이트에서 인증 양식을 사용한다는 의미입니다. -아마도 가장 많이 사용되는 SPA 프레임 워크 Angular JS에서 개발자는 웹 사이트에서 전체 HTML 템플을로드 할 수 있으므로 사용자 인증 수준에 따라 수행 할 수 있습니다. 모든 인증 유형에 대해 HTML을 사전로드하는 것은 SPA가 아닙니다.

3. 다른 장점이 있습니까? 다른 소식은 듣지 마십시오 ..

• 요즘에는 클라이언트가 자바 스크립트를 사용할 수있는 브라우저를 가지고 있다고 가정 할 수 있습니다.
• 사이트의 단 하나의 진입 점. 앞에서 언급 한 상태 유지 관리가 가능하므로 원하는 수의 진입 점을 가질 수 있지만 확실하게 입력 점을 확보해야합니다.
• SPA 사용자조차도 자신에게 적절한 권한이있는 내용 만 볼 수 있습니다. 한 번에 모든 것을 주입 할 필요는 없습니다. diff html 템플릿 및 javascript 비동기를로드하는 것도 SPA의 유효한 부분입니다.

내가 생각할 수있는 장점은 다음과 같습니다.

1. html을 렌더링하면 분명히 사이트를 방문하는 모든 사용자 가이 작업을 수행하는 데 약간의 리소스가 필요합니다. 또한 주요 로직 렌더링은 이제 서버 측이 아닌 클라이언트 측에서 수행됩니다.
2. 날짜 시간 문제-클라이언트에게 UTC 시간을 미리 설정 한 형식으로 지정하고 자바 스크립트가 처리하도록 시간대를 신경 쓰지 않아도됩니다. 이것은 사용자 IP에서 파생 된 위치를 기준으로 시간대를 추측 해야하는 위치에 큰 이점입니다.
3. 나에게 상태는 변수를 설정하면 변수가있을 것이므로 SPA에서 더 잘 유지됩니다. 이것은 웹 페이지가 아닌 앱을 개발하는 느낌을줍니다. 이것은 일반적으로 foodpanda, flipkart, amazon과 같은 사이트를 만드는 데 많은 도움이됩니다. 클라이언트 측 상태를 사용하지 않으면 값 비싼 세션을 사용하기 때문입니다.
4. 웹 사이트는 매우 반응이 빠릅니다. SPA가 아닌 웹 사이트에서 계산기를 만들어보십시오 (이상한 것을 알고 있습니다).

댓글 업데이트

It doesn't seem like anyone mentioned about sockets and long-polling. If you log out from another client say mobile app, then your browser should also log out. If you don't use SPA, you have to re-create the socket connection every time there is a redirect. This should also work with any updates in data like notifications, profile update etc

An alternate perspective: Aside from your website, will your project involve a native mobile app? If yes, you are most likely going to be feeding raw data to that native app from a server (ie JSON) and doing client-side processing to render it, correct? So with this assertion, you're ALREADY doing a client-side rendering model. Now the question becomes, why shouldn't you use the same model for the website-version of your project? Kind of a no-brainer. Then the question becomes whether you want to render server-side pages only for SEO benefits and convenience of shareable/bookmarkable URLs

---

I am a pragmatist, so I will try to look at this in terms of costs and benefits.

Note that for any disadvantage I give, I recognize that they are solvable. That's why I don't look at anything as black and white, but rather, costs and benefits.

Advantages

• Easier state tracking - no need to use cookies, form submission, local storage, session storage, etc. to remember state between 2 page loads.
• Boiler plate content that is on every page (header, footer, logo, copyright banner, etc.) only loads once per typical browser session.
• No overhead latency on switching "pages".

Disadvantages

• Performance monitoring - hands tied: Most browser-level performance monitoring solutions I have seen focus exclusively on page load time only, like time to first byte, time to build DOM, network round trip for the HTML, onload event, etc. Updating the page post-load via AJAX would not be measured. There are solutions which let you instrument your code to record explicit measures, like when clicking a link, start a timer, then end a timer after rendering the AJAX results, and send that feedback. New Relic, for example, supports this functionality. By using a SPA, you have tied yourself to only a few possible tools.
• Security / penetration testing - hands tied: Automated security scans can have difficulty discovering links when your entire page is built dynamically by a SPA framework. There are probably solutions to this, but again, you've limited yourself.
• Bundling: It is easy to get into a situation when you are downloading all of the code needed for the entire web site on the initial page load, which can perform terribly for low-bandwidth connections. You can bundle your JavaScript and CSS files to try to load in more natural chunks as you go, but now you need to maintain that mapping and watch for unintended files to get pulled in via unrealized dependencies (just happened to me). Again, solvable, but with a cost.
• Big bang refactoring: If you want to make a major architectural change, like say, switch from one framework to another, to minimize risk, it's desirable to make incremental changes. That is, start using the new, migrate on some basis, like per-page, per-feature, etc., then drop the old after. With traditional multi-page app, you could switch one page from Angular to React, then switch another page in the next sprint. With a SPA, it's all or nothing. If you want to change, you have to change the entire application in one go.
• Complexity of navigation: Tooling exists to help maintain navigational context in SPA's, like history.js, Angular 2, most of which rely on either the URL framework (#) or the newer history API. If every page was a separate page, you don't need any of that.
• Complexity of figuring out code: We naturally think of web sites as pages. A multi-page app usually partitions code by page, which aids maintainability.

Again, I recognize that every one of these problems is solvable, at some cost. But there comes a point where you are spending all your time solving problems which you could have just avoided in the first place. It comes back to the benefits and how important they are to you.

---

Disadvantages

1. Client must enable javascript. Yes, this is a clear disadvantage of SPA. In my case I know that I can expect my users to have JavaScript enabled. If you can't then you can't do a SPA, period. That's like trying to deploy a .NET app to a machine without the .NET Framework installed.

2. Only one entry point to the site. I solve this problem using SammyJS. 2-3 days of work to get your routing properly set up, and people will be able to create deep-link bookmarks into your app that work correctly. Your server will only need to expose one endpoint - the "give me the HTML + CSS + JS for this app" endpoint (think of it as a download/update location for a precompiled application) - and the client-side JavaScript you write will handle the actual entry into the application.

3. Security. This issue is not unique to SPAs, you have to deal with security in exactly the same way when you have an "old-school" client-server app (the HATEOAS model of using Hypertext to link between pages). It's just that the user is making the requests rather than your JavaScript, and that the results are in HTML rather than JSON or some data format. In a non-SPA app you have to secure the individual pages on the server, whereas in a SPA app you have to secure the data endpoints. (And, if you don't want your client to have access to all the code, then you have to split apart the downloadable JavaScript into separate areas as well. I simply tie that into my SammyJS-based routing system so the browser only requests things that the client knows it should have access to, based on an initial load of the user's roles, and then that becomes a non-issue.)

Advantages

1. A major architectural advantage of a SPA (that rarely gets mentioned) in many cases is the huge reduction in the "chattiness" of your app. If you design it properly to handle most processing on the client (the whole point, after all), then the number of requests to the server (read "possibilities for 503 errors that wreck your user experience") is dramatically reduced. In fact, a SPA makes it possible to do entirely offline processing, which is huge in some situations.

2. Performance is certainly better with client-side rendering if you do it right, but this is not the most compelling reason to build a SPA. (Network speeds are improving, after all.) Don't make the case for SPA on this basis alone.

3. Flexibility in your UI design is perhaps the other major advantage that I have found. Once I defined my API (with an SDK in JavaScript), I was able to completely rewrite my front-end with zero impact on the server aside from some static resource files. Try doing that with a traditional MVC app! :) (This becomes valuable when you have live deployments and version consistency of your API to worry about.)

So, bottom line: If you need offline processing (or at least want your clients to be able to survive occasional server outages) - dramatically reducing your own hardware costs - and you can assume JavaScript & modern browsers, then you need a SPA. In other cases it's more of a tradeoff.

---

One major disadvantage of SPA - SEO. Only recently Google and Bing started indexing Ajax-based pages by executing JavaScript during crawling, and still in many cases pages are being indexed incorrectly.

While developing SPA, you will be forced to handle SEO issues, probably by post-rendering all your site and creating static html snapshots for crawler's use. This will require a solid investment in a proper infrastructures.

Update 19.06.16:

Since writing this answer a while ago, I gain much more experience with Single Page Apps (namely, AngularJS 1.x) - so I have more info to share.

In my opinion, the main disadvantage of SPA applications is SEO, making them limited to kind of "dashboard" apps only. In addition, you are going to have a much harder times with caching, compared to classic solutions. For example, in ASP.NET caching is extreamly easy - just turn on OutputCaching and you are good: the whole HTML page will be cached according to URL (or any other parameters). However, in SPA you will need to handle caching yourself (by using some solutions like second level cache, template caching, etc..).

---

I would like to make the case for SPA being best for Data Driven Applications. gmail, of course is all about data and thus a good candidate for a SPA.

But if your page is mostly for display, for example, a terms of service page, then a SPA is completely overkill.

I think the sweet spot is having a site with a mixture of both SPA and static/MVC style pages, depending on the particular page.

For example, on one site I am building, the user lands on a standard MVC index page. But then when they go to the actual application, then it calls up the SPA. Another advantage to this is that the load-time of the SPA is not on the home page, but on the app page. The load time being on the home page could be a distraction to first time site users.

This scenario is a little bit like using Flash. After a few years of experience, the number of Flash only sites dropped to near zero due to the load factor. But as a page component, it is still in use.

---

For such companies as google, amazon etc, whose servers are running at max capacity in 24/7-mode, reducing traffic means real money - less hardware, less energy, less maintenance. Shifting CPU-usage from server to client pays off, and SPAs shine. The advantages overweight disadvantages by far. So, SPA or not SPA depends much on the use case.

Just for mentioning another, probably not so obvious (for Web-developers) use case for SPAs: I'm currently looking for a way to implement GUIs in embedded systems and browser-based architecture seems appealing to me. Traditionally there were not many possibilities for UIs in embedded systems - Java, Qt, wx, etc or propriety commercial frameworks. Some years ago Adobe tried to enter the market with flash but seems to be not so successful.

Nowadays, as "embedded systems" are as powerful as mainframes some years ago, a browser-based UI connected to the control unit via REST is a possible solution. The advantage is, the huge palette of tools for UI for no cost. (e.g. Qt require 20-30$ per sold unit on royalty fees plus 3000-4000$ per developer)

For such architecture SPA offers many advantages - e.g. more familiar development-approach for desktop-app developers, reduced server access (often in car-industry the UI and system muddles are separate hardware, where the system-part has an RT OS).

As the only client is the built-in browser, the mentioned disadvantages like JS-availability, server-side logging, security don't count any more.

---

2. With SPA we don't need to use extra queries to the server to download pages.

I still have to learn a lot but since I started learn about SPA, I love them.

This particular point may make a huge difference.

In many web apps that are not SPA, you will see that they will still retrieve and add content to the pages making ajax requests. So I think that SPA goes beyond by considering: what if the content that is going to be retrieved and displayed using ajax is the whole page? and not just a small portion of a page?

Let me present an scenario. Consider that you have 2 pages:

1. a page with list of products
2. a page to view the details of a specific product

Consider that you are at the list page. Then you click on a product to view the details. The client side app will trigger 2 ajax requests:

1. a request to get a json object with the product details
2. a request to get an html template where the product details will be inserted

Then, the client side app will insert the data into the html template and display it.

Then you go back to the list (no request is done for this!) and you open another product. This time, there will be only an ajax request to get the details of the product. The html template is going to be the same so you don't need to download again.

You may say that in a non SPA, when you open the product details, you make only 1 request and in this scenario we did 2. Yes. But you get the gain from an overall perspective, when you navigate across of many pages, the number of requests is going to be lower. And the data that is transferred between the client side and the server is going to be lower too because the html templates are going to be reused. Also, you don't need to download in every requests all those css, images, javascript files that are present in all the pages.

Also, let's consider that you server side language is Java. If you analyze the 2 requests that I mentioned, 1 downloads data (you don't need to load any view file and call the view rendering engine) and the other downloads and static html template so you can have an HTTP web server that can retrieve it directly without having to call the Java application server, no computation is done!

Finally, the big companies are using SPA: Facebook, GMail, Amazon. They don't play, they have the greatest engineers studying all this. So if you don't see the advantages you can initially trust them and hope to discover them down the road.

But is important to use good SPA design patterns. You may use a framework like AngularJS. Don't try to implement an SPA without using good design patterns because you may end up having a mess.

---

Disadvantages: Technically, design and initial development of SPA is complex and can be avoided. Other reasons for not using this SPA can be:

• a) Security: Single Page Application is less secure as compared to traditional pages due to cross site scripting(XSS).
• b) Memory Leak: Memory leak in JavaScript can even cause powerful Computer to slow down. As traditional websites encourage to navigate among pages, thus any memory leak caused by previous page is almost cleansed leaving less residue behind.
• c) Client must enable JavaScript to run SPA, but in multi-page application JavaScript can be completely avoided.
• d) SPA grows to optimal size, cause long waiting time. Eg: Working on Gmail with slower connection.

Apart from above, other architectural limitations are Navigational Data loss, No log of Navigational History in browser and difficulty in Automated Functional Testing with selenium.

This link explain Single Page Application's Advantages and Disadvantages.

---

In my development I found two distinct advantages for using an SPA. That is not to say that the following can not be achieved in a traditional web app just that I see incremental benefit without introducing additional disadvantages.

• Potential for less server request as rendering new content isn’t always or even ever an http server request for a new html page. But I say potential because new content could easily require an Ajax call to pull in data but that data could be incrementally lighter than the itself plus markup providing a net benefit.

• The ability to maintain “State”. In its simplest terms, set a variable on entry to the app and it will be available to other components throughout the user’s experience without passing it around or setting it to a local storage pattern. Intelligently managing this ability however is key to keep the top level scope uncluttered.

Other than requiring JS (which is not a crazy thing to require of web apps) other noted disadvantages are in my opinion either not specific to SPA or can be mitigated through good habits and development patterns.

---

Try not to consider using a SPA without first defining how you will address security and API stability on the server side. Then you will see some of the true advantages to using a SPA. Specifically, if you use a RESTful server that implements OAUTH 2.0 for security, you will achieve two fundamental separation of concerns that can lower your development and maintenance costs.

1. This will move the session (and it's security) onto the SPA and relieve your server from all of that overhead.
2. Your API's become both stable and easily extensible.

Hinted to earlier, but not made explicit; If your goal is to deploy Android & Apple applications, writing a JavaScript SPA that is wrapped by a native call to host the screen in a browser (Android or Apple) eliminates the need to maintain both an Apple code base and an Android code base.

---

I understand this is an older question, but I would like to add another disadvantage of Single Page Applications:

If you build an API that returns results in a data language (such as XML or JSON) rather than a formatting language (like HTML), you are enabling greater application interoperability, for example, in business-to-business (B2B) applications. Such interoperability has great benefits but does allow people to write software to "mine" (or steal) your data. This particular disadvantage is common to all APIs that use a data language, and not to SPAs in general (indeed, an SPA that asks the server for pre-rendered HTML avoids this, but at the expense of poor model/view separation). This risk exposed by this disadvantage can be mitigated by various means, such as request limiting and connection blocking, etc.

참고URL : https://stackoverflow.com/questions/21862054/single-page-application-advantages-and-disadvantages