How to choose backend technology for my project?

Firstly, the technology stack of a commercial project should be selected based on several different decision factors.

• Staff availability is paramount. The developers, QA and associated team members must have a mastery of the technology for the project. For growing projects, new team members must be available for hire in the greater community. This rule often constrains the choices to relatively mature and popular technologies.

• Industry trends should be considered. Companies need to keep up with technology or risk becoming irrelevant. This goal is increasingly difficult as the pace of technological change continues to accelerate. New technologies should be considered and folded into the tech stack at the right time.

• Unique tools should be considered for the problem. It may be that one tech stack is better for the job at hand but not currently used in-house. Machine Learning is heavily influenced by the python community for example. In general, python would be a better choice than NodeJS for an ML project due to this factor.

• Time to market can sometimes dominate. Budget constraints and delivery pressure can push a project to use the incumbent technologies. This is usually a facet of the staff availability metric as the local team will have mastery of certain technologies.

For hobby projects the rules are much more relaxed. I would choose on a couple of factors.

• Personal interest. There are a myriad of IT technologies available. No one can master even a fraction of them so we all have to choose our areas of interest. For example, in recent years I have started learning, Python, NodeJS, client side JS, HTML, CSS, React (with hooks), C++ 17/20, Mongo, Electron, Kafka and just recently Elixir.

• Industry trends. From a career perspective learning new tech is almost a certain win. I invariably end up using technologies that I have self-taught for profit. Management likes to see an eagerness to learn in software engineers so raises and promotions are possible. If the current project ends then having a wide range of skills is very marketable.

For you hobby project, dump all the stuff you know and write it in new-to-you tech! Mongo, Python and React would be fun and perhaps profitable for example. Your simple description is less than a days work in these technologies. Host it on Heroku or one of the AWS services. Get a domain name, sort out DNS, port management and HTTPS with Let's Encrypt. Understand encryption and website vulnerabilities in your password scheme. Play around with websockets vs REST.

Most of all, have fun, it is a hobby after-all :)

posted almost 4 years ago

CC BY-SA 4.0

4y ago

Matthewericfisher‭

71 reputation 0 1 7 2

There are a few main and a few minor factors involved in most "which tool should I use" decisions.

Evaluation Criteria

1. "What do I already know how to competently use?" OR "What do I want to learn how to competently use in the course of writing this project?"
2. Are there any peculiar needs served best by one tool over another?
3. Am I being mandated to use any particular tool by a customer or The Management?

In the ideal world question 2 above would be the only way we ever evaluate anything, but in the real world humans are irrational and we tend to pick the absolute worst tools for a given job from a technical standpoint but make those decisions in a way that is emotionally satisfying for us at the moment we make the decision (and never mind how much pain this may cause us months later).

Separation of In-Development VS Runtime Concerns

When thinking about a tool it is useful to make two separate value judgements about it, one on how we interact with that tool (its interface) and the other on what utility it will provide for us when it is applied.

1. How will the project feel to interact with during development?
2. How will the resulting system actually run in production? (Performance characteristics and so on.)

Your Main Languages Are Your Main Interface

Your main interface to most projects is the language you decide to code in as this is where you will be spending most of your time. Dealing with customer data it is also likely that you will be spending a fair amount of time dealing with your DB schema and actually programming the DB itself (depending on how far into "make the DB do the work" you want to get VS "make the DB remember some things but do the work in the application code procedurally") -- so the decision to use Oracle instead of Postgres winds up implicitly also becoming the decision between flavors of SQL and possible PL/SQL vs PLpg/SQL vs PL/Python or whatever else vs non-relational DBs vs writing your own data handling and storage procedures from scratch.

This isn't always a significant difference but it certainly can be (money can also be a big difference when picking between Oracle and Postgres). One of the most annoying things is to build 90% of a project using a set of tools or libraries only to realize that they almost do what you want but not quite and to get that final, crucial 10% of functionality out of it you have to decide between performing major surgery to cover the gap or engaging in Workaround Oriented Programming to make the thing go (one reason the web is itself such a weird stack of idiosyncratic tools, languages and techniques is because it is a prime example of an entire ecosystem of workarounds).

Interfaces are important and that's why after using dozens of languages and learning them well enough to hate all of them at least a little, I have settled on a handful of go-to languages that have features I consider to be the most expressive, easiest to read months later (as opposed to writing "clever" code in a language that rewards that sort of thing, and then being confused months later why anything does anything), and most compatible across different coders who use the same language. For me this means picking languages with limited feature sets that rely more on functions than nifty syntax-driven features and data structures as opposed to OOP style objects. But everyone has their favorite things.

The Bestest Language Can't Beat a Garbage Runtime

Language decision is one thing, but runtime decision is an entirely separate concern in many cases. Whether or not to use Python, for example, may be a far less influential decision than whether you continue to run the resulting code on the standard Python runtime or move to Cython or Jython, or in the case of Java stick with Oracle's JVM, the OpenJVM or IBM's JVM.

None of this even addresses the issue of concurrency, distribution, robust behavior (fault tolerance), or other runtime considerations of course. If runtime concerns are your primary criteria for selection because they dwarf every other requirement of your project (which is very often the case for me) then the cost of learning a language you've never even seen before might be trivial compared to the relative cost of trying to implement some desired characteristic of a runtime yourself in a language you already know well. (This has been so true for me over the last several years that I went from being an Erlang tourist to lately working almost exclusively in Erlang!)

At The End of The Day...

By the time your project is complete you'll have spent more time comprehending your project and what it does than the incidental details of what particular DB you picked or what language you happened to write a given component in, aside of course from the cases where a particular runtime requirement could only be well served by a runtime and language designed specifically to handle your particular problem (for example, consider that SQL and the PL/[foo] variants are just ways to drive a runtime that has optimized primitives for handling relational data). If the tools you pick don't match the problem you are solving then it doesn't matter how cool the language you get to code it in might be: the solution will be either kludgy or extremely time consuming to implement properly.

I'm a lot less intimidated by the prospect of learning a new language to work on a given project than I am to actually have to learn a large project's internal libraries, coding practices and inner quirks.

I can't tell you what technology to use for your application. I know what I would use to start with (no guarantee I wouldn't switch after a few days realizing it wasn't going to work out), but familiarity and personal experience plays a lot into that. Hopefully I've instead explained a little bit about how I would think about tool and tooling choices, though, and you can apply that to your own decisions.

As always, the only truly correct answer is: "It depends"

posted almost 4 years ago

CC BY-SA 4.0

zxq9‭

61 reputation 0 1 6 0

There are a lot of factors that can go in the choice of a language:

• Do the properties of the language itself meet your requirements (e.g., C allows for more low-level optimizations than Visual Basic, Java is more type safe than python, go compiles faster than rust)
• Are the libraries supported that you need?
• Is tooling available for the language?
• How familiar is everyone with the language?
• Do we receive the right support for the language?

In your case, you have a hobby project and, I assume, you are the only person working on. For a simple website like that Java, PHP, Ruby, NodeJS, and Python are all valid options for what you want to do. Since you are already familiar with Java, this is an obvious choice, and I would only check if you already know about libraries you want to use that don't exist in Java.

There is nothing wrong with sticking with what you know, in this case. Of course you might want to learn another language to broaden your horizon. In that case I would first decide on the language you want to learn and then whether it would be an adequate alternative for your project.

posted almost 4 years ago

CC BY-SA 4.0

Peter‭

41 reputation 0 1 4 0