Codesign.io – architecture that works
Hello, guys. My name is Paul, I am a co-founder of service Codesign and the answer for its technical component. Codesign is a web service for the creation and review of feedback when working on web sites, design layouts and presentations. If you, designers continue to write edits on the layout of continuous text in the letter, then it is time to quit and go to Codesign.
We launched the service on July 22, 2015 and has since gained 3500 registered users, experienced the launch on ProductHunt when we went to 10,000 for 36 hours, received its first paying users and discuss obtaining funds from the European (I live in Italy) investors. In this article I will explain how we built a service architecture and organized development process.
the
In developing Codesign, we sought to modularity, arguing that in this case it will be easier to make changes and replace one block by another. The first major decision was the complete separation of API and web applications so that they work on different servers. As the team has had experience with Python / Django, it was decided to build an API based on Django Rest Framework. The web application we had originally planned to write on AngularJS, but hired front-end developer convinced us to implement the React. Server-side web application implemented using the framework Express Node.js.
the
For the reason that we wanted as little time as possible to spend on the server configuration, and be able quickly to scale (if we expect a large jump in traffic after posting on the popular online), we decided to deploy our code on Heroku. Thus on Heroku we have 2 servers for the API (production / development) and 2 servers for the web application (production / development). In the Heroku free rate server goes to sleep every hour and needs not be active for more than 6 hours a day. I had a few servers raised a few months before the new tariffs and this limitation. Web application and API work on free servers, we periodically scale, when the expected influx of traffic. The main advantage of Heroku I think the ease of deployment and its GIT the Foundation that enables you to automatically deplot code from Github. This process is described in more detail below.
the
Heroku there are a large number of different plug-ins, among which there is also a database management system (DBMS). Before the release of the 22nd of July we had a prototype using MySQL and we decided to continue to work within this database and connected ClearDB. Free rate has a database limit to 5MB, thus we first moved to the rate Punch and then Drift for $50 per month. ClearDB is now the most expensive part of the technology services (expensive only Intercom, but I'm not talking about him in this article) for which we pay. I thought that $50 a month it is expensive and believed that the Amazon RDS I get better performance for the same money. After several experiments, I realized that this is not so for the same speed of execution of queries I received only on RDS instances that can cost more than $50, so we are left with ClearDB.
the
Based Codesign are graphic files that users download for further discussion. Here we conducted long discussions and stopped at the Amazon S3, where with our traffic and number of stored pictures we pay $3-4 per month. On slow Internet downloading pictures over 4MB took more than 30 seconds, and there were timeout error from Heroku. To solve this problem, we started on the server just to generate a special link that you can to upload images directly to Amazon S3 from a browser. So the problem was solved.
the
When one user has made changes to the Board (a collection of images for discussion) on Codesign, and other members of this Board receive notification. To implement these notifications, we use two services: Heroku task scheduler to initialize the sending of notifications every hour, and Mandrill to send emails as such.
the
Django itself allows you to send reports about the 500 error occur on the server. It is convenient. But even more convenient was the service Opbeat. It collects information on errors, shows the statistics of their occurrence, each group assigns error to the person who commits code that exhibits this error. In addition Opbeat monitors the requests to the server and shows bottlenecks with performance. There are accounting services, but Opbeat bribed its simplicity and free up to 3 users. We had a problem with the fact that the endpoint for getting a list of Burgundy in the folder is executed 4 seconds. We could not understand what exactly the problem is. Opbeat has shown that we do very suboptimal queries to check user rights. We have optimized the code and execution endpointа accelerated in 20 times.
the
Our development at the moment is completely built on GIT:
the
Next, we plan to introduce the following tools:
the
the
This article is an example of how various third-party services can be integrated to simplify the work with its own product. To the architecture that you see in this article, we did not come immediately, but gradually – by trial and error. We do not claim and are not agitating that this architecture is ideal. We are open for discussion and we would love to hear feedback on the architecture that we use.
If you like Codesign (or don't like and you want to change it), come to work for us — we are open 4 remote jobs.
Article based on information from habrahabr.ru
We launched the service on July 22, 2015 and has since gained 3500 registered users, experienced the launch on ProductHunt when we went to 10,000 for 36 hours, received its first paying users and discuss obtaining funds from the European (I live in Italy) investors. In this article I will explain how we built a service architecture and organized development process.
the
Frameworks
In developing Codesign, we sought to modularity, arguing that in this case it will be easier to make changes and replace one block by another. The first major decision was the complete separation of API and web applications so that they work on different servers. As the team has had experience with Python / Django, it was decided to build an API based on Django Rest Framework. The web application we had originally planned to write on AngularJS, but hired front-end developer convinced us to implement the React. Server-side web application implemented using the framework Express Node.js.
the
Deployment
For the reason that we wanted as little time as possible to spend on the server configuration, and be able quickly to scale (if we expect a large jump in traffic after posting on the popular online), we decided to deploy our code on Heroku. Thus on Heroku we have 2 servers for the API (production / development) and 2 servers for the web application (production / development). In the Heroku free rate server goes to sleep every hour and needs not be active for more than 6 hours a day. I had a few servers raised a few months before the new tariffs and this limitation. Web application and API work on free servers, we periodically scale, when the expected influx of traffic. The main advantage of Heroku I think the ease of deployment and its GIT the Foundation that enables you to automatically deplot code from Github. This process is described in more detail below.
the
Database
Heroku there are a large number of different plug-ins, among which there is also a database management system (DBMS). Before the release of the 22nd of July we had a prototype using MySQL and we decided to continue to work within this database and connected ClearDB. Free rate has a database limit to 5MB, thus we first moved to the rate Punch and then Drift for $50 per month. ClearDB is now the most expensive part of the technology services (expensive only Intercom, but I'm not talking about him in this article) for which we pay. I thought that $50 a month it is expensive and believed that the Amazon RDS I get better performance for the same money. After several experiments, I realized that this is not so for the same speed of execution of queries I received only on RDS instances that can cost more than $50, so we are left with ClearDB.
the
Storage
Based Codesign are graphic files that users download for further discussion. Here we conducted long discussions and stopped at the Amazon S3, where with our traffic and number of stored pictures we pay $3-4 per month. On slow Internet downloading pictures over 4MB took more than 30 seconds, and there were timeout error from Heroku. To solve this problem, we started on the server just to generate a special link that you can to upload images directly to Amazon S3 from a browser. So the problem was solved.
the
Notifications
When one user has made changes to the Board (a collection of images for discussion) on Codesign, and other members of this Board receive notification. To implement these notifications, we use two services: Heroku task scheduler to initialize the sending of notifications every hour, and Mandrill to send emails as such.
the
Monitoring
Django itself allows you to send reports about the 500 error occur on the server. It is convenient. But even more convenient was the service Opbeat. It collects information on errors, shows the statistics of their occurrence, each group assigns error to the person who commits code that exhibits this error. In addition Opbeat monitors the requests to the server and shows bottlenecks with performance. There are accounting services, but Opbeat bribed its simplicity and free up to 3 users. We had a problem with the fact that the endpoint for getting a list of Burgundy in the folder is executed 4 seconds. We could not understand what exactly the problem is. Opbeat has shown that we do very suboptimal queries to check user rights. We have optimized the code and execution endpointа accelerated in 20 times.
the
Development
Our development at the moment is completely built on GIT:
-
the
- First, the developer makes the changes and uploads the code to the development branch Github. In the master branch at Github to push code directly is impossible, it is forbidden in the repository settings. the
- At this point webhook is triggered and the code repository pereraspredelyatsya development server on Heroku. the
- Making sure that code works properly, we create a pull request to master branch, when making code which is automatically sent to a production server Heroku. If something went wrong and was found by some mistake, Heroku makes it very easy to do rollbacks to previous versions.
the
the Future
Next, we plan to introduce the following tools:
the
-
the
- Heroku apps review – for testing different features separately following the git flow (now we only have one development server) the
- Travis – to run unit tests each time you push to Github the
- CodeClimate for automatic code analysis (will lead to high code quality) the
- Amazon RDS – when we fall short of rates offered by ClearDB will need to deploy more powerful RDS instances the
- Firebase – to implement real time updates. the
- Stripe to receive payments (now used Gumroad)
the
Conclusion
This article is an example of how various third-party services can be integrated to simplify the work with its own product. To the architecture that you see in this article, we did not come immediately, but gradually – by trial and error. We do not claim and are not agitating that this architecture is ideal. We are open for discussion and we would love to hear feedback on the architecture that we use.
If you like Codesign (or don't like and you want to change it), come to work for us — we are open 4 remote jobs.
Комментарии
Отправить комментарий