Forem: Karsens

Quickly ship your changes to git? Use 'ship'

Karsens — Wed, 29 Dec 2021 10:25:31 +0000

Ship is a small cli command I wrote that automatically adds and commits all your changes and pushes them to your current branch. It then lets you know if it succeeded or failed.

To add ship to your cli, copy and paste this into your terminal:

echo "ship () { BRANCH=$(git branch --show-current); git add . && git commit -m \"${1:-Improvements}\" && git push -u origin \"$BRANCH\" && say you shipped it || say something went wrong }" >> ~/.zshrc && source ~

Go ahead and try it! Hope you like it ;)

P.S. only tested on MacOS.

Scaling to one million RPS

Karsens — Fri, 11 Jan 2019 20:49:31 +0000

This Forbes Article and its Original Post describe how a guy managed to hit 1Million RPS for a while with one load balancer and 10$. This post also contains a gist to reproduce the experiments, which is pretty cool. This Facebook blog shows how they scaled up to 500 million users in 2010. In this article, which is also from 2010, Facebook gives an insight about their statistics and scaling strategies. Stories like these excite me to think about future scaling of Communify. With 500 Million users, Facebook had 13M requests per second. Now, with 4 billion users, they probably handle ±100M requests per second. I wonder how proper scaling could end up there.

My Geo Scaling Plan: scaling without bottlenecks

Since we have global communities now, it's pretty much impossible to get one user's data from one server. Therefore, the load balancer may need to have an overview of which communities are housed where. Then, the load balancer can send the query to the right server, based on the request.

If this wasn't the case, it would be easy, like described in my previous article about geo-scaling. But now that we have global communities too, we have a few tricks to do. This is what I came up with:

PULL automatically pull my GitHub repo everywhere whenever a new commit is pushed. pull, restart pm2, and automatically merge db changes to the db.
SPLIT automatically split a server into 2 servers whenever load is too high. Shard on community. The server is split in two, so there should be drawn a line on a map (cluster by location) so that the total members are split in two, based on location. There is an edge case in which an user is member of a community in both clusters. In this case, put the user on both servers. This is no big deal. The new server should then let the load balancer know it exists, and expose its communities.
MERGE automatically merge a server with another server whenever load is too low. Because we merge servers, we can't use incremental ID's, but need a UUID or GUID to keep table-rows unique. Since the sharding/splitting was done on communities, we can just merge all rows in all tables together. But because users may be in both clusters, there can be double users. If this happens, pick the user that's last updated, because that's where the user was active last. The deleted server should let the load balancer know it got deleted, so it will be deleted from the global server list.
BALANCE put a load balancer in front of all of it that directs every request to the right server, based on communityid. it knows which server has which communities because every server exposes their communities by communities(){id} and we know every server, so, every minute or so, we can look up all community-id's from all servers. This is pretty light. However, this can also be done the other way around. When a community gets created or removed, or when a server splits up or merges, the load balancer gets notified with the new composition. This would be instant and way cheaper.

Double Models

Models that can be sharded based on community, and thus just need to live on one server, and have just one copy: Posts, Subs, Roles, Communities, Channels.

Models with some problems: Users, CommunitySubs, Locations

A user can be subbed to two communities that live on different servers at the same time. There are a few possibilities to deal with this:

1) Copy/paste When a user updates the current community to a community on a different server, copy that user, together with all of its CommunitySubs and Locations to the new server. This will, then, be the single server that user gets its data from. CommunitySubs get notification increments by mutation calls (that increment) from other servers where the user still exists. When a user changes community, all servers should be notified, so that if a server knows about a user, it also knows in which community that user is... This can get heavy, but it doesn't happen that often. A side effect of this strategy is that users, communitysubs and locations can get outdated on servers on which the user isn't active. However, all servers that need to know, know on which server a user currently lives, all servers can get updates about that user to stay updated. For example, every hour, or every day. I don't know how much will be useful. In principle, a user doesn't change much for another community if it's not active in that community.

2) Global, seperate database for users, community and locations This can be nice because its a single source of truth with is always up to date. However, the drawback is having multiple servers the app has to connect to, and there is one global server, which is bad for availability (risk) and can't scale infinitely.

I think this is where I have to choose from, and I think option one is the best. I still have to discuss this with an expert. I'm quite impressed with this idea, because my app can scale infinitely big without bottlenecks based on a few assumptions, which my design of the app can guarantee:

1) It doesn't get bigger than one loadbalancer can handle (around 1M rps)
2) A single community never has to be sharded

This whole architecture is, I think, very interesting and would also work for my Chat-BaaS idea.

From 1M to 100M RPS.

100 M RPS, 4.000 M users, and ±40 M communities, ±20.000 servers.. That's the dream!

On a single server that's balanced well, I don't think any problems will arise. The only problem is that, when a user changes community, all servers that know this user should know this, so the server has to send 20.000 requests! Right? Well it does. Unless it knows on which server all other communities the user is subbed to are hosted. And the load balancers know this, right? So let's ask a load-balancer, and then just let the servers know that care! Great! Problem solved.

The other thing is, we have to balance the traffic with load balancers. One load balancer doesn't cut it anymore. 100 times as many RPS should mean 100 times as many load balancers, but because we have some extra work for the load balancers (telling servers which communities are hosted where), I think 1000 load balancers would be better, just to be sure. With 40M communities, is it still doable to let all load balancers know which communities are hosted where?

If yes, the problem gets easy. Just have one 'Master Load Balancer' that assigns any new visitor to one of the 1000 Load Balancers, and keeps it there. From there, the visitor knows where to go, because every Load balancer knows everything. Searching from ±40M rows of communities could be doable, but the bottleneck is probably that, on every user changing community (that is on a different server), every Load Balancer gets notified. The question is: How many times per second does this happen with 4 Billion users? If this is more often than ±5.000, the bottleneck is too small, and it won't fit. We have to find another solution.
If no, it gets complicated. Splitting the communities over all load balancers may be an option, but it's a complicated mess that I would have to think through. Let's save that for another time!

Originally published at my website

Chat-BaaS: Chat Backend as a Service

Karsens — Fri, 11 Jan 2019 00:27:47 +0000

Chats are very universal. With Communify, I'm solving a problem that many software companies have solved, are solving, and will solve. I am solving it for React-Native + Node JS + GraphQL + MySQL, on Linux. A very nice combination.

What if I could create a BaaS for chats, and solve this problem once and for all?

There are already Chat BaaS'es out there. Check https://sendbird.com/. If you read their blog, you'll find others, too. But it's super expensive, and I don't know if they've taken the right approach.

So, in this post, I will elaborate on what I think the right approach would be for creating a Chat-BaaS.

Model, front-end and back-end

Every chat-post has { user (id,name,avatar,pushtoken), channel, group, information (type, text, likes, etc.), createdAt, updatedAt } and every channel has { id, channel, group, user, createdAt, updatedAt, lastMessage, lastMessageText, etc... }

The whole front-end is super convenient. I could open source the whole front-end of the chat-list, chat, chat-details, actions, and everything and couple this to a default BaaS where people can create an account, get 1M messages/month for free, and pay a lot more for more.

The cool thing would be that I open source the front-end as one component which is a data-coupled and navigation-coupled react-native component. you only have to give your token and it connects with your backend.

On the backend, it has a few queries and mutations:

Queries: serverInfo, posts, subs, mysubs;
Mutations: createPost, likePost, createSub, createPM, deleteSub, toggleSub, setRead, upsertSub.

On the front-end, it can actually handle all push-notification stuff. This is a big big deal. Lots of code that can be spared for a startup if they use this. The user model is very lightweight and is meant to be extended by the startup itself.

The cool thing of a BaaS is that you can create multiple front-ends for it. I could also create an app in which you can create your own 'app'. It then creates the whole chat-interface inside that app. with react-native-web, I could also expose that chat-interface on the web.

This idea could take a huge part out of my codebase. On itself, it's a big startup, which is just a small refactor for me to create and start using myself... Since the biggest part of many applications is the chat, it's a great way to shorten the programming time to create useful apps.

This app will still be useful in a 1000 years. Think about that!

Scaling

It gets even cooler if you think where the bottlenecks are. I think that, if it's a truly good product, you don't need marketing or anything. No sales. I think, if it's a truly good product, all you need is good scaling. It's so universal, that features is something you can finish. After a few years of programming, it just has all you need. So features is not a bottleneck you will need many people for. What's left? SCALING. So scaling is the bottleneck. So how do we scale succesfully? The great thing is that every platform that wants to use this, is independent of other platforms. So they have to scale independently. Another great thing is that even scaling can be automated. Databases can be created automatically. For small customers, a single server per DB will do with a few servers for the backend. This can be automated. Once we have super big clients that need sharding, they have 2 options:

1) Pay us for experts that automate the sharding process

2) Split up their app into separate communities, for example, location-based.

So if I get the hang of basic CI automation, I can automate up to 10k online users per community or so, maybe even more.

This is a great idea.

Should I do it?

I think that, if Communify doesn't pick up as quickly as I expect, it may be a smart idea to have a look at this. It seems that MessageBird is doing incredibly well. To start, a PoC should be easy. Just extrahere the server of communify, automatically create a new SQLite for every Backend user, and create a nice onboarding page that asks you the app-name and shows you your app on the web. It should just be a screen that you can place in your RN-app. super simple. If this proves succesful, I could create more building blocks for apps maybe. More small BaaS'es. For example one for a timeline. One for friends. One for pages. One for photo albums. The possibilities are endless.

To further see if it's really that easy to create a BaaS for Communify (there may be some things I didn't see because I didn't look at the code) I should have a look at the backend code and see if I really thought of all connections....

Join me!

Did you read it all and think it's a great idea? Then join me, I could use some hands! As of now, I have so many things I want to build, but just so little time! Yet, I already have a great start. I basically have all the code (front-end and back-end) already, I just need to rewrite it a bit, and make it look fancy. Let me know if you're interested, or let me know if you're interested in using parts of my codebase! Everything's negotiable!

This was originally published on my website
Follow my GitHub

Big reason to use React navigation over Wix navigation (React Native)

Karsens — Thu, 10 Jan 2019 15:07:42 +0000

Today I discovered a really big reason why React navigation is fundamentally better than Wix navigation. React navigation has functions createBottomTabNavigator/createStackNavigator, etc. which return a component. However, Wix navigation just has registerComponent, which take the screen you want to render (with a wrapper around it, if you want it) and just returns a void and creates this screen natively.
The problem with the latter is that, if you use a wrapper around your screen, this wrapper will be mounted for every screen that is registered. For our app this meant that our LocalAuthWrapper was also mounted 5 times on app start, because we had an app with 5 tabs, and it mounts all tabs. Therefore, the dialog to authorize with local auth mounted 5 times, which is 4 times too many. Because of how this library works, it didn't function anytime after the first time, and therefore we had to make native changes to this library.

I think it's kind of ugly that our wrapper gets mounted every single time a new screen loads... Also less efficient. With react navigation, you don't have this problem, because you can wrap your wrapper around the whole of the navigation, because navigation is a component too.

This fundamental difference should not be overseen! It can be very important.

Originally published here

Why code ownership is a must for agile development

Karsens — Sat, 05 Jan 2019 13:56:29 +0000

Tl;dr:

It takes a while to get to know a codebase
The more people have t know and edit one piece of code, the less efficient because of confusion and errors
However, strong code ownership also brings another bottleneck in play
Strike the golden mean! Strive for feature ownership to diminish ineficiencies and bottlenecks

It's optimal to assign one person to a piece of code if you want to have the optimal development speed. This is also one of the reasons why Communify is developing so quickly. I'm having ownership over the entire codebase. I know what every script does. Searching for where is what is never a thing. Having to figure out how something works or what something does, never happens.

If you're in a team, it may be useful to have access to changing someone elses code sometimes. This is called weak code ownership. You are responsible for your own piece of the codebase but others can make changes in it. You review those changes and make sure the codebase stays the way you like. I think this is the best because waiting on other developers to make changes for you can also be a bitch. It can slow things down and force you to work on something else. That's also why I don't like the back-end frond-end distinction much. I know python and react native, yet, at my current day-job, I'm not allowed to work on the back-end and make changes there. Very often I'm forced to start working on something else and stop what I'm working on now, just because the backend people don't have time to make a tiny change. If I could handle backend too, I could do this change within seconds. Now I have to wait hours.

A lot of new features in an app involve changes in all layers of the code and other work. That is, UI/UX, front-end, back-end, and testing. Therefore, if you have a front-end backend sepeartion of your team, a new feature has to be done by two people. If you also have seperate UX/UI and testing, that number becomes 4. Often, one is done before the other. Therefore, one person has to wait on the other for it to complete! This is, in my humble opinion, a huge bottleneck to developing speed and being agile... And now I haven't even talked about UX and Testing! These functions are very often also done by separate teams. If this is the way you do things as a team, and everyone has to wait for one another all the time, a new feature can take days, if not weeks. The bottleneck gets bigger and bigger.

Therefore, in a company that wants to be truly agile, I think that you'd have to strike the golden mean by giving everyone responsibility for a part of the codebase and process, yet allow everyone to access and edit all, and, in the end, strive to work on your own code yourself by proper issue/feature distribution by the team lead. This also shows why Full Stack Developers are so valuable. Especially when they can also handle a bit of UI, UX and testing. Ideally, you shouldnt' seperate code and tasks by it's technology and skills used to create them, but by it's features. This ensures code ownership, yet makes it possible for one person to add one new feature, all by himself, from start to finish. You can even take it further: let the person that crafts the feature also evalue the introduction of the feature into production and see the impact to the product. See what customers think of it, and if the results are not good, improve. I think this would be great for many reasons. One because you improve agile-ness, but also because you get to see the result of your own doings. As a front-end developer myself, it can be very boring sometimes. I never get to think about what something must look like, I just need to make it. I never get to see the outcome of what I make, I just have to make it. So boring....

So, in conclusion:

Be agile
Strive for feature ownership along the entire production-line to diminish bottlenecks, inefficiencies, and waiting

(originally published here)