making a social network
Back in October I decided I wanted to create a proof of concept social network that I gave the working title meteor (more on what it actually is later), mostly for the practice and to have a project to motivate me to really learn the basics of web development. At the time, it seemed relatively daunting but achievable nonetheless, particular with the help of the handy dandy Communication as a Service provider, Layer. Sure enough, I had an initial version out in about 3 weeks, and that was with midterms and what not in the way. Layer and google authentication really made it a piece of cake. I used django as my framework, but really all I needed do to was serve up the pages using conversations I pulled from layer and deal with some basic user management with sqllite, but overall, it was super easy. Layer organized all messages into conversations, kept histories of who’d seen what, who was in what conversation, and all messages, and provided a super easy websockets API. I finally posted that version to github; it’s available here. As an initial project, the organization was terrible. I didn’t think through what should go where and added functions seemingly randomly; I was planning on reorganizing it before releasing it, but after I decided to scrap and restart I just left it. I kind of forget about the whole thing for a bit due to Thanksgiving/finals/etc. but I had/have a free week before going back to school, so I decided to polish it up and send it out into the world.
Only one problem — Layer had increased their prices. And boy did they increase them. When I created meteor on a whim, I used their free developmental plan, and my plan was to send out the network to the school, pay the at the time $25/month fee for the basic plan for one month, and see how I did. When I checked back on January 2nd, the price for a basic production plan was 600 dollars/month. Whelp. That was the end of me using layer.
The next week was spent researching. There are a LOT of similar services that provide communication etc. as a service. Some are good, most are not. I initially settled on quickblox for their low prices and robust services. Once I looked at implementing though, I realized that this was just not doable — their documentation was quite bad and their services were all over the place.
At this point, I decided perhaps looking for a full Layer replacement might not be feasible. I started looking at real time app APIs like pubnub and Pusher, but many were too expensive for a student like me. In this search, I found the perfect solution: Sinch. They ONLY provided real time instant messaging, not storing data or conversations or anything. But that was ok; I’d get to learn how to interact with postgresql. Two days later, I know I’ve made the right choice.
Having to create basically all but the real time aspect (admittedly one of the harder parts) from scratch has taught me a lot: each message must be saved as part of a distinct conversation, and because the app allows for fluid adding and dropping of users, a new request must be sent every message to check who’s part of which conversation. Which messages belong in which conversation must also be constantly checked. This leads to a lot of requests hitting the database: my plan for the next couple days (once I finish the app) is to begin aggressively caching everything to memcached just for good practice. Doing everything myself also allowed me to be far more flexible — I can add a tagging system and calendar program no problem right at the start.
Most of all though, this time around, my thoughts for the design of the app have been a lot more coherent and organized. I drew out all my thoughts and actually wrote design documents — I made a web app that only serves the webapp pages, a messaging app that deals with messaging, and an auth app that does all things authentication. So far it’s worked really well.