Breaking out parts of your code that don’t need to run 24/7 on a full blown service will not only make debugging easier but will also optimize performance.
and Linux Fan Boy • You can follow me on twitter @TiemmaBakare • General Weird Guy with some humour • People call me Bakman, so there’s also that! @ T i e m m a B a k a r e 2
3. Microlith (Bad design) 4. SPA / Backend -> Frontend 5. Microservices 6. Event Driven Applications a. Handlers to Events (1 to 1, no more) b. Events are to be unique and handled in no two ways 1. DEMO!!! 2. Event Sourcing and CQRS a. MemoryImage & ParallelModel b. Recording event data as it streams c. Event Logs and how they’re build 3. Event Collaboration 4. Retroactive Events 5. Resources YOU CAN COVER 2 - 4 FOR MORE INFO! HISTORY OF SOFTWARE ARCHITECTURES MORE BACKGROUND ON EVENT ARCHITECTURE
the requests we make, a frontend is the part of the entire thing that we interact with. A frontend could be a web browser, a load balancer, an api gateway etc. Backend: This is the main server that gets all the requests we push from the frontend. It is responsible for handling all the requests that we need to process. Tier - Basically a layer / part of the entire systems that interact with each other Microservice - This is basically a single service that does one thing and does it very well. Events - This is just a call to action, which has a subscriber and producer for handling it. PubSub - This means PublisherSubscriber and is related to systems that can read and write data in real time.
two, three parts of your application, all in order 1. Presentation Layer (Frontend e.g Vue) 2. Application Layer (Backend e.g Django, Flask, NodeJS) 3. Data Layer (Database, Persistence e.g Redis, Mongo, SQL)
This is a form of software architecture where the backend and frontend are detached. Requests are made using one-way or streaming connections and several backend functionality can be emulated on the frontend by local caching and routing. Examples are front ends on (service workers, PWAs, web components) using backends on (websockets / http/2 / gRpc / APIs) etc
thing and does it very well. So that means we can have a single service that does one thing. We could have a service for authentication, emails, transactions and whatever we feel needs to be singled out. It’s most preferred due to the fact that services can be rolled back and forward easily without directly bringing down the others. It’s also a lot more complex to orchestrate and requires fine understanding of the entire product. Directly - In the sense that an error there might bring down that service but the others that don’t need it work fine
functions on a pub-sub way of receiving data. In this kind of system, we can have multiple people publishing data to a queue and many subscribers reading the same data at the same time. This allows for a many to many call to action kinda API request. We publish and subscribe by using topics or channels. Whatever you use to call them, it’s just a simple pipe. What ever you send to it can be read on the other side at about the instant it’s sent, similar to a water pipe.
concept of attaching handlers to events. A handler is just a fancy word for a function that reacts to that event. For those familiar with Javascript and the EventListener concept, you have an event and a callback function to handle it. That event and the function are uniquely bonded together.
to be unique, the concept is to have a specific event attached to a specific action and ONLY that action, no duplicates. To properly group events that are similar, we use namespaces which is just simply attaching it in the following way: <EVENT_GROUP>.<EVENT_NAME> ==== user.signup, email.send, folder.create etc.