No Code: How Much Is It a Threat To Developers? - Part 2

The Real Reason Behind the No Code Rage

No code tools and platforms like Construct, a no code game builder, Thunkable, no code android app builder, website builders like Wix, and more have been in existence for like forever. The no code concept is not entirely new. Then what really happened that caused so much stir of late? 

Well, it's because of the PANDEMICIt cut most of the jobs. The economy was hit pretty bad, industries specifically travel and hospitality, literally came to a standstill. People were let go or wages were cut down. This triggered a surge of people starting online businesses, approx.—1.5 million, through 2020 and 2021 

In addition, as our world became remote-first, the brick and mortar businesses realized the necessity of having an online presence. These reasons combined spawned an unprecedented demand for systems that would enable them transition online quick and thus the no code rage. 

Now let's find out why developing a complex app like and at the scale of FacebookInstagram or Netflix is not reasonable using these no code tools.

Why Can't We Build Complex Apps Like Facebook Or Instagram With No Code Tools?

Polyglot Persistence

Besides building the user interface, one of the first steps when developing any application is to design the data model. And apps as big and complex as Facebook have a polyglot persistence architecture. This is primarily to leverage different database technologies to fulfil different persistence requirements in the application. 

For instance, to store relationships like persisting friends of a user, friends of friends, what rock band a user likes, what food preferences they have in common with their friends, etc., a relational database like MySQL or a graph database like Neo4J would fit best. 

For low latency access of all the frequently accessed data, we can implement a cache using a key-value store like Redis or Memcache. We can use the same key-value data store to store user sessions

To enable businesses run ads on our portal, we need a payment system. For this, we need ACID transactions and strong consistency; this makes a relational database the best fit. 

To enhance our application's user experience, we need to recommend new content to keep the users engaged. A graph database would fit best to implement a recommendation system. 

To implement the search feature that would enable the users search for their friends, pages, groups, marketplaces, products, etc., we can use a mix of a documented oriented store like Elasticsearch and a graph database like Neo4J for running a contextual search. 

Next up is analytics. To understand user behavior, we need to set up an analytics system. This would make sense of the data generated by the users. We can do this with a wide-column database like Cassandra or HBase

Businesses continually evolve and the algorithms are continually tweaked based on analytics data and social trends. Short videos is one good case in point. TikTok surpassed Google to be the most popular website of 2021 because of the popularity of the short video format. YouTube and Facebook, Instagram played catchup with YouTube shorts and Reels, respectively, to stay relevant.

Illustration 2.6

I can go on, but I believe you get the gist. Picking the fitting persistence technology and designing the data models for these applications is complex and needs a lot of brainstorming. And the same goes for every component in the architecture, like when picking the right message queue, programming language (backend, frontend), and so on. 

Illustration 2.7

I do not see how all this can be accomplished without having the freedom to pick the fitting technology and access to the code.


Microservices

Apps as big as Facebook, Insta have complex architectures and are powered by hundreds and thousands of microservices. And this complexity in the architecture is for a reason. Features such as Live streaming, messenger, Fb groups, Fb pages, Home page, post recommendations, group recommendations, Like button, and so on have dedicated microservices powering them developed and maintained by dedicated teams. Every feature may be powered by a single or a number of microservices.  

Splitting different features as dedicated microservices have several upsides:


Leverage The Fitting Technology

We can leverage fitting technologies to build our features, for instance: for building features like messaging, live streaming that require a persistent connection between the browser and the server for real-time data interaction technologies such as NodeJS, frameworks like Tornado in the Python ecosystem, Spring ReactorPlay, and Akka.io in the Java ecosystem can be leveraged. 

C++, Rust can be used for writing features that require low-level memory manipulation. This provides more control over memory to the developers when writing distributed systems. Erlang can be picked if we need support for concurrency, fault-tolerance, and distributionGo can be used to write code for multi-core machines and handling a large amount of data. Julia can be used for writing features that need high performance, computations, and numerical analytics, and so on.

 

Loosely Coupled Architecture, No Single Point Of Failure, Dedicated Teams

Since microservices facilitate a loosely coupled architecture, there is no single point of failure in the system. Even if a few of the services go down, the application as a whole is still up. Services can be independently deployed, not affecting other services. Microservices can be owned by dedicated teams, facilitating better management and less chaos.  

I'll stop right here and won't go into technical detail any further just to keep things concise. However, so many things still remain to talk about, like image, audio, video optimizations, data compressionrecommendation algorithmsgraph searchhandling concurrency scenarios, architectural optimizations for cutting down deployment costs, and more. Nevertheless, I hope you get the gist.  

 

An insane amount of engineering effort goes behind these services to provide a top-notch user experience staying ahead of the curve. Here are a few interesting reads if you wish to delve any further into the technical details:  

Netflix: How it serves personalized recommendations and visuals for the viewers.  

Facebook: A browser tweak that saved 60% of requests to Facebook

Under the hood: The natural language interface of Facebook's graph search

I wonder how all this engineering can be done using drag and drop builder tools without access to the code.  

Social networks and e-commerce stores can also be built using WordPress and a few plugins, but the question is, should we? Everything has a trade-off and a use case.

 

Scalability

When no code platforms claim to scale apps built on their platform at par with Facebook, Instagram, and Netflix, this means your app running on these platforms will never be short of compute power or memory for as long as you keep pouring bags of money on the infrastructure since these platforms, in turn, are deployed on cloud services like AWS, GCP or Azure.  

But can we optimize our server costs? No!  

Are we certain our app uses optimum resources? We do not know since we do not have access to the code and the profiling tools.  

Can we cut down the infrastructure costs by optimizing the code and the application architecture? No!


Folks! Every tool, technology, platform has a use case and is not a silver bullet. And this goes for open-source tech too. I have learned this pretty well, having spent a decade in the software development industry. I've written numerous projects from the ground up and spent countless hours scavenging the web, browsing through technologies and frameworks to pick the right tech that would align with my requirements. 

I have wasted days, if not months, trying to implement stuff with a not-so-fitting technology. I have implemented stuff with tech having no support and community and have later cried for days into a pillow.

Picking the right tech stack is crucial for our business's success. There is no way around it, and I think we all understand this fact pretty well. Do not take everything at face value. Do your research before zeroing on anything.

Is No Code A Threat to Development Jobs?

I am certain you would have figured this out by yourself. Still, just for the record, I will say, No! No code is not a threat to the development jobs unless your day-to-day work involves performing repetitive no-brainer tasks as opposed to solving problems. Repetitive tasks, if not yet automated, will soon be. AI and the scientists behind it are hellbent on automating every task that a human performs. 

With so many apps popping up as a result of this no code trend, I see this as an opportunity as opposed to a threat. Every online business, built with high code or no code, needs assistance in marketing, finding influencers, customer feedback, customer support, automation, and whatnot. We can come up with disruptive tools in the respective segment to assist them. All it needs is good research. The Reddit marketing tool I discussed in the earlier lessons is one example. 

In the next lesson, let's understand low code.

Discussion

0 comments