Tech Stack, Scaling, and Security

The bread is in the oven, and I’m moving into the meat of the product — the technology.

Technology

I’ve already preconceived this project as a ReactJS and MeteorJS product, so that part is done. The combination allows fun reactive moments, especially in word wars, public writing, or leader boards, as they would all be in real time. Both are known to be very quick to develop in, and I have some basic knowledge of both and can probably kludge together a prototype in the coming two months.

  • ReactJS
  • MeteorJS
  • MongoDB
  • SASS
  • DraftJS (for more advanced editing features)

Scaling & MongoDB

The only unknown factor is the ability of MongoDB to keep up. I know that my database schema will be fairly flat, but I’m not sure how well I can scale up to word wars and more complicated I/O operations later on. If somehow lots of users catch onto the app, MongoDB might start buckling at the knees (I really don’t want a Pokemon Go affair here, where their servers crashed pretty often as millions of users tried to play simultaneously. I’m not saying I will get millions of users, but it would seem both a blessing and a curse.

  • Database rate limiting
  • Max user limiting — either concurrent users or user signups, as a safeguard against too many users
  • Never lose someone’s work use local storage or mini mongo caching to make sure that someone’s work is never lost if they break connection, or their computer shuts down

Security

I’ve heard that Meteor can easily be configured to be insecure, that in and of itself it’s not an unsafe platform, but can be very easily be written to be unsafe (poor allow/deny rules, passing user IDs back and forth, not checking data, etc.), so I will need to make security a top priority, as I can imagine having to go back and rewrite the app to be more secure a certain flavor of nightmare.

  • Captcha for new signups? Maybe shouldn’t implement this unless it becomes a problem.
  • Strict allow/deny rules
  • Strict no sending Meteor UserID between client and server. UserID should stay secret
  • Usernames are used as public ID
  • Use mailgun for standard user account

Privacy

Writing is a highly private endeavor for most people (including myself). In addition to security concerns, I need to make sure that any content that needs to be private stays private only for the author

  • Encrypt user novels for extra security, unless they’re published or marked for sharing — stretch goal for Phase 1. Also note that encryption will make debugging and helping out authors with problems a lot harder
  • Use SSL? Maybe for the second phase, as it might be expensive

Cost

The thing no one wants to talk about. I would much rather like NovelMonkey to reach as many people as I can, and to grant all the fledgling NaNoWriMo writers a chance at the feeling at the end of reaching those 50,000 words. I would also like NovelMonkey to just exist as a resource for anyone who wants to get into writing to get started. NovelMonkey should prod them in the right direction, to get into the right headspace.

However, I would rather not lose money on something like this, especially since I’m giving up two months time I could be spending actually earning an income. I would like to release NovelMonkey without any kind of monetization for the first NaNoWriMo, but might add a PayPal donation button once a user has completed 50,000 words as a thanks. If more writers stay around after November, I might consider pursuing either a freemium, donation, or even a sponsorship model (hello MailChimp!) to keep monkey alive.

  • Explore donation and variable donation options
  • Explore freemium model later on, if a lot of people have expressed interest and costs become too high for me
  • Explore sponsors (like how podcasts are sponsored)