Hello, I am Kobayashi, CTO of Jicoo.
Jicoo is a service that automates tasks and operations related to scheduling and booking in your daily work, and promotes the creation of valuable time by reducing the time spent on coordination tasks.
We have decided to publish technical information as a blog in order to make people interested in how Jicoo is made as of July 2022. I will introduce the technology and services we use as the first article, and after that I will write in-depth information on the topics of scheduling and booking.
So this article will introduce the architecture and technology stack behind Jicoo.
Overall Architecture
Jicoo uses GCP as its infrastructure, and the rough overall picture is shown in the figure below. The system is based around Cloud Run, a fully managed serverless platform. ! Overall System Architecture
Concept
All processing is centralized in Cloud Run
APIs are called by users, Cloud Scheduler, Cloud Tasks, and external service webhooks, but by having Cloud Run perform all processing, the data flow is centralized and simplified.
As the service expands in the future, it will become necessary to perform processing outside of HTTP, but for now, this is sufficient, and it is very easy because it costs almost nothing to manage.
Common language: TypeScript
All code is based on TypeScript. (Swift is used for some iOS applications).
Engineers who can write TypeScript can write FE, BE, Mac apps (Electron), iOS apps and Android apps ([PWA](https://developer.mozilla.org We aim to create an environment where engineers who can write FE, BE, Mac apps (Electron), iOS apps, and Android apps (PWA) can all be modified, allowing for fast development and easy cross-border development where front end engineers can do BE development.
We aim to create an environment that facilitates cross-border development by allowing front-end engineers to develop BEs.
Technologies supporting each area
App(SSR)
The instance that receives requests uses the SSR function of Next.js, which is a rather common configuration these days. The infrastructure is server-less using Cloud Run, so the operational load is almost zero. The system automatically scales in late at night when access is low and scales out during the day, optimizing costs.
We originally used GAE flexible, but the infrastructure cost of the sandbox environment was an issue because we needed to run at least one instance. Since last November, when we adopted Cloud Run, we have been able to reduce the cost of the sandbox environment by nearly 50% because we can now operate without being billed for zero instances when the development environment is not in use.
App (API)
REST is used instead of GraphQL because the service does not have a large number of unspecified API users. Various APIs are defined in API Routes of Next.js.
The type of API is defined as interface and can be referenced by both BE and FE.
FE
The web app framework uses Next.js, so React is used, and components are divided and managed based on Atomic Design. CSS definitions are Emotion, which can be changed by any engineer or designer.
The Mac app is implemented with Electron and webview, and the iOS app is a hybrid of Swift and webview. The Android application is implemented using PWA, so the code is basically the same as the web. Although we offer a wide variety of devices, we are able to provide almost a single code base for all of them, so we are able to respond quickly to multi-device development.
Batch
This is an instance that performs batch processing, such as the delivery of bulk mail. The execution time is defined in cron format in Cloud Scheduler, and Cloud Run takes care of the execution itself.
Currently, we have no particular complaints, but we plan to migrate to Cloud Run Jobs when it becomes GA.
Job Queue
Costly external API executions such as sending emails and creating ZoomURLs are offloaded to Job Queue for faster response instead of being executed by the API's online transaction processing. Cloud Tasks.
The execution also hits the Cloud Run endpoint, and each job is kept as small as possible so that data inconsistencies do not occur even if retries occur.
Originally, we were using npm's bull package to run Job Queue on Redis, but the default package does not have a job management screen, and it was troublesome to run retries. However, the default version had no job management screen and it was troublesome to execute retries, and the cost of recovery when a Redis failure occurred was too high, so we migrated to Cloud Tasks. It has been about 2 months since we migrated to Cloud Tasks, and we have had no major problems and have been able to greatly reduce our operating costs.
Search
We use algolia for search because GCP does not have a product for search. It is a SaaS that provides search services based on REST API, and I personally find it easier to use than Elasticsearch. If there are multiple sorting conditions, it is necessary to create a replica for each index, which is expensive and makes it difficult to choose a service to use.
Headless CMS
We use contentful as a CMS.
Jicoo has many static pages such as case studies, and we are calling contentful's API as a reference for the submitted data. We use getStaticProps to generate several hundred files at build time and Incremental Static Regeneration to optimize the trade-off between page loading speed and deployment speed. We are trying to optimize by looking at the trade-off between page loading speed and deployment speed.
We are optimizing by looking at the trade-off between page loading speed and deployment speed.
CI/CD
We use GCP Cloud Build and Github Actions for CI/CD.
Automated test execution
When a pull request is made, TypeScript is compiled and automated tests written in jest are executed, and if they are not successful, they cannot be merged to master.
Deployment
When a Pull Request is merged to master, Cloud Build is executed to deploy to Cloud Run in the production environment.
Monitoring
DataDog is used for service monitoring, NewRelic for RPM, and Sentry for error monitoring.
Summary
It has been a year since the official release of the service, and as the product has grown, some problems have occurred, and the current Cloud Run-centric configuration has been adopted. We would like to continue to operate the service while introducing changes that will contribute to further growth of the service.
---We will continue to make changes that will contribute to the growth of the service.
We are looking for members who can develop together with us!
Jicoo is actively recruiting engineers, so if you are interested in an environment where we actively invest in new technology, or if you want to work hard from the planning stage, please apply now!
If you are interested in working with us as an engineer, please check here. Please check here if you are interested in working with us as an engineer. https://www.jicoo.com/en/careers
