← Back

Quid Sentio Blog

Building a shareable personal journal alone using React, Netlify, S3, and FaunaDB

Quid Sentio is a shareable personal journal.
Learn more about us and follow us on Twitter.

I have wanted to build a social network for 8 years, but it was much harder to make software for the web back then. Also, 8 years ago, I was not even a software developer yet, so there is that. But now I am (thanks freeCodeCamp.org!), and we are living in the easiest time to be a software developer since Jeff Goldblum uploaded a virus to an alien mothership.

Quid Sentio

The time was kind to my idea of what a social network should be too. It aged well, and now it's time to uncork it. I am building Quid Sentio, a shareable personal journal. I am not calling it a social network site, but it is. Well, it will be. It's just the basics now but open in public beta in the hopes someone will care.

What I am building now is much more mature than what I envisioned back then. The core idea is the same -- keeping in touch with real friends, the closest friends and family-- but the foundation is much more robust these days. In the meantime, Path has come and gone, people saying they have quit Facebook have come and gone, data leaks and privacy abuses have come and stayed.

I want to build Quid Sentio upon the principle of privacy. Privacy as freedom from being observed. From being observed by non-friends, from being observed by companies, from being observed by people who bought your data in the deep web after a database leak.

The first two are just consequences of design and business choices. Adding a little bit of friction for adding friends -- so no one can spam-add all their contact list; keeping shared posts visible only by your direct friends -- so no virality or friends of friends stalking you. A subscription-based business model -- so no ads, no invasive tracking. The third level of privacy is not that simple.

Cybersecurity is one thing that gets harder and harder to do in software development. At the same time, services that do it better than me are more accessible. This is the first reason why I decided to build my project using other people's infrastructure.

The second reason is that I want to limit how many things I have to juggle in my mind while building it. I read in Sapiens that the Cognitive Revolution started 70,000 years ago. I am pretty sure it ended when I made 40. Some things look attractive from afar, but I can pass without them, and I am happy enough just hearing people talking about it. Things that fall into that bucket are Finnegans Wake, EVE Online, Dwarf Fortress, and Vim. Other things I cannot pass by without, and I have no idea how to do it myself.

The inevitable implication is that I had to find other people to do my job for me. I wanted to focus on building the UI, creating the application logic, designing the experience that would make my product unique. Not the devops, not the infra, not the data plumbing, none of those solved problems. I found people that do these better than I could possibly ever do in Netlify and FaunaDB. There is also other software taken for granted that are worthy, but not newsworthy at this point. Like Stripe, AWS S3, and the plethora of open-source software that are the buried giants whose shoulders I am standing on while pretending to be in a mountain that I climbed all by myself.

Economics teaches you about comparative advantage. People in those companies have the advantage of being smart; I have the advantage of using their service's free tiers. Not sure I got that economics thing right.

The defining technical characteristic of my application is using good things with bad names. I built it on a serverless architecture, which is the same as calling food delivery "kitchenless food". I am using JAMstack, which is an acronym for static websites or dynamic web apps using a stack with Javascript, APIs and markup language but not like all those other websites and web apps that also use Javascript, APIs and markup language in a totally different way. I would be much happier calling serverless architecture, “Boaty”, and JAMstack, “McBoatface”.

Still, just like Panama hats from Ecuador, they are great things. They are powerful ideas, implemented, and popularized by great companies that I am using to build mine.

Netlify Build and Netlify Functions

Netlify is famous for how simple and intuitive it is to create static sites that have hosting, continuous deployment, and CDN without any hassle. With Netlify Functions, I can go one step further; I can make my React site a dynamic application using APIs. Their serverless Functions make creating an API a breeze; I drop a javascript function in a folder, deploy, and I have an API.

Serverless is great for its smaller upfront costs (for low traffic, you are usually still in free tier range) and zero infrastructure management needs. Pay-as-you-go is a risk if you go too fast, but that’s not something I am expecting. With Netlify Functions encapsulating the not that simple AWS Lambda Functions, it has the extra bonus of keeping me away from the AWS Management Console interface.

I have a fast CRUD app deployed in my domain, with minimal cognitive overhead.


FaunaDB is a distributed NoSQL database that is very well suited to plug into serverless applications. NoSQL, with its flexible schema, is a blessing for building new projects that will change a lot and quickly. I am not building a typical social network; I am implementing original ideas that might or might not work, that have changed and will continue to change as my own ideas evolve and I get users' feedback. The data structure will reflect that. I am a Javascript developer; I like how javascript notates its objects; it is easier for me to understand and change a JSON object. It is also the obvious solution for going serverless.

I have a safe, reliable, and fast database, with minimal cognitive overhead.

update: In the first version of this post I was using Userbase as authentication solution. Since then, I decided to concentrate more on FaunaDB tech, including their built-in user authentication.

Putting everything to work

Quid Sentio core entity is the journal entry. An entry can contain text, audio recorded by the user, an image, a mood number selected from a range from -100 to 100, and custom tags. Each entry can also be shared and commented by friends. This data looks like this for the user:

Text entry screenshot Audio entry screenshot Image entry screenshot Mood entry screenshot Tags entry screenshot Sharing entry screenshot Commenting entry screenshot

The entry data is pretty suitable for a JSON structure, as I have to fit all of these, with its inherent grouping, in one database item. Images and audios are stored at AWS S3, their URLs are stored at the database item too.

Another advantage is that I can -- and I will -- add more types of content that the user can add to an entry. Audio, image, and custom tags were all added after I launched the alpha version. I still consider video, maybe stickers, or other more creative inputs that I learn from my users. The flexibility of adding more properties to an entry while keeping it backward-compatible comes much more naturally to NoSQL.

Quid Sentio is also social. The user creates an entry in their journal and can then choose with whom, among their friends, they want to share it and allow to comment on it. The user will also view all of their friends’ entries that were shared with them. Each entry contains its permissions of access and list of comments.

I keep the user’s list of friends as one of the profile properties that I keep in a "Users" collection in FaunaDB. After user authentication I can access it and then I can keep it in the state of my application. It is basically a list of userIds, so no big deal. The tricky thing is to make the request that returns only the entries from those friends who are authorized to be seen by the user.

This is where FQL shines. FQL is FaunaDB’s own query language, but I could use GraphQL (also supported by FaunaDB) with similar results. I can easily create a query from a Netlify Function that only brings the authorized entries without the need of writing a lot of code with the logic required to not expose unauthorized entries to the client. So it ends up being pretty fast and simple to get the user’s friends’ entries and show this:

Text entry screenshot


I had many technical obstacles between me and the social network that I wanted to build. Then modern services started to arrive, one by one, and, with more ease than expected, I got it done. I create-react-apped an app, deployed with Netlify, wrote Netlify functions for the basic operations, integrated with Fauna's NoSQL serverless database, including its built-in user authentication, inserted a Stripe handled checkout page and voilà. The only thing in front of me now is my vision. And I have all my cognitive resources preserved to reach it. Or to be consumed trying to write smart comments on Hacker News. Only time will tell.

Sign up to Quid Sentio if you want to journal your life and share it with the ones you trust.

Follow on Twitter for updates.