Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Architecture june 2019

100 views

Published on

Squidex Software Architecture

Published in: Software
  • Be the first to comment

  • Be the first to like this

Architecture june 2019

  1. 1. June 2019
  2. 2. Architecture principles • Easy to deploy in different environments • Squidex is not only a SaaS product. As Open Source solution it must be easy to deploy. • Fast and efficient • Because Squidex is also used within other processes it must not become the bottleneck. • Transparent and trackable • Everything that happens in the system must be trackable.
  3. 3. Web Cluster (k8) Mongo Replica Set Deployment Architecture 1 DB 1 DB 2 DB 3 Node 1 Node 2 Node 3 Load Balancer (Cloud) WorkerRedis MVC Domain Data
  4. 4. Deployment Architecture 1 - Evaluation Advantages • Typical software architecture without surprises. • Developers and administrators have experience with this architecture. Disadvantages • Worker is essential to the system, which would not work properly without it. • Worker is a single point of failure • System is hard to deploy because you had four deployment artifacts: Squidex, Squidex Worker, MongoDB and Redis
  5. 5. Squidex Cluster (k8) Mongo Replica Set Deployment Architecture 2 Node 1 Node 2 Node 3 Load Balancer (Cloud) MVC MVC MVC Orleans E I D B BE I I D D D Microsoft Orleans • Distributed actor framework. • Actors are virtual and will be created and destroyed automatically in the cluster. Actors / Grains: D Domain Objects E Event Consumers I Indices B Background Processes
  6. 6. Deployment Architecture 2 - Evaluation Advantages • Orleans is a proven system from multiplayer games (Halo) • When a node goes down, actors will be activated on other nodes. • Actor model is faster, less calls to database, no caching. • Actors are great for long running processes. Disadvantages • Orleans is not easy to understand and to maintain.
  7. 7. Patterns: Event Sourcing • Persistence pattern (no system pattern) • State is represented as source of events. • Event is something that happened in the past. • Snapshot (state at given a point of time) can be derived from events. • Events cannot be derived from snapshots. • Source of truth (vs. Audit Log, vs. Domain Events) • Inefficient for reading (CQRS!) ItemAddedBasket ItemAdded ItemRemoved
  8. 8. Patterns: CQRS - Command query responsibility segregation Architecture Myths • Myth #1 – CQRS = Event Sourcing and vice versa • Myth #2 – CQRS requires an eventual consistent read store • Myth #3 – Commands are fire- and-forget CommandQuery DB DB Domain
  9. 9. CQRS Implementation 1 Command Handler Repository Read Store Event Store Domain Object PubSub, e.g. Redis API Layer Caches Event Consumer Pulls Events Notify about new EventsNotify about new Events Creates events from previous events and command
  10. 10. CQRS Implementation 1 - Evaluation Advantages • Strict isolation between write and read side. • No transactions required. • Easy to rebuild read models, just restart event consumers. Disadvantages • Eventual consistency model is hard to understand and to use. • Event consumers can fail silently. • You have to query all events when you make updates.
  11. 11. CQRS Implementation 2 Command Handler Query Full Text Event Store Domain Object Orleans for PubSub API Layer Event Consumer Notify about new EventsNotify about new Events Creates events from previous events and command Snapshots Pulls Events Indices Contents+Assets Apps+Schemas+Rules Read Store Special Grains
  12. 12. CQRS Implementation 2 - Evaluation Advantages • Stronger consistency model, which is easy to understand. • Specialized solution for different problems. • Less important or slow persistency processes are running in the background. Disadvantages • Harder to understand because of different solutions. • Would require transactions, but never became a problem so far.
  13. 13. Events • Simple POCOs • Serializable to JSON • Can be migrated to new events • Inherit from base events for common behavior
  14. 14. Domain Objects • Properties • Immutable • Thread Safe (Orleans) • Serializable to JSON • Dependency free • Advantages • Independent from infrastructure • Easy to use • Easy to test
  15. 15. Domain Entities • Responsibilities: • Create events • Validate commands • Ensure consistency • Derive snapshot from events • From Base class: • Read snapshot • Read events (after snapshot) • Write events • Write snapshot • Ensure consistency with versioning
  16. 16. API Design - Versioning • Domain Objects provide versioning out of the box: • Version = Number of Applied Events • Versioning can be used for optimistic concurrency: • Return current version as etag-header and/or response field. • Provide expected version with if-match header. • PUT: Return 412: PreconditionFailed error code for version mismatch. • GET: Return 304: NotModified with empty body for version match
  17. 17. API Design - Security • API is secured with OpenID Connect OAuth 2.0 and Identity Server: • http://docs.identityserver.io/en/latest/ • Well defined specification • Implementation from German security expert. • Identity Server is co-hosted in the same application • Can be replaced with other OIDC servers: • https://www.keycloak.org/ (JAVA) • https://auth0.com/de/ (SaaS) • Hierarchical permission system: https://docs.squidex.io/concepts/permissions
  18. 18. API Design - Evaluation Advantages • Efficient, because only the minimum amount of version are sent over. • Good caching effects with Etag support. • Good documentation with OpenAPI and Redoc. Disadvantages • Allowed operations not documented by the API itself. • Mutations after operations have to be implemented by UI. • Therefore a lot of duplicate code and dependencies.
  19. 19. API Improvements - HATEOS • Describe possible operations with links. • If a link is not part of response the operation is either not possible or not allowed for the current user. • Permissions do not have to be implemented in the UI. • Workflows do not have to be implemented in the UI.
  20. 20. API Improvements – Response bodies • API returns only minimum amount of information for operations: • POST: Usually the Id and additional values added by the API • PUT/PATCH/DELETE: 204 with empty body. • What is the (new) resource structure after creation or update? • Requires a lot of domain knowledge and violates SRP. • What are the allowed operations for new resources? • NEW Concept: Return full resource after each creation or update.
  21. 21. General problems and perspective • No strict separation between contracts and implementation 1. Extract contracts to projects and assemblies 2. Publish contracts to NuGet to enable easy Plugin development • No load shedding for Orleans yet 1. Just integrate it for Windows and Linux • No use of Angular CLI 1. Wait for Angular 9 and then migrate it. Prototype available. 2. Or integrate it for e2e tests. • Simplify UI and API with HATEOS (Prototype available)
  22. 22. Frontend • Angular 7 (PR for Angular 8 completed) • Angular AOT compiler • Unit tests with karma • Styles with scss. • Custom and optimized webpack config. • Currently faster and smaller results than CLI
  23. 23. Angular States • Like redux but with less code: • Immutable state (snapshot) • Implemented with rxjs (BehaviorSubject) • Access to changes • Access to state • Relatively easy to test with Mockups

×