|
|
|
|
|
|
by t_fatus
3073 days ago
|
|
|
One thing I learnt to love about SPAs is how they distribute responsibilities: obv you get 3 layers: - your DB which stores your data - your backend which access your data, retrieve it safely, and delivers it without having to know anything about the client it serves. - your frontend which handle how / when it needs data, which data it needs, how it caches it. Separation is good, since you can test your API without needing your client, you can test your client code with mock data, you can build different clients (web, native apps, ..) over the same API (and even do not need to build an API if you're using things like graphql) |
|
|
- an infrastructure layer for managing data
- a domain layer for enforcing rules and encapsulating data access/management (completely independent of the view)
- (optional) an application/service layer between your domain and presentation to provide a common interface for convenience
- a presentation layer for handling view semantics
a service layer can be very useful if migrating from a traditional app to a SPA because it makes creating your API almost trivial.
There is nothing about creating a SPA that makes a 3-layer architecture any simpler or cleaner. In fact, these days it is quite the opposite. You have all of the above systems in your application PLUS another MVC (or MVVM) framework on the client. The entire point of the MVC architecture is to allow for the switching/replacement of the "V".