Basics – choosing the best fit amongst server-side programming languages
What should be the criteria to consider when developing a web application? It should go without saying that it’s the technological options in their stack. Choosing a suitable server-side programming language is the nightmare of small businesses and startups as they suffer from the burden of choice and limited available budget. Everyone wants a high-power low price easy maintainable bug free project, but the reality is cruel; especially on limiting starting resources.
Selecting the right language is, somewhat, essential and can come to hunt you down later if you have not scrutinized the opportunity cost. In all my humble thinking, I believe the implementation of a language is more critical than the language itself. Nevertheless, with Bill Gates in our thoughts, let us walk through adopting the right mindset when viewing the zoo of languages.
Choosing your server-side programming language
Obviously, experienced developers have already gone through the troubles of explaining themselves to top management, what is their guideline?
Type of Project
The type of project is probably the first thing you consider. As the joke goes, you don’t want to attack a tank with a fork.
If you are to deliver a small project in the quickest time possible, then you forego any of the prose below and jump to using a CMS like WordPress. It will give you a working prototype within the grasps of strict deadlines.
Here is where the troubles brew and shit gets real. A combination of frameworks, language SDKs and thousand of stack overflow queries glued together for the sake of server-side functionality and integration.
These web apps are developed with tons of tears and coffee; usually, it’s composed of different systems within a bigger system that is part of a system. The input of such mammoths is not one language but a bunch of them. Such heavy-lifting jobs are usually consumed by social media, eCommerce marketplaces, data warehouses or intelligence-driven interfaces.
Each server-side project type is powered by a set of business goals and choosing one language, might contradict the other. Therefore, take into account:
Heavy load processing
Rely on languages and frameworks that can deal with and integrate solutions for resolving high loads of requests. Video, audio and game streaming apps, file sharing, popularity surge are a few examples.
Various factors affect the latency of your applications, however, do try to start working on it from the very beginning. If Facebook took 1 more second to load than it is right now, would you still be using it?
Expertise and Knowledge of your Team
The level of your team’s expertise impacts not only the server-side programming process but also the post-developing one. If you have decided on a language, keep in mind the devs will have to maintain it after launch.
Producing code is not a seamless experience. Developers have to work out bugs along the way. If the team is indeed experienced, then identifying the issues and finding solutions for them is a breeze. Remember the deadline does not care about bugs torturing your poor fellows.
When setting out your eye on a particular language or framework, research into the developer community. Rich documentation and endless tabs on dev forums is just less time needed for conceiving your masterpiece. Play to the strength of numbers.
Favour ease of testing in your endeavours. Test-Driven Development is testing first and coding later, consequently, the quality and speed of your project increase. Built-in facilities are nice, but make sure your team can apply TDD successfully.
Time to Market
Projects can’t go on forever, while some inherently take a long time, nobody says no when it’s finished and pushed to production before the deadline. Startups and small businesses rely on quick to market prototypes, whereas medium and big businesses desire little to no downtime on servicing system improvements.
TTM does heavily depend on the stack you choose, and not the typing speed as many imply.
Plugins from the box
Always check what immediate functionalities might be added to assist your server-side programming troubles. For instance, Ruby on Rails (a Ruby framework) facilitates developers with open-source libraries (gems), consequently, decreasing TTM.
Don’t go writing server-side obsolete code, when the heavy work has already been done. Study your priorities and research what third-party solutions can do for you; then you can decide whether it’s worth reinventing the wheel or throwing a coin to Mesopotamians.
It’s not me nor you that is going to code the project visiting you during the nights. The cursor on the screen does not move, without the appropriate person exercising theory. Do check by all means possible the availability of professionals in your area, or maybe even remote. Costs aside do not put all your backend on some exotic patented framework that only the guy who quit knows.
Scalability entails the property of an app to offer respectable experience as the number of users goes up. It is not exactly always a linear growth and the system should always be prepared to not be tipped off by the sudden increase. Growth spurts, spikes and sudden agenda attraction are the main causes some services go down and we are met with a defeated screen: “Server is down for maintenance”.
Scalability is achieved in two ways:
Scale-up or Vertical Scaling
Involves increasing the available resources of your server machine: RAM, CPU, GPU. It is typically costly and is not fault-tolerant. Depending on the available architectures, it is inevitable that you may have to swap-out two or three pieces to power on a new system.
Vertical scaling is also susceptible to increased downtime and upper bound limit since you can’t upgrade endlessly.
Scale-out or Horizontal Scaling
Involves increasing the available resources of your system server by adding a new machine – called worker- into the pool. This is the default way of today’s expansions in the tech industry. It does not require a full restart. Another benefit to horizontal scaling is all workers amount to equal effort thanks to the load balancer. As requests are distributed evenly, there is no delay should a machine reach its full capacity. A pool of workers can also be referred to as a cluster.
Before you plan out on how better to thread out your work amongst 100 machines, execute the Minimum Viable Product. After you have just enough features under your belt to satisfy your backers, you can go on to loading up the servers with code. Don’t make MVP rocket engineering with frameworks bigger than the size of your whole code. Incorporate high return investment and low risk-factor when choosing your language.
Server-Side Programming: Maintainability
Plan and don’t think once you are done with the project, no more efforts will be required; that is not talking about adding features.
Clients and protocols get updated, therefore, you need your application always fully supported. Pay attention to:
It’s either too long and convoluted that your team spends more time on pinpointing the right starting point and the references it has or is so concise that debugging it is an issue. Therefore, it’s paramount you use a language that can be maintainable in the sense: it does not give developers a headache when they search through the lines only to find out there is a missing column causing a run failure. Other than that, impel the team to document the code in a discernible fashion. If a new-comer takes up the job, he shouldn’t spend years understanding what the project is and what it does. #Documentation
You cannot change the pillars making up the language itself, but you can design the dome that sits upon them. Portability, scalability and reusability of a server-side programming language are under an opinionated view.
Cost of Development
As all software goes some is free some is locked under a paywall. You shall scrutinize whether the advanced features that come with being charged fees are worth it. Explaining the legal consequences of publishing an app based on unlicensed or even pirated underlying software would be better for another type of article.
These costs do add up together with the salaries of server-side developers and third-party contractors as well as the server infrastructure required to power up the app. Not to talk about system administrators and the whole bureaucratic hierarchy.
Security of a server-side programming language
Be it open source code or code as a service, cyber-attacks are ever-present. Juniper Research estimated that cost of data breaches will rise from $3 trillion each year to over $5 trillion in 2024. This common enemy has goaded governments and corporations to work together in combating further losses.
You want your web app to be secure, safe, hack-proof your server-side code (actually, hack-proof everything). You will also pick technologies claiming to bolster defenses. The truth is security is not language-based for the most part. Faults in core code are fixed upon the requests of the community, either by the devs or the community itself.
There are running jokes about how insecure PHP is, but if you search thoroughly the cause of those breaches is improper usage of guidelines. On these criteria, follow the best guideline, not the best self-acclaimed secure language.
To sum up
Choosing the best server-side programming language is everyone’s dream, yet they did not put in the effort when the project was doing baby steps. Overanalyzing can be anxious, but it will save you more money in the long run. This list of criteria should be used as a comparison when selecting the language to power up your application. Although, remember that I’m not a programmer neither are you so it’s better to consult one before you smash that gavel saying: “Alright boys, we will write all this in HTML.” – it so happens that I work with over 50 senior engineers, so hit us up for a consult.
Are you binge-reading our articles? Lucky for you, the next one in line is top 10 programming backend programming languages. Just one less step towards understanding what makes the web tick.