Although our target users mostly use big screen devices (at least 12 inches) we don't want to lose any user. Considering the cost/benefit we choose to support all screen sizes and implement a fluid design, real-time adaptive to viewport size changes.
We could have gone for Bootstrap but because we want the CSS bundle size to be as small as possible, we opt for creating a CSS file specifically for noodles.dev. Minimized Bootstrap file is 19kB while our custom .css file is almost half the size.
For interactivity on frontend we opted to use ReactJS mini-apps. This allowed to load the main ReactJS bundle only once while the individual mini-apps each have less than 30kB.
All static resources are served through a CDN service (Cloudflare) thus the initial resources loading times is considerably fast.
Whenever possible we are using Django inbuilt caching with Redis backend for serving content as fast as possible.
Processing full-text and aggregation queries would be very slow on SQL Databases, especially when searching through large amounts of data. PostgreSQL supports trigram indexing and is quite fast but is still not as powerful as Elasticsearch which is built specifically for fastest full text search. More on implementing Elasticsearch with PostgreSQL on the full text search section.
Processing full-text and aggregation queries would be very slow on SQL Databases, especially when searching through large amounts of data. PostgreSQL supports trigram indexing and is quite fast but is still not as powerful as Elasticsearch which is built specifically for fastest full text search.
Elasticsearch is a NoSQL database so data persistence is not as good as on using an SQL database. Noodles.dev uses a PostgreSQL instance for persisting all data but we want the searchable data to be passed on to the Elasticsearch instance running on AWS.
Through the clever usage of hooks to the django data models each time a resource is created,updated or deleted a background task is queued to synchronizes it to the Elasticsearch index. For queue management system we use the lightweight Huey python library.
Allowing users to easily authenticate makes for a pleasant user experience, especially when they can do so with just 1 click. Using an authentication library using OAuth2 specifications is both secure and easy to implement.
Noodles.dev uses allauth library for django. It supports a wide range of OAuth providers such as Facebook, Google, Github, Stackoverflow etc.
Because the main selling point of Noodles.dev is the "community curated list of learning resources" we needed a way for the registered users to edit any resource type. For this purpose a modular django package was created. It can easily make any django data model to be transformed into a community editable resource.
Any registered user can create an edit suggestion for a resource. After the edit suggestion is created, it can be voted by the other registered users. The edit can be published or rejected if a condition is met. In our project's case the condition is that the user should be either the resource owner, an user with a high positive score or a staff member.
If the edit is published, the edit owner receives a positive reward. More on that in the next section.
You can't have community creating or editing content without rewarding such behaviours somehow. Noodles.dev has a points/rewards system where each user has a positive and a negative score reflecting their actions.
We don't like waste resources but also hope that Noodles.dev will get millions of users. Until we become the next social network of developers unicorn app, we want to pay as little as possible while delivering the best experience.
While i'm sure that the current capabilities are enough for a long time from now, when we'll be approaching the limits of the current set up the first steps towards scaling up will be:
