\nThe Application consists of 3 separate Applications:<\/p>\n
- \n
- Chat Server: Allows Clients to connect to it, manages the Chat-Channels\/Users and relays messages sent from a client to the other clients in the same channel.<\/li>\n
- Chat Client: The Client consists of a GUI where the User can connect to the Server and chat with other Users.<\/li>\n
- Chat Backend Database: A simple Database which records and provides the chat history of a given Chat-Channel via REST.<\/li>\n<\/ul>\n
\nThe following Image describes the connections\/interactions between the different applications. These will be described in more detail later.<\/p>\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/StudyChat-300x231.png\")
<\/a><\/p>\nThe motivation behind this was that I always wanted to do a traditional Client-Server application and this Project was a good reason for it.
\nTo develop everything for the Cloud was an additional challenge since I had some experience with cloud based application but never really got into it.<\/p>\nIn the following paragraphs I will explain how these services were developed, what Problems arose and how IBM’s Bluemix performed.
\n(You can try out the client right here<\/a>.
\nIt should be working for at least another month of the time of this publishing, after that my trial runs out and I don’t know what’ll happen.)<\/p>\nDevelopment<\/h2>\n
Used Tools<\/h3>\n
All 3 applications were written in Java since I have the most experience with it and already knew some libraries I was going to use.
\nAs an IDE I used Eclipse<\/a>, as Build Tool I used Gradle<\/a>.
\nA great tool to check for additional flaws or erros I used SonarQube<\/a> for code analysis which also has a plugin(SonarLint) for Eclipse.
\nAs a Build tool I chose Gradle since it is a lot more flexible due to its programmable nature.
\nAnd since groovy is very close to Java it’s quite easy to work with.
\nI chose Git<\/a> as a Version Control System out of personal preference and experience.
\nThe Continuous Delivery Service of Bluemix supports Github Repositories which is an additional plus.<\/p>\nFirst Steps<\/h3>\n
When I first started developing on this project I started with the most important part, exchanging messages in a Server-Client structure.
\nNaivly I tried to use standard Java Sockets(java.net.Socket) which quickly failed for a reason:
\nWhen developing a Application in Bluemix usually only one single Port is open for use, which is mapped to the url of your application(in my case https:\/\/studychatclient.bluemix.net etc.).
\nIn my case the port defaulted to 8080 but others are possible.
\nSince each Java Socket connection needs its own port and I wanted\/needed multiple connections that option was qickly ruled out.
\nAfter that I tried to solve the issue by using REST calls, which worked ok at the time but obviously not fast enough.
\nOnly after a few weeks I found the oerfect(?) Solution for my problem: WebSockets.
\nWebSockets are based on TCP and work by sending an Upgrade request on an existing HTTP connection.
\nWhen this was succesful we have a full-duplex connection over an already used port and this isn’t limited to only one connection.
\nAfter this revelation I quickly searched for a fitting library and found org:java-websocket:Java-WebSocket(https:\/\/github.com\/TooTallNate\/Java-WebSocket<\/a>) which provides two classes, WebSocketServer and WebSocketClient, which can easily be extended.
\nAn empty WebSocketServer extended class looks something like this:<\/p>\npublic class Server extends WebSocketServer\n{\n public Server(final InetSocketAddress address)\n {\n super(address);\n }\n\n @Override\n public void onOpen(final WebSocket conn, final ClientHandshake handshake)\n {\n }\n\n @Override\n public void onClose(final WebSocket conn, final int code, final String reason, final boolean remote)\n {\n }\n\n @Override\n public void onMessage(final WebSocket conn, final String message)\n {\n }\n\n @Override\n public void onError(final WebSocket conn, final Exception ex)\n {\n }\n}<\/pre>\nThe Client looks the same except for the Constructor, which needs an URI instead of an InetSocketAddress.
\nFor actually connection to the Server there exists the “connect()” and “connectBlocking()” methods, with the first one being run in the background.
\nAdditionally the WebSocket objects received as paramters in these methods can be used to send messages, either as a String, byte array or ByteBuffer.
\nWith this solution it is very easy to send messages between server and client but for a chat application there needed to be a few more things done.<\/p>\nGraphical User Interface<\/h3>\n
A chat application needs a GUI to be used efficiently, chatting via a command line interface would be quite bad and very limiting.
\nI started looking into a HTML+Javascript combination but quickly stopped due to my aversion and limited experience of JavaScript.
\nBut then I remembered Vaadin<\/a>, which makes it possible to build web UIs in Java.
\nYou can try out their demos here<\/a>.
\nIt’s based on the “javax.servlet.annotation.WebServlet” interface and provides similar functionality to the JavaFX framework, which I was already familiar with.
\nI had quite a few problems with settings it up and running it correctly but after many tries I settled on this:<\/p>\n@Theme(\"valo\")\npublic class ChatUI extends UI\n{\n @WebServlet(name = \"ChatUIServlet\", asyncSupported = true)\n @VaadinServletConfiguration(ui = ChatUI.class, productionMode = false)\n public static class ChatUIServlet extends VaadinServlet\n {\n private static final long serialVersionUID = -6216866496615055637L;\n }\n\n private static final Logger LOGGER = LoggerFactory.getLogger(ChatUI.class);\n\n private static final long serialVersionUID = 903938514945760669L;\n\n @Override\n protected void init(final VaadinRequest request)\n {\n final ChatView chatView = new ChatView();\n\n this.setContent(chatView);\n this.setPollInterval(500);\n this.addDetachListener(event ->\n {\n ChatUI.LOGGER.info(\"Closing View!\");\n if (chatView.getClient() != null)\n {\n chatView.getClient().stopTimer();\n }\n });\n }\n}<\/pre>\nThe UI class, which I extended here, represents the top most component in the Vaadin component hierarchy.
\nFor every instance of the Chat Client openend in a Browser a ChatUI Object will be created.
\nAs its content I created a ChatView, as you can see in the “init” method, which contains all the buttons, textfields and similar(usually in further subclasses).
\nThere exists a Graphical Designer to design a Vaadin UI in a Drag-and-Drop fashion but it isn’t available for free so I had to do it all in Code which is unfortunate but not the end of the world.<\/p>\nServer<\/h3>\n
The Server has effectively two responsibilities:<\/p>\n
- \n
- Managing users<\/li>\n
- Managing channels<\/li>\n<\/ul>\n
Managing channels<\/h4>\n
Managing Channels contains relaying messages from one user to the rest of the channel and handling joining\/leaving of a user.<\/p>\n
Channel registry<\/h5>\n
I had the idea of a single channel registry which controls\/manages all channels.
\nOriginally I wanted to add the ability to create custom channels but left it out because of time reasons and so the channel registry is a pretty lightweight class.
\nIt has a list containing all channels, in this case 6 fixed channels. It allows to access them by name or to send a list of all channels to a user.
\nI made this class a singleton, since there should be only every one instance of it.<\/p>\nJoining\/Leaving<\/h5>\n
public boolean userJoin(final RemoteUser user)\n {\n LOGGER.debug(\"User {} wants to join Channel {}\", user.getName(), this.getName());\n if (this.userList.size() < this.maxUsers && !this.userList.contains(user))\n {\n this.userList.add(user);\n this.sendMessageToChannel(user, MessageType.CHANNEL_USER_CHANGE);\n this.sendHistoryToUser(user);\n return true;\n }\n return false;\n }<\/pre>\nWhen a User wants to join a channel, first the channel checks if the user can join and if so, notifies all other users that the user list has changed.
\nAfter that the chat history of that channel is retreived and sent to the new users client for display.<\/p>\npublic boolean userExit(final RemoteUser user)\n {\n LOGGER.debug(\"User {} wants to exit Channel {}\", user.getName(), this.getName());\n final boolean success = this.userList.remove(user);\n this.sendMessageToChannel(user, MessageType.CHANNEL_USER_CHANGE);\n return success;\n }<\/pre>\nA user leaving is almost the opposite, he\/she is removed from the list of users and another notification is sent so everyone else has the correct user list.
\nThe “sendHistoryToUser” method resolves to a relatively simple REST call which retreives the chat history and sends it to the user as a message.<\/p>\nRelaying messages<\/h5>\n
public void sendMessageToChannel(final RemoteUser sender, final Message message)\n {\n final String messageType = message.getType();\n LOGGER.debug(\"Sending message to channel {} with type {}\", this.getName(), messageType);\n Message msg = null;\n switch (messageType)\n {\n case MessageType.CHANNEL_USER_CHANGE:\n msg = MessageBuilder.buildUserChangeMessage(this.userList, this);\n break;\n case MessageType.CHANNEL_MESSAGE:\n msg = MessageBuilder.buildMessagePropagateAnswer(message.getMessage(), sender.getName());\n this.addMessageToHistory(msg);\n break;\n default:\n msg = new Message(\"{}\");\n LOGGER.error(\"Tried to send message to channel with unknown type: {}\", msg.getType());\n break;\n }\n for (final RemoteUser user : this.userList)\n {\n user.sendMessageToUser(msg.toJson());\n }\n LOGGER.debug(\"Message sent to channel {} with {} users, Content: {}\", this.name, this.userList.size(), message.toJson());\n }<\/pre>\nRelaying messages was pretty much a simple loop iterating over all joined users and sending them the given message.
\nIf it was of the type “CHANNEL_USER_CHANGE” it sends the whole list of currently joined users, if it was just “CHANNEL_MESSAGE” it sent the chat message around and uploaded it into the chat history.<\/p>\nManaging users<\/h4>\n
User registry<\/h5>\n
As with the channels I created a user registry, managing all users.
\nWhen a user wants to join the server, he\/she has to send the username they want to use while chatting.
\nSince every username should be unique to avoid confusions, already used usernames were rejected.
\nAdditionally I assigned every user a unique and positive ID of the “long” datatype to make identification easy.
\nOut of the name and ID I created user objects which were stored in a Map with the ID as key and the user object as value.
\nThen of course I created methods for accessing and removing users.<\/p>\nClient<\/h3>\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/client-1024x494.png\")
<\/a>
\nThe client has a relatively simple GUI and, as written above, was built with the Vaadin framework.
\nI won’t go into too much detail of how the GUI itself was built, it’s mainly sticking pre-built blocks together.<\/p>\nVaadin has several containers such as “GridLayout”, “VerticalLayout” or similar.
\nThose containers can be filled with controls such Textfields for inputting text, buttons for pressing, so called “ListSelects” for displaying a list and many more.
\nWhen you look at the screenshot above you can see many of them in action.
\nI used a GridLayout as the base and then tried to group the different parts together in sub-layouts, i.e. the user list on the right is a VerticalLayout containing a Label for the title and a ListSelect for the user list.
\nThis splitting of parts helps a lot since they can be worked on seperately.
\nThe more interesting part is the WebSocketClient although it’s very similar to the WebSocketServer.<\/p>\nDetecting disconnected clients<\/h4>\n
One interesting problem with Vaadin is detecting when a user\/client disconnects under abnormal instances.
\nWhen he disconnects via the WebSocketClient it’s all fine and good but how is it detected if he closes the tab or even the Browser.
\nThe answer is unfortunately not easy.
\nVaadin provides several ways to detect this but I haven’t found a reliable solution.
\nYou can add a “DetachListener” to the Client but I found this to be called only around 30% of the time when I was closing a tab or window.
\nI then built in a custom “Heartbeat”, basically a periodically updating timestamp for each user on the server.
\nEach period a message would be sent to the respective client and he would (not) answer it and when he would fail to do so, the server would disconnect him.
\nBut since the closing isn’t detected very reliably more often than not there would be ghost users, sometimes I would find myself with 6 other users while testing, all of them created by me earlier.<\/p>\nChat History Database<\/h3>\n
For the chat history service I chose to make it a REST based service with a NoSQL database attached.
\nMainly because I already knew how to work with REST APIs but never user a NoSQL database before.
\nIts service is also kind of detached from the server and client so if it fails at any point, the rest can still work.
\nIBM Bluemix provides such a database, namely the Cloudant NoSQL database, which I promptly connected with my application.
\nThis gives access to the database authentication via environment while running in the cloud.
\nCloudant also provides a nice library to use with this database.<\/p>\nI used SpringBoot <\/a>as the framework using a single controller with 3 methods:<\/p>\n
@RestController\n@RequestMapping(\"\/history\")\npublic class ResourceController\n{\n @PostMapping(\"\/channel\/{channelName}\")\n @ResponseStatus(HttpStatus.OK)\n public String addMessage(@RequestBody final String input, @PathVariable final String channelName)\n {\n final JsonObject jo = MessageDatabase.addChannelMessageToDB(channelName, input);\n return jo.toString();\n }\n\n @GetMapping(\"\/channel\/{channelName}\")\n @ResponseStatus(HttpStatus.OK)\n public String getChannelMessages(@PathVariable final String channelName)\n {\n return MessageDatabase.getMessageFromDB(channelName, new MessageList().getId());\n }\n\n @PostMapping(\"\/removeall\/{channelName}\")\n @ResponseStatus(HttpStatus.OK)\n public void removeDB(@PathVariable final String channelName)\n {\n MessageDatabase.removeDB(channelName);\n }\n}<\/pre>\nThe methods are pretty self explanatory except the removeall POST mapping, which is only in there for development purposes.<\/p>\n
The database has a very simple structure:
\nIt is split into 6 documents, matching the 6 chat channels.
\nEach of those document contain the list of all messages sent to that channel, with the username who sent it.
\nThese then can be requested per channel and will be sent as a JSON message containing the array of messages.<\/p>\nCustom Message protocol:<\/h3>\n
For the Server and Client to reliably exchange messages I created custom, standardized JSON messages.
\nTheir base structure looks like this:<\/p>\n{\n \"version\" : <versionNumber>,\n \"type\" : <messageType>,\n \"content\" : {\n <additional Content, depending on messageType>\n }\n}<\/pre>\nExplanation:<\/p>\n
The “version” field contains the Version of the chat protocol and serves to differentiate them, if there ever would be a conflict.
\nThe “type” field contains the type of the message, one of the following:<\/p>\n- \n
- USER_JOIN: A new Client wants to join a Server(not Channel)<\/li>\n
- USER_HEARTBEAT: Periodic message to check if the client is still running<\/li>\n
- CHANNEL_MESSAGE: A normal chat message to a channel<\/li>\n
- CHANNEL_JOIN: A Client connected to the Server wants to join a Chat Channel<\/li>\n
- ACK_CHANNEL_JOIN: Response to Client for succesful Channel join<\/li>\n
- CHANNEL_USER_CHANGE: Send to all Clients of a Channel whenever the Userlist of that channel changes, contains the list of clients connected to the channel<\/li>\n
- CHANNEL_CHANGE: Sends the currently available channels to a freshly connected client<\/li>\n
- CHANNEL_HISTORY: Contains the Chat history of a channel, which is sent to a client on a channel join<\/li>\n<\/ul>\n
Example:
\nThis would be a message sent from the Client to the Server, containing a chat “message” from a Client with a given “userID”.
\nWith this ID the Server can find the User, the channel he\/she is in and send the message to the rest of the users of this channel.<\/p>\n{\n \"version\" : 1,\n \"type\" : \"CHANNEL_MESSAGE\",\n \"content\" : {\n \"userID\" : 1234567890L,\n \"message\" : \"Hello World!\"\n }\n}<\/pre>\nIBM Bluemix<\/h2>\n
Right from the start of the project I wanted to use a continuous delivery pipeline to make developing and testing much easier and comfortable.
\nLuckily Bluemix had in-built support for this with a (mostly) easy setup:<\/p>\nWhen creating a Toolchain Bluemix provides several pre built templates to choose from. In this case the “Simple Cloud Foundry Toolchain” was sufficient.<\/p>\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/toolchain-schablone-1024x596.png\")
<\/a>This toolchain is based around a Github repository and even provides a Web based IDE.
\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/toolchain-1-1024x476.png\")
<\/a>The toolchain for the Server(and the other two apps) looked like this in the end.
\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/toolchain-overview.png\")
<\/a> I used the Github repository and configured the toolchain with it. This enabled me to use it as an input in the build steps.
\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/toolchain-githubconfig-1024x485.png\")
<\/a>I used the two pre-configured build Stages: “Build” and “Deploy”.
\nIn Build the unit tests are run and the application assembled while in Deploy the application is pushed to the cloud via the cloud foundry cli.
\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/toolchain-pipeline-1024x589.png\")
<\/a>Each stage consists of one or more Jobs. In case of the Build stage there was a “Test” job and a “Build” job. As the names imply, the Test job ran the unit tests and the Build job assembled the application, all via Gradle tasks.
\nIn case of the unit tests, Bluemix can display the result of the tests so you can see where something went wrong.
\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/toolchain-pipeline-job.png\")
<\/a>In the Input Tab I configured the Stage to use the Git repository as an Input and more importantly set it to run whenever something is pushed to the repository on Github.
\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/toolchain-pipeline-input.png\")
<\/a>
\nThe Deploy stage is very simple, it configures the different Cloud-Foundry Variables(Organization, Space, Application Name etc.) and executes the command “cf push $CF_APP”. Additional configuration was stored per project in the “manifest.yml”.
\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/toolchain-deploy.png\")
<\/a>
\nWhen the jobs of a stage have finished the next stage begins and runs its jobs and so forth.
\nThis whole process made testing the application very easy since all I needed to was develop something, push the changes and I could test them after 1 or 2 minutes live in the cloud.
\nBut not everything was great, the biggest problem was configuring a recent version of the JDK. As of this writing the standard version configured is the IBM JDK version 7 and I noticed this not until I tried to build a early version with Java 8 Lambdas. Then began the search on how to change to a Version 8 JDK, which took quite a while. I found the answer first on StackOverflow and later also in the official Documentation: Change the “JAVA_HOME” environment variable to $HOME\/java8 (“export JAVA_HOME=$HOME\/java8”).
\nOther Problems were with the UI of Bluemix itself but these were minor and some of them were solved over time.<\/p>\nMisc.<\/h2>\n
Github Repositories<\/h3>\n
Here the list of Github repositories used for this project.
\nCode quality and documentation could use some improvement but these were not intended for further development.
\nStill, if there are questions about the code, the best option would be to create an issue on Github.
\nhttps:\/\/github.com\/westerwave\/StudyChatServer<\/a>
\nhttps:\/\/github.com\/westerwave\/StudyChatClient<\/a>
\nhttps:\/\/github.com\/westerwave\/StudyChatBackend<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Introduction During the Lecture “Software Development for Cloud Computing” I decided to develop a Cloud based Chat Application with the help of IBM’s Bluemix. The Application consists of 3 separate Applications: Chat Server: Allows Clients to connect to it, manages the Chat-Channels\/Users and relays messages sent from a client to the other clients in the […]<\/p>\n","protected":false},"author":465,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1,120,650,22],"tags":[],"ppma_author":[734],"class_list":["post-2748","post","type-post","status-publish","format-standard","hentry","category-allgemein","category-cloud-technologies","category-scalable-systems","category-student-projects"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":21651,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/09\/18\/deploy-random-chat-application-on-aws-ec2-with-kubernetes\/","url_meta":{"origin":2748,"position":0},"title":"Deploying Random Chat Application on AWS EC2 with Kubernetes","author":"dv029","date":"18. September 2021","format":false,"excerpt":"1. Introduction For the examination of the lecture \u201cSoftware Development for Cloud Computing\u201d, I want to build a simple Random Chat Application. The idea of this application is based on the famous chat application called Omegle. Omegle is where people can meet random people in the world and can have\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/image-19.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":7125,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/08\/21\/evaluating-and-visualizing-statistical-bot-data\/","url_meta":{"origin":2748,"position":1},"title":"Evaluating and Visualizing Statistical Bot Data","author":"zc001","date":"21. August 2019","format":false,"excerpt":"STAB Website Homepage The idea Video game streaming has taken over a big part of the commercial video game scene with Twitch being its biggest platform. Viewers are able to communicate with other viewers and streamers through the chat, or watch their previous streams or highlights. These highlights are made\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/chart.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/chart.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/08\/chart.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":27618,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/02\/28\/crowdconnect-developing-a-scalable-live-chat-application-with-aws-cloud-services\/","url_meta":{"origin":2748,"position":2},"title":"CrowdConnect – Developing a Scalable Live Chat Application with AWS Cloud Services","author":"Jannik Scheider","date":"28. February 2025","format":false,"excerpt":"Imagine you're developing a live chat application in the cloud that needs to serve a growing number of users simultaneously and in real time across multiple chat rooms. Sounds like a challenge? It is. But with proven approaches and valuable insights from real-world experience, this task can be successfully and\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/image-14.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/image-14.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/image-14.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":22123,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/02\/21\/scaling-a-basic-chat\/","url_meta":{"origin":2748,"position":3},"title":"Scaling a Basic Chat","author":"Max Merz","date":"21. February 2022","format":false,"excerpt":"Authors: Max Merz \u2014 merzmax.de, @MrMaxMerzMartin Bock \u2014 martin-bock.com, @martbock The idea of this project was to create a simple chat application that would grow over time. As a result, there would be more and more clients that want to chat with each other, what might lead to problems in\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/sent-vs-received_test-3.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/sent-vs-received_test-3.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/sent-vs-received_test-3.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/sent-vs-received_test-3.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":22530,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/02\/28\/discord-monitoring-system-with-amplify-and-ec2\/","url_meta":{"origin":2748,"position":4},"title":"Discord Monitoring System with Amplify and EC2","author":"mk322","date":"28. February 2022","format":false,"excerpt":"Abstract Discord was once just a tool for gamers to communicate and socialize with each other, but since the pandemic started, discord gained a lot of popularity and is now used by so many other people, me included, who don't necessarily have any interest in video gaming. So after exploring\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/data-workflow.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/data-workflow.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/data-workflow.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":5175,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/02\/24\/benefiting-kubernetes-part-2-deploy-with-kubectl\/","url_meta":{"origin":2748,"position":5},"title":"Migrating to Kubernetes Part 2 – Deploy with kubectl","author":"Can Kattwinkel","date":"24. February 2019","format":false,"excerpt":"Written by: Pirmin Gersbacher, Can Kattwinkel, Mario Sallat Migrating from Bare Metal to Kubernetes The interest in software containers is a relatively new trend in the developers world. Classic VMs have not lost their right to exist within a world full of monoliths yet, but the trend is clearly towards\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=1050%2C600&ssl=1 3x"},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":734,"user_id":465,"is_guest":0,"slug":"jk165","display_name":"Jan-Niklas Keck","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/1b6e91d7fc2622ece8b3308cd055c09cb3292f8ae0424f9a9799472c8314918b?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/2748","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/465"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=2748"}],"version-history":[{"count":28,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/2748\/revisions"}],"predecessor-version":[{"id":24732,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/2748\/revisions\/24732"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=2748"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=2748"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=2748"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=2748"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}