As ChatKitty grows, more and more customers who have operations in Europe have reached out for service and support. So naturally, their most asked questions are about GDPR. And we always tell them; ChatKitty was developed with GDPR in mind. We are a GDPR compliant processor.

What is GDPR?​

The General Data Protection Regulation (GDPR) is a privacy and security law drafted and passed by the European Union (EU). It imposes obligations onto organizations anywhere, so long as they target or collect data related to people in the EU. This regulation was put into effect on May 25, 2018.

Using a chat SDK not only can shorten your development time, but also help you build a stable product and scale quickly. Before you instruct your team to start investing time adding all available features from ChatKitty, have you identified your product's purpose, and its primary use case?

Are you and your team considering adding chat to your product roadmap? Congratulations! You have made the right choice. As a product owner myself, I believe all excellent products eventually need to connect all users via a good chat experience. At this point, you probably have spoken to your developers about the options to make the chat happen. If you are looking at the ChatKitty website, you are probably thinking about using a chat SDK.

Using a chat SDK not only can shorten your development time, but also help you build a stable product and scale quickly. Before you instruct your team to start investing time adding all available features from ChatKitty, have you identified your product's purpose, and its primary use case?

You may be wondering why I am asking these questions. Many founders will tell you one of the hardest things before getting the blade and glory of developing a product is to plan out the features that need to be included in the road map.

Your developers and your users may have different expectations of what your product will accomplish. Before digging into it, simplify what the chat needs to accomplish and who the users are.

Here is a breakdown of all the features ChatKitty offers. You may be surprised by the variety of features right away, but we trimmed our offerings to provide our partners' essential features compared to our competitions on the market.

Reading this title, you are either wondering what Chat API is or what value it adds to your product. You are at the right place. These are the same questions; our team wondered while ago when we were developing our first app Howdi.

Let's be honest here for a second. We are too damn spoiled by big technology companies like Facebook and Google. We don't appreciate how much it takes to create a useful feature until we start to develop our product or use a new product from another Startup. Let's use chat as an example. When it comes to chatting, the golden standard you will think of right away, is maybe Facebook messenger, WhatsApp or Slack. After you use those apps for a while and start to use other products with the chat feature on the market, you will instantly feel something is lacking. Lagging, missing messages, notification error, you can name it.

As a project manager (PM), I can speak from personal experience. You are not wrong about feeling this way. When our team was developing our first app, we didn't consider the chat feature until in the later EPICS. Although we always know the chat will help us keep our users engaged and active, we didn't have time to plan out the feature. Because of the incorrect prioritization, our users could not connect right away and slowly drifted away after the launch. Luckily, we caught the mistake very early on, so we moved our focus on developing the best chat experience possible. When we launched chat in early 2020, we tripled our users and increased active users' numbers in a few months.

Having a discoverable API makes it easier for your users to understand and build mental models of your application. New data and relationships can be found without the user knowing of their existence. It also makes it easy to inline documentation with links to external documentation.

When designing Web APIs, many constraints and factors affect the decisions we make as software architects and developers. Some of these constraints are internal (like what tools and libraries are available within our tech stacks), and others external (like choosing a representational format easy for clients to consume, such as JSON). Regardless of the specific constraints facing each API designer, we almost universally want our Web APIs to be easy to use, flexible, and consistent. This article by Jordan Ambra does a great job of explaining these "golden rules" we all hope to follow as API designers.

The best Web APIs allow API users to use a service with minimum effort and knowledge of the system. Presenting the API user with only the information required to perform a task at hand, with links to related information that they may be interested in, allows for the user to focus on using your API to do what they need to do at the moment while having enough context to learn more about your API should the need arise. This scheme leads to APIs that are discoverable: API users can interact with your API from a single entry point in a way that requires little to no prior knowledge, and "discover" the rest of your API as needed.

Having a discoverable API makes it easier for your API users to understand, build mental models of your application and its data. New data and relationships can be found, even without the user knowing of their existence. It also makes it easy to inline documentation with links to external documentation. Client applications built on discoverable APIs have simplified logic since the responsibility of creating link URLs remains with your API, meaning as your API changes and evolves, it's easier to change your URL-structure without breaking client applications.

STOMP is a straightforward and easy to use open protocol that provides an interoperable text based format for message brokers and applications to communicate. STOMP allows real-time messaging components to share messages and communicate effectively.

To build real-time web applications you'll need full-duplex communication between a client application and a web server - having a message broker is also essential if you want reliability, and if you want to be able to handle messaging at scale. These different components have very different requirements and often share very little in terms of their tech stack, the programming languages they are written in, and the libraries they use. Despite these differences, the components involved in real-time messaging systems need to be able to send and receive messages agnostic of each component's tech stack in both directions. The WebSocket Protocol was introduced in 2011 to enable two-way communication between clients, and a remote host over a single TCP connection.

Since then, the WebSocket Protocol has become widespread, and it is supported across the web, both by browsers and mobile devices. The WebSocket Protocol although ubiquitous is a low level protocol functioning as a thin layer over TCP. The WebSocket Protocol upgrades a HTTP connection into a duplex connection and transforms a stream of bytes into a stream of messages without defining what those messages look like or how they're structured. With the WebSocket Protocol alone there isn't enough structure for real-time messaging components to route or process messages. This lack of structure makes the WebSocket Protocol by itself too low level for any serious application. Real-time messaging systems can take advantage of the wide support for WebSocket and provide structured messaging by using a WebSocket sub-protocol. The WebSocket Protocol allows itself to be extended by application-level messaging protocols that structure messages and provide additional information to messaging components.

TLDR - we need a simple messaging protocol we can use on top of the WebSocket protocol to allow our real-time messaging components to share messages and communicate effectively.