Designing a ui for microservices

This document discusses different approaches to designing a user interface for a microservices architecture. It begins by proposing a domain model decomposition with individual services owning pieces of product data. However, this poses issues for users who need an aggregated view. An alternative presented is to have individual services cache normalized data and compose a view model at the edge. Later approaches incorporate client-side messaging, hosting the composition engine in MVC, and using view components to give services more ownership over vertical slices of the UI. The key takeaways are that the UI structure can be defined at the edge while still keeping domain responsibilities clear across services.

Tutto quello che avreste voluto sapere sull'API Management (e non avete mai o...

Massimo Bonanni

Designing a UI for microservices

Do IT Better Community

The agenda covers various topics related to conversion optimization and user experience including recommended tools, project styles, analytics tips, best practices, and opportunities for site reviews. Key learning points from 6 years of optimization experience will also be discussed. The session will be led by an experienced director of optimization with past experience at several large companies.

Reactive summit 2018

Joongjin Bae

The document discusses the Reactive Summit 2018 conference, including topics on microservices, reactive systems, and the Reactive Summit schedule. Some of the session topics included reactive microservice architecture, distributed transactions, streaming data applications, event-driven systems, and chaos engineering. The schedule provided links to over 20 sessions that would be presented at the conference.

SharePoint development evolution from classic to app

Marco Rizzi

This document contains notes from a presentation on apps for SharePoint. It discusses the differences between the traditional WSP solution package model and the new app model in SharePoint 2013. Various approaches for developing apps are presented, including using remote web services and pages rather than custom server-side objects. The document also covers provisioning functionality through apps, including provisioning sites, app stapling to add apps during site creation, and apps that can execute workflows automatically without user intervention.

APIdays Helsinki 2019 - Lean Method for Building Good APIs for Business – API...

Lean and Business oriented method at APIOps Cycles APIDays Finland 2019

Marjukka Niinioja presents the APIOps Cycles method for building APIs using lean principles. The method focuses on collaborating with customers, adopting a DevOps mindset, and considering business needs and developer experience. Key aspects of the method include prototyping APIs, conducting API audits, and connecting APIs to business goals using canvases. The goal is to minimize waste and build the right APIs for customers through an iterative process.

How to get your management board to Teams Kettukari MWPC Paris 191.2021

Karoliina Kettukari

TYPO3 + Magento + SugarCRM + Alfresco: An Enterprise Integrated Platform

Mauro Lorenzutti

Creating an Accessibility Machine for 220 Million Users

NirHoresh2

50 Great Products For Startups

Muhammed Tüfekyapan

apidays LIVE Jakarta - What will the next generation of API Portals look like...

Lizards & Pumpkins Catalog Replacement at mm17de

vinaikopp

Mconf14 aperto vanity url-app

Aperto Nachname

There is an App for...Vanity URLs

Magnolia

apidays Paris 2022 - Lessons from the evolution of API product management ove...

apidays Paris 2022 - APIs the next 10 years: Software, Society, Sovereignty, Sustainability December 14, 15 & 16, 2022 Lessons from the evolution of API product management over the last 10 years: what they could mean from here Claire Barrett, Director at APIsFirst ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/ Deep dive into the API industry with our reports: https://www.apidays.global/industry-reports/ Subscribe to our global newsletter: https://apidays.typeform.com/to/i1MPEW

Marjukka Niinioja at APIdays Amsterdam 2019

BrightonSEO April 2022 - Kara Thurkettle - Search in the Metaverse.pdf

🇺🇲 🇬🇧 Kara Thurkettle

1) What is "The Metaverse?" 2) What technologies are being used within The Metaverse? 3) How are these technologies transforming shopping behavior? 4) How are the technologies impacting search? 5) Why should search professionals care and how do we optimise for this? 6) What gives NFTs their value and how can we optimise them? 7) What types of experiences are industries creating with these technologies? 8) What the user concerns around "The Metaverse" and how cam we be more ethical?

Search in the Metaverse

Kaizen

[RakutenTechConf2013] [E-2] HTML5 in Rakuten

Rakuten Group, Inc.

Welcome to the (state) machine @ ExploreDDD 2019

Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long running business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb. This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind. (It’s all right, I know where you’ve been)

Designing a ui for microservices @ .NET Day Switzerland 2019

Similar to Designing a ui for microservices

Design a UI for your Microservices @ Do IT Better

Generazione dinamica della UI con Blazor WebAssembly

Michele Aponte

Conversionista : Conversion manager course - Stockholm 20 march 2013

Craig Sullivan

Reactive summit 2018

Joongjin Bae

SharePoint development evolution from classic to app

Marco Rizzi

APIdays Helsinki 2019 - Lean Method for Building Good APIs for Business – API...

Lean and Business oriented method at APIOps Cycles APIDays Finland 2019

How to get your management board to Teams Kettukari MWPC Paris 191.2021

Karoliina Kettukari

TYPO3 + Magento + SugarCRM + Alfresco: An Enterprise Integrated Platform

Mauro Lorenzutti

Creating an Accessibility Machine for 220 Million Users

NirHoresh2

50 Great Products For Startups

Muhammed Tüfekyapan

apidays LIVE Jakarta - What will the next generation of API Portals look like...

Lizards & Pumpkins Catalog Replacement at mm17de

vinaikopp

Mconf14 aperto vanity url-app

Aperto Nachname

There is an App for...Vanity URLs

Magnolia

apidays Paris 2022 - Lessons from the evolution of API product management ove...

Marjukka Niinioja at APIdays Amsterdam 2019

BrightonSEO April 2022 - Kara Thurkettle - Search in the Metaverse.pdf

🇺🇲 🇬🇧 Kara Thurkettle

Search in the Metaverse

Kaizen

[RakutenTechConf2013] [E-2] HTML5 in Rakuten

Rakuten Group, Inc.

Similar to Designing a ui for microservices (20)

Design a UI for your Microservices @ Do IT Better

Generazione dinamica della UI con Blazor WebAssembly

Conversionista : Conversion manager course - Stockholm 20 march 2013

Reactive summit 2018

SharePoint development evolution from classic to app

APIdays Helsinki 2019 - Lean Method for Building Good APIs for Business – API...

Lean and Business oriented method at APIOps Cycles APIDays Finland 2019

How to get your management board to Teams Kettukari MWPC Paris 191.2021

TYPO3 + Magento + SugarCRM + Alfresco: An Enterprise Integrated Platform

Creating an Accessibility Machine for 220 Million Users

50 Great Products For Startups

apidays LIVE Jakarta - What will the next generation of API Portals look like...

Lizards & Pumpkins Catalog Replacement at mm17de

Mconf14 aperto vanity url-app

There is an App for...Vanity URLs

apidays Paris 2022 - Lessons from the evolution of API product management ove...

Marjukka Niinioja at APIdays Amsterdam 2019

BrightonSEO April 2022 - Kara Thurkettle - Search in the Metaverse.pdf

Search in the Metaverse

[RakutenTechConf2013] [E-2] HTML5 in Rakuten

More from Mauro Servienti

Welcome to the (state) machine @ ExploreDDD 2019

Designing a ui for microservices @ .NET Day Switzerland 2019

Welcome to the (state) machine @ Xe One Day Enterprise Applications

Ultimamente ci hanno stressato come non mai che stateful è il male. Tutto deve essere stateless, altrimenti non scala, non può essere altamente disponibile, ed è complesso da manutenere ed evolvere. Nonostante questo i sistemi software complessi, essendo basati su processi collaborativi, sono per natura stateful. I processi collaborativi, noti anche come long running business transactions, necessitano di interagiscono con risorse distribuite. L’approccio tradizionale basato su transazioni distribuite, anche se allettante, è una bomba pronta ad esplodere. Pane quotidiano per le Saghe. Le Saghe consentono di modellare sistemi complessi senza la necessità di transazioni distribuite e coordinamento esterno. Vedremo cosa sono le Saghe, come possono essere usate per modellare domini complessi, e che ruolo giocano quando progettiamo sistemi basati sui concetti di “design for failures” e “eventual consistency” (It’s all right, I know where you’ve been)

All our aggregates are wrong @ NDC Copenhagen 2019

It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule. In this talk, we’ll analyze what appears to be a straightforward e-commerce shopping cart. We’ll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we’ll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.

Be like water, my friend @ Agile for Innovation 2019

L’acqua è quasi inarrestabile, basta un pertugio e si propaga. Basta un po’ di pressione e con facilità il pertugio diventa una voragine e lascia spazio ad una piena. La conoscenza e l’esperienza in un team possono essere come l’acqua. Il sapere deve poter scorrere senza freni, con solo degli argini che lo guidino al fine di evitare un’inondazione. È possibile strutturare un’organizzazione al fine di garantire la diffusione del sapere? Quali sono i processi e gli strumenti che possiamo mettere in campo per essere certi che conoscenza ed esperienza siano diffuse, ma anche che non vi sia un’inondazione? Lasciatevi trasportare da Mauro nei meandri di Particular Software, per scoprire come una realtà “dispersa” su 17 time zone gestisce collaborazione e condivisione del sapere. Analizzeremo sia i processi, che ci siamo creati, che gli strumenti digitali che usiamo quotidianamente.

Microservices architecture is it the right choice to design long-living syste...

Microservices all the thing! they say. Nowadays it seems that if architectures are not microservices based they are not worth the name. Is it really true? Do we really need a (micro)services based architecture? We should design our systems with longevity, manutenability, and evolution simplicity in mind. Not hype. Long living systems are our primary goal. We'll analyze most common errors and we'll see how architecture can be a game changer in systems design. Join Mauro in a journey that aims to disclose what it means to build a distributed system based on a (micro)services oriented architecture.

Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019

Living organizations, particular software @ do IT Better Parma

Siamo così abituati ad organizzazioni basate sul tradizionale organigramma che diamo per scontato che sia l'unica opzione. Un approccio differente è possibile? Quando sono entrato in Particular, era un'organizzazione tradizionale, sebbene distribuita. Avevamo manager e una gerarchia. Un anno dopo la decisione di rivoluzionare tutto. La miglior decisione di sempre. Intraprenderemo un viaggio che ci permetterà di scoprire che un modello organizzativo diverso è possibile, che un processo decisionale dall'alto verso il basso non è l'unica opzione e che possiamo organizzare la vita lavorativa intorno a quella privata in funzione di un ottimo life-work balance.

Welcome to the (state) machine @ Crafted Software

Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb. This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind. (It’s all right, I know we’re you’ve been)

PO is dead, long live the PO - Italian Agile Day 2018

Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.

Microservices and pineapple on pizza what do they have in common - dos and ...

Microservices è una delle buzzword del momento. Sembra quasi che un'architettura a microservices sia fondamentale. È veramente così? Faremo un tortuoso viaggio tra le buzzword del momento cercando di districarci tra cosa è bene e cosa è meno bene, ma soprattutto perché. Obiettivo è quello di comprendere quali sono i limiti di certe scelte architetturali e quali gli errori da non commettere. Il tutto nell'ottica di garantire ai nostri sistemi 'lunga vita e prosperità' (cit.)

All our aggregates are wrong (ExploreDDD 2018)

It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule. In this talk, we'll analyze what appears to be a straightforward e-commerce shopping cart. We'll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we'll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.

Po is dead, long live the po

Shipping code is not the problem, deciding what to ship it is!

This document discusses an organization's approach to prioritizing work and developing software. It emphasizes focusing on solving clear problems rather than executing on estimates or deadlines. Work is organized into buckets or strategies, each with a dedicated squad prioritizing issues. Issues go through an intake process to clearly define the problem before being selected for a cross-functional task force to implement a solution. The goal is for squads to proactively address problems rather than reactively execute work.

GraphQL - Where are you from? Where are you going?

GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.

Dall'idea al deploy un lungo viaggio che passa per git flow e semver

Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi. Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog? Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.

The road to a Service Oriented Architecture is paved with messages

One of the options on the table when implementing a Service Oriented Architecture (SOA), or the communication style across multiple microservices, is based on messages and a service bus. This talk will drive you through the basic SOA building blocks, introduce message based architectures, and will connect the dots between technology and architectural principles through some samples using NServiceBus.

La via verso SOA è lastricata di messaggi

The document discusses how a service-oriented architecture is built on a message-based infrastructure and outlines some of the benefits of using messaging patterns between services rather than direct integration. Messages allow for loose coupling between services, autonomous components that respect boundaries, and easy scalability through asynchronous communication and competing consumers. Transaction handling becomes simpler with messages since each operation is independent rather than spanning multiple systems.

Implementare il single sign on con IdentityServer

How we daily manage and work in a dispersed company: Particular Software