microservices

SophiaH67 commented

2023-06-14 18:54:57 +02:00

(Migrated from github.com)

No description provided.

fredi-68 commented

2023-07-19 21:44:07 +02:00

(Migrated from github.com)

In software engineering, a microservice architecture is a variant of the service-oriented architecture structural style. It is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is that teams can develop and deploy their services independently of others. This is achieved by the reduction of several dependencies in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users.[1] As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.

In [software engineering](https://en.wikipedia.org/wiki/Software_engineering), a microservice architecture is a variant of the [service-oriented architecture](https://en.wikipedia.org/wiki/Service-oriented_architecture) structural style. It is an [architectural pattern](https://en.wikipedia.org/wiki/Architectural_pattern) that arranges an application as a collection of [loosely coupled](https://en.wikipedia.org/wiki/Loose_coupling), [fine-grained](https://en.wikipedia.org/wiki/Granularity) services, communicating through [lightweight protocols](https://en.wikipedia.org/wiki/Lightweight_protocol). One of its goals is that teams can develop and [deploy](https://en.wikipedia.org/wiki/Software_deployment) their services independently of others. This is achieved by the reduction of several [dependencies](https://en.wikipedia.org/wiki/Coupling_(computer_programming)) in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users.[[1]](https://en.wikipedia.org/wiki/Microservices#cite_note-1) As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public [API](https://en.wikipedia.org/wiki/API). One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.

SophiaH67 commented

2023-07-19 22:10:42 +02:00

(Migrated from github.com)

That's so true Fredi!

On Wed, Jul 19, 2023, at 9:44 PM, fredi_68 | Jay | Fredi | Whatever, at this point anything is fine wrote:

In software engineering https://en.wikipedia.org/wiki/Software_engineering, a microservice architecture is a variant of the service-oriented architecture https://en.wikipedia.org/wiki/Service-oriented_architecture structural style. It is an architectural pattern https://en.wikipedia.org/wiki/Architectural_pattern that arranges an application as a collection of loosely coupled https://en.wikipedia.org/wiki/Loose_coupling, fine-grained https://en.wikipedia.org/wiki/Granularity services, communicating through lightweight protocols https://en.wikipedia.org/wiki/Lightweight_protocol. One of its goals is that teams can develop and deploy https://en.wikipedia.org/wiki/Software_deployment their services independently of others. This is achieved by the reduction of several dependencies https://en.wikipedia.org/wiki/Coupling_(computer_programming) in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users.[1] https://en.wikipedia.org/wiki/Microservices#cite_note-1 As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API https://en.wikipedia.org/wiki/API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.

—
Reply to this email directly, view it on GitHub https://github.com/marnixah/isla-bot/pull/2#issuecomment-1642659147, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSJLJDNUXR2NKGUDK755XTXRA2JFANCNFSM6AAAAAAZGU4B6I.
You are receiving this because you authored the thread.Message ID: @.***>

That's so true Fredi! On Wed, Jul 19, 2023, at 9:44 PM, fredi_68 | Jay | Fredi | Whatever, at this point anything is fine wrote: > > > In software engineering <https://en.wikipedia.org/wiki/Software_engineering>, a microservice architecture is a variant of the service-oriented architecture <https://en.wikipedia.org/wiki/Service-oriented_architecture> structural style. It is an architectural pattern <https://en.wikipedia.org/wiki/Architectural_pattern> that arranges an application as a collection of loosely coupled <https://en.wikipedia.org/wiki/Loose_coupling>, fine-grained <https://en.wikipedia.org/wiki/Granularity> services, communicating through lightweight protocols <https://en.wikipedia.org/wiki/Lightweight_protocol>. One of its goals is that teams can develop and deploy <https://en.wikipedia.org/wiki/Software_deployment> their services independently of others. This is achieved by the reduction of several dependencies <https://en.wikipedia.org/wiki/Coupling_(computer_programming)> in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users.[1] <https://en.wikipedia.org/wiki/Microservices#cite_note-1> As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API <https://en.wikipedia.org/wiki/API>. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code. > > > — > Reply to this email directly, view it on GitHub <https://github.com/marnixah/isla-bot/pull/2#issuecomment-1642659147>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACSJLJDNUXR2NKGUDK755XTXRA2JFANCNFSM6AAAAAAZGU4B6I>. > You are receiving this because you authored the thread.Message ID: ***@***.***> >

This pull request has changes conflicting with the target branch.

.github/workflows/docker-publish.yaml
Dockerfile
package-lock.json
package.json
packages/isla-chat/src/directive-handler/Classes/interfaces/IslaChannel.ts
packages/isla-chat/src/directive-handler/Classes/interfaces/IslaMessage.ts
packages/isla-chat/src/directive-handler/Classes/interfaces/IslaUser.ts
packages/isla-chat/src/directive-handler/Classes/mood/dicts/Bt7274Dictionary.ts
packages/isla-chat/src/directive-handler/Classes/mood/dicts/IslaAsleepDictionary.ts
packages/isla-chat/src/directive-handler/Classes/mood/dicts/IslaExhaustedDictionary.ts
packages/isla-chat/src/directive-handler/Classes/mood/dicts/IslaFocusedDictionary.ts
packages/isla-chat/src/directive-handler/Classes/mood/dicts/IslaFrustratedDictionary.ts
packages/isla-chat/src/directive-handler/Classes/mood/dicts/index.ts
packages/isla-chat/src/directive-handler/Classes/mood/states/AwakeState.ts
packages/isla-chat/src/directive-handler/Classes/mood/states/BaseState.ts
packages/isla-chat/src/directive-handler/Classes/mood/states/Bt7274State.ts
packages/isla-chat/src/directive-handler/Classes/mood/states/SleepingState.ts
packages/isla-chat/src/directive-handler/Command.ts
packages/isla-chat/src/directive-handler/Commands/DebugConversationCommand.ts
packages/isla-chat/src/directive-handler/Commands/LightsCommand.ts
packages/isla-chat/src/directive-handler/Commands/RemindmeCommand.ts
packages/isla-chat/src/directive-handler/Commands/RssCommand.ts
packages/isla-chat/src/directive-handler/Commands/ShellCommand.ts
packages/isla-chat/src/directive-handler/Commands/SpellCheckCommand.ts
packages/isla-chat/src/directive-handler/Commands/WeatherCommand.ts
packages/isla-chat/src/directive-handler/Conversation.ts
packages/isla-chat/src/directive-handler/DirectiveHandler.ts
packages/isla-chat/src/directive-handler/HomeAssistant.ts
packages/isla-chat/src/directive-handler/PilotGuard.ts
packages/isla-chat/src/directive-handler/Services/BaseService.ts
packages/isla-chat/src/directive-handler/Services/CommandService.ts
packages/isla-chat/src/directive-handler/Services/ConversationManagerService.ts
packages/isla-chat/src/directive-handler/Services/LoggingService.ts
packages/isla-chat/src/directive-handler/Services/MessageLoggerService.ts
packages/isla-chat/src/directive-handler/Services/MqttService.ts
packages/isla-chat/src/directive-handler/Services/PrismaService.ts
packages/isla-chat/src/directive-handler/Services/RssService.ts
packages/isla-chat/src/directive-handler/Services/SpellCheckingService.ts
packages/isla-chat/src/directive-handler/Services/TwitterEmbedService.ts
packages/isla-chat/src/directive-handler/Services/UserService.ts
packages/isla-chat/src/directive-handler/SleepBypass.ts
packages/isla-chat/src/directive-handler/prisma.config.ts
src/Classes/Frontends/BaseFrontend.ts
src/Classes/Frontends/CLIFrontend.ts
src/Classes/Frontends/DiscordFrontend.ts
src/Classes/Frontends/HomeAssistantFrontend.ts
src/Classes/Frontends/HttpFrontend.ts
src/Classes/Frontends/JoinFrontend.ts
src/Classes/Frontends/MatrixFrontend.ts
src/Classes/Frontends/WebsocketFrontend.ts
src/Classes/Isla.ts
src/Classes/Utils/Join.ts
src/Classes/Utils/MatrixEvent.ts
src/Classes/Utils/moodToImage.ts
src/Classes/mood/MoodManager.ts
src/Classes/mood/Moods.ts
src/Commands/CanYouCommand.ts
src/Commands/MoodCommand.ts
src/Commands/ThanksCommand.ts
src/Commands/WakeUpCommand.ts
src/index.ts
tsconfig.json

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin microservices:microservices

git switch microservices

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master

git merge --no-ff microservices

git switch microservices

git rebase master

git switch master

git merge --ff-only microservices

git switch microservices

git rebase master

git switch master

git merge --no-ff microservices

git switch master

git merge --squash microservices

git switch master

git merge --ff-only microservices

git switch master

git merge microservices

git push origin master

Rows
Columns

microservices #2

Checkout

Merge