Launching OneFamily, a social network for Families and a family discovery tool

announce
1

I am proud to announce that after a lot of hard work, I launched oneFami.ly in December and the response has been great so far.

oneFami.ly is a free social network for families where you can create Family tree, write family history and biographies of your ancestors. You can also upload pictures of historical documents, say old photos, birth/marriage certificates, newspaper clippings, awards etc.

oneFami.ly also helps you discover currently living distant relatives through matching ancestor profiles.

The app uses Meteor, React, Redux and D3.

A little something about me - Three years ago when I got the idea, I had no programming experience, a complete noob. After google research, I started with Ruby on Rails. Rails was too much magic and I couldn’t get a handle on how the magic happened. I was also overwhelmed with learning - CSS, HTML, database concepts, Linux, Terminal, JS - all at the same time.

Within a few months, I discovered Meteor. The fact that everything was wired in Meteor and I had to think just in terms of one language (JS) was godsend to a noob like me. I took the DiscoverMeteor tutorial. Then I created Telescope from scratch to get comfortable with my new skills. That gave me the confidence and finally I started on oneFami.ly in Jan, 2016. It took me 11 months to launch the first version.

I would like to greatly thanks MDG for creating Meteor, a framework so easy that can help a complete noob like me to get started with web technology. I would also like to thank @sacha and @tmeasday for creating a highly-easy-to-read DiscoverMeteor book, @arunoda for his immense contribution to the community and numerous other package authors. @arunoda, it’s sad to see you go.

I would also like to thank everybody in the Meteor Forum. I have been a longtime lurker here and have learnt a great deal through your discussions.

Please do provide me with feedback, suggestions or any bugs you may discover on the website.

I am also looking for people to help create iOS and Android apps for the website using React Native. Let me know if anybody is interested.

20 Likes
2

I love hearing about Meteor success stories like yours @warpdrive - congrats on the launch!

2 Likes
3

Awesome work! Well done :grinning:

4

Kool idea :smile:
Love to see you create smth from scratch with ur own hands. Keep at it!

5

Okay, that’s super impressive, given you were new to coding just three years ago and coded this whole app up in the last 11 months. I echo @hwillson’s sentiment – hearing stories like this is great!

3 Likes
6

Awesome work @warpdrive !!
Magic - well done.
I must tell my Mum about this - she is using the old paper stuff to document our family tree.
Congratulations again.

2 Likes
7

Congrats @warpdrive really nice app! I just created a profile and it’s very impressive that you were able to launch it with little prior programming experience.

This is a true Meteor success story and a great app concept, best of luck.

2 Likes
8

Hey, congrats on the work! Looks nice. I have one question, how do you do uploads and where do you store your data?

9

One question that’s really intriguing me: would you be willing to disclose details about your database model?

I have a fairly large Meteor app with over 11,000+ users (with 2,500+ weekly active), which is also a social network. Managing the social relations and loads of other documents with relationships is really becoming a hassle, and makes me want to stray away from MongoDB and thus Meteor.

We currently denormalize most of our relational data, but this is a burden when you need to update a single thing. You need to check every related document and see if it needs updating…

Love to hear your approach!

1 Like
10

Thanks.

I am using SlingShot package and store the uploaded pics on Google cloud.

The reason I chose Google cloud is because their API for regular storage (high latency) and long-term storage (low latency) is the same. So, in the future, if I were to move photos from regular to long-term, it will be very easy. And that will halve the hosting cost.

In social networks, the life of a shared photo is very short, maybe a week or so. The future strategy would be to move pics to long-term storage after a few weeks. Google promises a latency of max 3 seconds for long term storage. For Amazon S3, not only their API for long-term storage (Glacier) is different but also their promised latency is in hours.

11

Thanks a lot. I could do with more users. :slight_smile:

12

My technology stack is Meteor, React, Redux, MongoDB and D3.

Most of OneFamily database is also denormalized. The only thing I have normalized is the author data (name, profile pic etc.). I started out with denormalized data (i.e. store author data in every document) but then later realized, it could be a big hassle when people change their profile pics. I also didn’t want to burden server with join-relations so the client (browser) reads the data first (say posts or notifications), extracts all the authorIds and makes another trip to server to get the author details. Until the author details come back, I display a gray circle as the avatar. I also store author details in Redux store. So any author detail is downloaded exactly once in a given session.

Also, I don’t use any subscriptions. I receive all data through methods and store them in redux store. And then I poll every 5 minutes for new data. This keeps the server connections and thus server load to the minimum. I use Redux for optimistic updates on the client side and handle server error, if any, using Redux Actions.

All the posts on the website are by default private to the Family. So, anytime a post is created, I add PostId to PostStream collection. Now when a user logs in, I don’t need to calculate which posts to show to him/her. I pick the familyId of the user and all the post Ids for that family from PostStream.

My goal has been that server should not do any calculations (or minimum calculations). It justs reads the data from MongoDB and serves to the client.

1 Like
13

Thats some interesting insight. And how do you handle the access to the files? When I was thinking about a file upload solution, I was worried that I only could use public URLs. For instance, when I upload a file to Amazon S3, the file will be accessible to all people who know the public URL. There is the option to restrict the access to the files and only allow access from certain IPs, but then I would have to send all files via my application.
Is this correct? And if so, how did you solve this?

14

Great App!! Congrats!!!

1 Like
15

Even Facebook hasn’t solved this problem. :slight_smile:

Google cloud has pretty extensive security rules, even down to a single picture level. But there documentation is a nightmare to read and I couldn’t figure it out. Also, to the best of my knowledge, they use user’s gmail address for restrictions so it doesn’t really cover all the users.

If this security is important to you, I think the only way to do it is to save images in MongoDB as blobs. But it does have other implications - Server load, database size etc.

1 Like
16

If it’s ok, could you share where are you hosting, how many servers and server config - RAM etc? Also if you have multiple servers, how do you load balance?

17

For instance, when I upload a file to Amazon S3, the file will be accessible to all people who know the public URL.

No, it’s not, resources are private by default. You can create access policies to enable secure access to resources: http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html

You can also use CloudFront and its signed cookies or URLs to have access control through CDN delivered files as well - then you just set your S3 bucket as the source; http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html

@warpdrive your app doesn’t use HTTPS while dealing with user signin and sensitive data. Strongly suggest you get your security correct (HTTPS and the above access policies for files) before storing birth certificates etc. Congrats on the progress in any case :slight_smile:

1 Like
18

Currently our setup is quite big because we’re part of a startup program with Azure.

Top down this is our setup:

Azure loadbalancer
v
2 Nginx Loadbalancers
v
8 webservers (1 core each, 3,5GB ram)
v
3 MongoDB servers configured in a replicaset

(This setup is way more than you would need, our codebase is pretty big so we have more servers than needed).

Before we were running Meteor on EC2 and had this setup:
1 Nginx Loadbalancer
v
3 webservers
v
1 MongoDB server (with a script to copy our DB to S3 storage every 30 min)

Things you could read:

19

This looks like polling on a rest backend, isn’t this defeating the main strength of using Meteor for real-time updates?

20

“…isn’t this defeating the main strength of using Meteor for real-time updates?”

True. But I didn’t need that strength. Also, the “real time reactivity” puts a lot of load on server. As a self-financed bootstrapped start-up, I have also focussed on keeping my server cost low.

I am using Meteor because this is the only thing I know. When I started out with my idea, I was a complete noob. Meteor was very easy to get started for a person like me. Since I have been completely focused on getting the site live, I have not had opportunity to explore anything outside of Meteor (besides React).

The real strength of Meteor is that it’s makes it so simple for anybody to get started with Web Technologies. It hides the complexity of tying things together for an average noob developer.

4 Likes