Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics

Dashboard
Notifications
Mark all as read
Q&A

How to choose backend technology for my project?

+6
−0

I am planning to build a "Customer Management Portal" as a hobby project using technologies like HTML,CSS,JavaScript,JAVA,JDBC,Oracle Database.The description of the portal is:

1)Customer details registration.

2)Customer can login using an ID which he gets after registration.

3)Customer can update as well as delete his details whenever required.

4)An Admin can view customer details using his ID.

Since I am familiar with JAVA I prefer the above mentioned technologies, but there are other technologies like MEAN/MERN stack and backend languages like RUBY,Python,PHP etc. How to choose the backend technology suitable for my project.I mean how to analyse and do the tradeoffs.

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment

I would strongly recommend that the customer can log in with their email address - they will be able to remember that, but can easily forget a login ID. (Unless you mean you are going to generate the password for them.) Martin Bonner‭ 23 days ago

3 answers

+7
−0

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 :)

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comments

+5
−0

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"

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comments

+4
−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.

Why does this post require moderator attention?
You might want to add some details to your flag.

5 comments

@Peter I found that Codidact was written in Ruby. Could you tell some obvious reasons for using Ruby? also compare if it was written in java, please. aditya98‭ 24 days ago

I’d add that the only way to know what kinds of effects language selection can have is to do some projects with varied languages. Don’t do those experiments on projects that others are counting on, so do try out new languages for smallish (but non-trivial) hobby projects. dmckee‭ 24 days ago

I am the wrong person to do a comparison of Java and Ruby, but I doubt that Ruby was chosen for Codidact for any other reason than personal preference of the person who started it. Peter‭ 24 days ago

@aditya98 People tend to use Ruby for the sole purpose of making a Rails app. Rails is widely used because it's not very hard to start with, easy to quickly host(Heroku), and has a wealth of learning resources. I suggest looking at some course material, learning some frameworks and finding out what works best for you. A few google searches about server-side performance comparisons would not hurt as well. Razetime‭ 24 days ago

Java tends to get verbose and projects written in it over-engineered (StrategyFactory? only in Java), but is wide-spread in the software industry. A rule for a manager is: It is never wrong to force Java for a project because there are many Java programmers, you can hire and fire them at will. Ruby is not as wide-spread. It's style is a lot conciser and flexibler, and with the motto "Convention over Configuration" this is true even for configuration. nalply‭ 11 days ago

Sign up to answer this question »