About Candifly
About Me
- BSc. in Computer Engineering from Bar-Ilan university
- 16 years of experience in software and product design, development and maintenance
- Delivered end to end SaaS solutions used by hundreds of thousands of users, including:
- Back-end planning and development with modern design including microservices and AWS cloud technology
- Planning and implementation of modular front-end using ReactJS
Background
I started Candifly in 2022 as a solution for a functionality that I was searching for – a simple widget that would allow me to easily display calendars on my short-term renting website, with feeds from platforms such as Airbnb and Booking.com.
Most online solutions were either expensive, complicated, or had clumsy UI.
I needed a simple product with nice and cool skins that would allow me to setup and get a simple HTML snippet that I could then paste on my web page to display the availability of my listings.
So I started playing with some open source projects, and noticed that without too much effort I could build this solution myself, and since I like coding, a simple solution that took a few hours became days, weeks, and months 🙂
Architecture
Candifly has many sub projects with different technologies, they can be divided into the following modules –
- Main API (user management, CMS) – REST API based on a classic LAMP bundle – PHP + MySQL over apache webserver hosted on AWS EC2 linux instances under a load balancer.
- Client Dashboard – ReactJS hosted on AWS CloudFront
- Calendar Runtime – Based on open source JS libraries wrapped by custom JS interface and CSS skins, hosted on CloudFront.
- Analytics – RESTful Microservices using AWS API Gateway, NodeJS Lambda functions and DynamoDB for storage.
- WordPress Plugin – Developed with PHP and JavaScript, distributed over WordPress SVN.
Authorization
- The authorization is administrated by the main API which serves as the identity provider (idP), using OAuth2.0 and JSON Web Tokens (JWT).
- For the microservices authorization I created a Lambda authorizer which controls the access to the API Gateway.
- I made the following diagram to depict the authorization process when accessing a microservice –
The application includes integration of 3rd party OAuth providers such as Google and Microsoft Azure, so users can sign-up and login using their Google and Outlook accounts respectively.
Analytics
- Analytics module is comprised of a set of microservices behind an API Gateway.
- Calendar Runtime instances that load on web pages collect and send event data such as Impression, Click, Scroll etc. that are recorded on DynamoDB dedicated tables.
- AWS EventBridge is used to trigger serverless aggregation process that transforms raw event data into analytics data that can be then displayed on the client dashboard.
- The client can view analytics information on the client dashboard for any of their calendars, viewing different scopes – from Today, Last week, and up to Last 12 months.
- Analytics dashboard also includes a live events graph that auto updates, counting impressions during last 30 minutes.
- Graphs are displayed using open source Chart.js library for React.
Caching
I designed Candifly with many caching layers to make it fast and avoid redundant requests on the main persistence.
Caching is used on the main two phases of the product –
- Configuration – Client dashboard
- Runtime – Serving of the calendars
For the configuration phase, the main data is persisted on MySQL RDBMS, but there are several caching layers on the way.
The following diagram depicts the flow when the client needs to fetch an object –
For the analytics microservice the caching is similar, only the main API is replaced by AWS API Gateway, and the persistence is DynamoDB.
During the Runtime phase caching is even more crucial –
Calendar Runtimes get event information from various sources, including events added manually by the owner, events imported from 3rd parties such as Google and Outlook, and also iCalendar live feeds which get updated constantly and have the potential to be the weakest link.
To solve the weakest link problem iCalendar feeds are cached in the main persistence.
In addition to the iCalendar caching, the entire events feed for each calendar is also cached in an in-memory Database (Redis is currently used, but Memcached is also supported).
Diagram that depicts the workflow for when a calendar requests its events feed during runtime –
On production the events caching seems to be yielding good results with low latency, where overall events feed requests average less than one second.
All static files of the project reside on AWS CloudFront CDN.
Calendar Runtime
The Calendar Runtime is the end product of the entire application.
After been configured and designed, the user get their HTML code snippet which they can paste anywhere on their website and the runtime will auto load itself into the placeholder.
A common calendar code snippet looks like this –
<div id=“CandiContXYZ”><script src=“https://app.candifly.com/calendar/XYZ/render”></script></div>
Loading sequence –
The Calendar Runtime is based on the open source library FullCalendar (GitHub ) which has been wrapped by code that customize its looks and behavior according to user configuration and a set of skins.
Event recurrence (repeat) is implemented using an open source library called rrule.js (GitHub ). The calendar supports the iCalendar RFC standard.WordPress Plugin
Since WordPress is still the internet’s most popular website builder, it was important for me to create a plugin that would help site owners manage and deploy their calendars, while at the same time will also give Candifly more exposure.
I learned how to develop WordPress Plugins and created a simple plugin that helps with the application on-boarding, managing, and also allows deploying your calendars with shortcode instead of HTML code snippet.
Example of a shortcode –[candifly id=“XYZ”]
The plugin is hosted and distributed using the WordPress SVN repository, and to date it has over 260 downloads.
Plugin page – https://wordpress.org/plugins/candifly/
Marketing and Social Media
- Marketing website that I created from a WordPress template (https://candifly.com ), including quick login / sign-up.
- Facebook and LinkedIn pages, where I published a couple of release updates.
- Maintain a Releases page with relevant new features.
Subscriptions and Payments
Candifly is a subscription based service, where anyone can sign up with a free subscription but can also upgrade to a paid subscription and get extra features –
- More calendars / events
- More monthly views (free subscription is limited)
- Less caching time on live feeds, meaning data is more updated
- Special calendar skins
- And more..
To manage the paid subscriptions I integrated with Stripe –
- Integrated their subscription and management forms into the client dashboard
- Implemented their subscription life-cycle using webhooks
- Actual payment is not active at the moment for bureaucratic reasons, however it’s ready to use
Next steps...
- Move all modules to microservice technology
- Add unit testing for client side (Jest? React Testing Library?)
- Use a deployment tool such as Jenkins to automate releases with standard process (build – test – deploy)
- Add publisher/subscriber messaging system such as Kafka or AWS SNS to automate and sync between distributed modules
i.e – calendar deleted -> remove all its assets, delete analytics data etc. - Better mobile support
- List with tons of new app features…