According to Robert C. Martin's "Clean Architecture" you should try to structure your system in such a way as to separate low-level concerns from high-level domain concepts.

Following this logic, Martin proposes, that

the Web is a delivery mechanism—an IO device—and [...]

therefore should be seen as a low-level concern. As a consequence, Web apps should only present data they receive from the domain.

In principle, a PWA could be seen as its own enclosed system with appropriate architectural boundaries, so that the app wouldn't need to have a backend which contains the domain logic. In that case, implementing the Clean Architecture would be a fairly trivial act.

But imagine your domain logic already exists on, say, a server. How would you then avoid duplicating your domain logic into the PWA if UX concepts such as offline availability are key to your product? What if your domain logic is quite sensitive and mustn't be exposed to end users under any circumstance? (e.g. by implementing it inside a PWA)

Another way to phrase the question would be: How do you build PWAs with rich UX, such as offline capability, without exposing your potentially sensitive domain logic by embedding it into the frontend?

  • 3
    Why would you create a PWA if domain logic is mainly contained on server? Isn't point of PWA that it can run offline and without server?
    – Euphoric
    Jan 6, 2021 at 21:22
  • 3
    If your app needs to be able to run offline, the code has to be delivered to the user, period. You can not keep the code on the server and only expose it as a service if you need offline capabilities. You are trying to fit a square pig in a round hole. Having to deliver a working app to the customer is the price to pay if you want offline execution.
    – Polygnome
    Jan 6, 2021 at 21:48
  • 3
    What do you mean by "expose ... domain logic?" Exposing source code? Exposing logic to malicious users? Jan 6, 2021 at 23:26
  • @Euphoric Answering your first question: To for example have an offline web app. Second question: Exactly, so if it should run offline without a server, it obviously needs to have access to domain logic. Therefore you need to a) expose your domain logic to the end user (indirectly) and b) duplicate your already existing domain logic to the web app. Either way, you can only break the existing architecture, can't you?
    – Max Krass
    Jan 6, 2021 at 23:37
  • @GregBurghardt You would be forced to essentially ship your domain logic with the PWA to have it work offline. If you previously followed the Clean Architecture, your domain logic will be behind at least one architectural boundary. I see no way of achieving both offline capability, as well as keeping your architecture intact
    – Max Krass
    Jan 6, 2021 at 23:41

1 Answer 1


A PWA is nothing more than a Client. Clients and Servers have existed for decades, and often they share logic.

To handle shared logic the tried and tested methods are:

  • Literally share the logic as a library.
    • As web code is largely JavaScript based a Library of JavaScript
  • Duplicate the implementation, but have a single specification.
    • In short write comprehensive automation tests and run them against a PWA version, and against the Server version.
  • Break the requirement to share logic in the first place.
    • Are you certain that the logic is actually required in both places?
    • Are you 100% certain that the same forces of change are acting on both sides?
    • Are the x% of cases enabled worth the cost?

Also if you want the client to perform logic on the users computer, the logic must be exposed to that users computer. No two ways about it. So if its a strict no no for the users computer, its strictly an online only feature.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.