.svg)
We attended the Tricity Scala Users Group scala meetup recently where I did a short presentation about Codacy’s project structure and architecture. This blog post is a quick summary of the presentation I made at the meetup group. The slides are available here, or you can download them directly as a pdf here if you prefer.
I would like to thank Scalac and Sandra, our Developer Advocate, for the organization of the event. Patryk Jażdżewski also made a presentation about how to use Scala on Android with Scaloid. You can check his slides here.
In the first part of my presentation I talked about play framework at Codacy. Codacy’s website is a multi-layer play application composed by controllers, services, rules and models.
- The controllers handle the authentication and hide all the implementation complexity of different login providers (GitHub, Bitbucket, Google).
- The services are mainly responsible for the application security. All calls go through this layer and it verifies if the user has permission to access the intended resource. Since we use small independent methods, the controllers can use this to compose the view they want to display.
- The rules contains all the business logic necessary to read, modify or create resources
- The model layer manages the data persistence operations. We generalized some of the common methods in each database table in a single Scala trait. This reduces code duplication an allows us to have basic queries ready in newly created tables.
We published an open source project on GitHub which contains the base structure of our play application. It can be helpful if you want to create a new play application with a layered structure and several helper methods to handle authentication, security and database access.
The second part of the presentation was related to Codacy architecture and some of the challenges we found while scaling the application to analyse thousands of projects and commits every day.
Codacy started as a single application, but soon we realized that we needed to separate it in multiple projects in order to efficiently test and monitor each component.
To minimize duplicated code we created the Codacy-SBT project, which centralizes common settings and configurations across our projects: compiler settings, play application settings, docker settings, etc. All the external dependencies are now centralized in one place so in order to update a project’s dependencies we only needed to update the Codacy-SBT version.
We also created a private maven repository to solve internal project dependencies. Our build server stores a compiled .jar file in Amazon S3 and SBT just retrieves it when needed. Including the project source code directly in SBT was not viable due to the slow scala compilation time.
Finally, we are using docker together with Amazon Beanstalk to manage the deployment of Codacy. Using docker to run Codacy brings us some advantages: simple build and deploy scripts, isolation, integrated performance metrics, etc. With Amazon Beanstalk we are able to create staging and production environments using the same docker images. This way we can be sure that the same code that runs in production also runs in staging because it is the same image running with a different configuration. Beanstalk also provides us basic settings to scale the number of instances automatically when the demand increases.
Be sure to check the presentation slides for more information and contact me if you have any questions or comments.
Scala developer? Check out more Scala resources on our blog.
Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!
About Codacy
Codacy is used by thousands of developers to analyze billions of lines of code every day!
Getting started is easy – and free! Just use your GitHub, Bitbucket or Google account to sign up.
