Slack

Business Tools / Collaboration / Group Chat & Notifications
Lead Engineer at StackShare

We began our hosting journey, as many do, on Heroku because they make it easy to deploy your application and automate some of the routine tasks associated with deployments, etc. However, as our team grew and our product matured, our needs have outgrown Heroku. I will dive into the history and reasons for this in a future blog post.

We decided to migrate our infrastructure to Kubernetes running on Amazon EKS. Although Google Kubernetes Engine has a slightly more mature Kubernetes offering and is more user-friendly; we decided to go with EKS because we already using other AWS services (including a previous migration from Heroku Postgres to AWS RDS). We are still in the process of moving our main website workloads to EKS, however we have successfully migrate all our staging and testing PR apps to run in a staging cluster. We developed a Slack chatops application (also running in the cluster) which automates all the common tasks of spinning up and managing a production-like cluster for a pull request. This allows our engineering team to iterate quickly and safely test code in a full production environment. Helm plays a central role when deploying our staging apps into the cluster. We use CircleCI to build docker containers for each PR push, which are then published to Amazon EC2 Container Service (ECR). An upgrade-operator process watches the ECR repository for new containers and then uses Helm to rollout updates to the staging environments. All this happens automatically and makes it really easy for developers to get code onto servers quickly. The immutable and isolated nature of our staging environments means that we can do anything we want in that environment and quickly re-create or restore the environment to start over.

The next step in our journey is to migrate our production workloads to an EKS cluster and build out the CD workflows to get our containers promoted to that cluster after our QA testing is complete in our staging environments.

READ MORE
79.4K views
Needs advice
on
Slack
Discord
and
Gitter

From a StackShare Community member: 鈥淲e鈥檙e about to start a chat group for our open source project (over 5K stars on GitHub) so we can let our community collaborate more closely. The obvious choice would be Slack (k8s and a ton of major projects use it), but we鈥檝e seen Gitter (webpack uses it) for a lot of open source projects, Discord (Vue.js moved to them), and as of late I鈥檓 seeing Spectrum more and more often. Does anyone have experience with these or other alternatives? Is it even worth assessing all these options, or should we just go with Slack? Some things that are important to us: free, all the regular integrations (GitHub, Heroku, etc), mobile & desktop apps, and open source is of course a plus."

READ MORE
6 upvotes374K views
Replies (4)
Expert En Dveloppement Web Et Systmes Dinformations, Designer UX, UI, Co-grant at Wixiweb
Recommends
Discord
at

We use Discord to tracking some action and errors (logs / alerting / assertion). it's free and simple to use with mobile application et notifications

READ MORE
4 upvotes119.6K views
Head of HR at Rawnet
Recommends
Slack
at

We use Slack to increase productivity by simplifying communication and putting Slack in the middle of our communication workflow #Communications #Collaboration

READ MORE
4 upvotes42.3K views
View all (4)
Product Manager at StackShare

We are highly dependent on G Suite for all our collaboration and productivity needs, from Gmail and Calendar to Sheets and Docs. While it may not be as robust as Microsoft's offerings in those areas, it's totally cloud-based, we've never had any downtime issues and it integrates well with our other tools like Slack. We write and collaborate on all our specs/PRDs in Docs, share analyses via Sheets and handle our meetings via Calendar. #StackDecisionsLaunch #ProductivitySuite #Collaboration #DocumentCollaboration

READ MORE
11 upvotes1 comment124.6K views
Yaron Lavi
Yaron Lavi
April 21st 2020 at 7:31AM

All is correct but the Gmail client which is still horrible, and by no way compare to Outlook. Still, we have made the same decision - the client-less model was the key issue for us.

Reply

We're using GitHub for version control as it's an industry standard for version control and our team has plenty of experience using it. We also found many features such as issues and project help us organize. We also really liked the fact that it has the Actions CI platform built in because it allows us to keep more of our development in one place. We chose Slack as our main communication platform because it allows us to organize our communication streams into various channels for specific topics. Additionally, we really liked the integrations as they allow us to keep a lot of our in formation in one place rather than spread around many different apps.

READ MORE
27 upvotes1 comment124.5K views
Betty Hull
Betty Hull
February 19th 2020 at 1:40PM

Slack is really comfortable

Reply
CTO at My Job Glasses

We build a Slack app using the Bolt framework from slack https://api.slack.com/tools/bolt, a Node.js express app. It allows us to easily implement some administration features so we can easily communicate with our backend services, and we don't have to develop any frontend app since Slack block kit will do this for us. It can act as a Chatbot or handle message actions and custom slack flows for our employees.

This app is deployed as a microservice on Amazon EC2 Container Service with AWS Fargate. It uses very little memory (and money) and can communicate easily with our backend services. Slack is connected to this app through a ALB ( AWS Elastic Load Balancing (ELB) )

READ MORE
16 upvotes162.7K views
CEO at Scrayos UG (haftungsbeschr盲nkt)

We first used Slack and switched to Discord later to stay near at where the community is at, while still be able to have private conversations and stay in contact. Discord offered everything we needed and used from Slack previously, plus the community-part, so it was an easy decision.

READ MORE
1 upvote51.8K views
Shared insights
at
()

Repost

Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

READ MORE
18 upvotes2 comments338K views
John Akhilomen
John Akhilomen
April 1st 2020 at 3:00PM

I like the tech stack you guys have selected. You guys seem to have it all figured out, and well planned. Good luck!

Reply
Ne Labs
Ne Labs
March 9th 2020 at 12:34PM

RDBMS like Postgres can also store, index and query schemaless data as JSON fields, while also supporting relations where it makes sense. A document model is actually a downside, since usually data will still have relations, and it makes modeling them inconvenient.

Reply
Needs advice
on
Redis
and
RabbitMQ

Hello there, We're developing a team chat application which would consist of direct (one-to-one) conversations and channel (group) conversations. I'm not the developer (of course), but my team suggested to go with Redis.

I've seen tech stacks of BIG team chat applications like Slack and Flock...but they haven't used RabbitMQ and used Redis instead.

A quick question, what's a good choice to go with for RabbitMQ or Redis for a message queue system in our case?

READ MORE
8 upvotes36.7K views
Replies (2)
Recommends
RabbitMQ

This is of course determined by the needs of your application. It is important how many of your estimated instant users in your application will be. Also, the features of the application will affect the architecture of the application. For example, if the message data would be processed on the server, I would prefer a distributed server solution such as akka actor with the rabbitmq cluster. I would definitely use Redis. Both technologies are incomparable lanes. Redis is a database and its purpose is to process data from a different memory with the memory used by the code running on the server. Rabbit is a messaging queue system. It contributes to the architecture in a different dimension. Performance and stability are keywords.

READ MORE
8 upvotes1 comment8.4K views
Slava Lovkiy
Slava Lovkiy
April 23rd 2020 at 6:01AM

I'm curious to find out why many people decide to compare seemingly disparate technologies such Redis and RabbitMQ? Is there some sort of esoteric ninja trickery behind this?

Reply
Lead Senior Software Engineer at InTouch Technology
Recommends
RabbitMQ

Each tool supports different use cases. RabbitMQ is a middleware peace supporting message driven reqs like you are trying to accomplish and Redis, on the other hand, allows to store data if performance, cache is important. If we are taking about a message queue system approach you could use RabbitMQ, Amazon SNS/SQS or Apache Kafka

READ MORE
3 upvotes8.4K views

Server side

We decided to use Python for our backend because it is one of the industry standard languages for data analysis and machine learning. It also has a lot of support due to its large user base.

  • Web Server: We chose Flask because we want to keep our machine learning / data analysis and the web server in the same language. Flask is easy to use and we all have experience with it. Postman will be used for creating and testing APIs due to its convenience.

  • Machine Learning: We decided to go with PyTorch for machine learning since it is one of the most popular libraries. It is also known to have an easier learning curve than other popular libraries such as Tensorflow. This is important because our team lacks ML experience and learning the tool as fast as possible would increase productivity.

  • Data Analysis: Some common Python libraries will be used to analyze our data. These include NumPy, Pandas , and matplotlib. These tools combined will help us learn the properties and characteristics of our data. Jupyter notebook will be used to help organize the data analysis process, and improve the code readability.

Client side

  • UI: We decided to use React for the UI because it helps organize the data and variables of the application into components, making it very convenient to maintain our dashboard. Since React is one of the most popular front end frameworks right now, there will be a lot of support for it as well as a lot of potential new hires that are familiar with the framework. CSS 3 and HTML5 will be used for the basic styling and structure of the web app, as they are the most widely used front end languages.

  • State Management: We decided to use Redux to manage the state of the application since it works naturally to React. Our team also already has experience working with Redux which gave it a slight edge over the other state management libraries.

  • Data Visualization: We decided to use the React-based library Victory to visualize the data. They have very user friendly documentation on their official website which we find easy to learn from.

Cache

  • Caching: We decided between Redis and memcached because they are two of the most popular open-source cache engines. We ultimately decided to use Redis to improve our web app performance mainly due to the extra functionalities it provides such as fine-tuning cache contents and durability.

Database

  • Database: We decided to use a NoSQL database over a relational database because of its flexibility from not having a predefined schema. The user behavior analytics has to be flexible since the data we plan to store may change frequently. We decided on MongoDB because it is lightweight and we can easily host the database with MongoDB Atlas . Everyone on our team also has experience working with MongoDB.

Infrastructure

  • Deployment: We decided to use Heroku over AWS, Azure, Google Cloud because it is free. Although there are advantages to the other cloud services, Heroku makes the most sense to our team because our primary goal is to build an MVP.

Other Tools

  • Communication Slack will be used as the primary source of communication. It provides all the features needed for basic discussions. In terms of more interactive meetings, Zoom will be used for its video calls and screen sharing capabilities.

  • Source Control The project will be stored on GitHub and all code changes will be done though pull requests. This will help us keep the codebase clean and make it easy to revert changes when we need to.

READ MORE
13 upvotes147.2K views