Hence, looking to divide the system to make it maintainable. Now, our app is monolith where we have everything to solve the domain problem as well as Slack/Teams integration logic that makes our current system hard to maintain, debug and add features. That way, when testing, we should be able to test whether the core behaves correctly by testing the endpoint directly by posting the payloads to core app.
We thought to divide this knowledge into two - the core/domain knowledge should be wrapped up in core and Slack/Teams specific stuff should go into their own app/service. Our app has to handle both the Slack integration knowledge (web hooks, events, Slack validations, etc) and it needs to have domain knowledge - what fields we should get from user if they can create an issue from Slack/Teams. Our app has to build this modal dialog as json and submit to to Slack for the dialog to appear. Let's say, we require title, priority & assignee. Both Slack and Teams provide modal dialog where we inject our business logic to build custom dialog and data capturing. Triggers when you click the 'Push to Zapier' button from a message in Slack. Once this Zap is active, it will automatically create a Microsoft To Do task from each new pushed message in Slack. Which means, the user should be able to create an issue from Slack/Teams. Make sure your to-do list stays up to date without having to leave Slack. Let's say that we want to build Slack & Teams integration for a Trello-like app. Should we inspire on Bot framework and build adapter for Messenger platforms? Or, customize/build on top of Bot framework itself?Įdit: Adding use case to give some context. Microsoft Bot framework also attempts to solve similar problem but they their own architecture & design. Should we add BoltJS in both of our Apps or just the Slack Adapter App? We also need to leverage BoltJS for Slack interactions. I'm not sure whether this problem would come under Backend-For-Frontend/API Proxy pattern or some other architecture/design. Core app is meant to perform slack-independent business logic and Slack Integration is meant to do Slack-specific operations (Events, Actions, Modals, etc) and also communicate with Core App to complete non-Slack works.
Hence, we thought to divide our single monolith into two sub apps.
#Slack microsoft to do integration code#
Both Slack & Team has a single Web hook endpoint which makes the app code tightly coupled with them and hard to make the core business logic verify-able. We are building bot application that suppose to support both Slack & Teams.
0 kommentar(er)
