Oded Arbel

As otherwise noted, you can also run your backend on Javascript, with the NodeJS server. That being said, I do recommend knowing more than one programming language - by having more tools in your toolbox you both make yourself more attractive to employers and by being familiar with more "coding philosophies" you'd be able to create better applications.

Javascript server programming is easy to learn - if you are already well familiar with Javascript; Typescript is a richer language that is based on Javascript and you'd often find it intermingled with Javascript in the same application, and it also runs with the same tools (such as NodeJS); PHP is a relatively simple language with a very large and friendly community, and tons of libraries; Java is also a very simple language with a lot of libraries, but is somewhat bit less accessible than PHP for "just building a web application backend"; Python is very popular these days (competes with Javascript for most popular programming language).

There are sssssooooo many good options for deploying a web service to production, there is really no space here (or probably anywhere outside a dedicated year-long course) to learn all the necessary technologies for even a part of this huge space. So instead - lets start with the easiest one (IMHO, others may disagree): AWS Fargate.

AWS Fargate is a simple container runtime - there are others, but Fargate excels in that it is very simple to create and manage (you basically let AWS manage it for you) and you don't need to worry about servers and control nodes and proxies and other things other container runtimes (such as Kubernetes) will have you worry about. On the other hand, it does not skimp on performance and if you ever want to go Kubernetes (which is all the hotness these days) - there is a clear and simple "upgrade" path.

How do you get there? First learn what a "container" is - the concept was popularized by the Docker product and it is pretty much an industry standard (there are other container formats, but the Cloud Native Foundation's format is basically the Docker format) - a container allows you to bundle an application in an lightweight operating system image and run it as an application. A container runtime can then take a container and run it, scaling it up as needed, without you needing to manage deployment scripts, process management and stuff like that.

To deploy your Java web service on AWS Fargate you need to do the following:

1. Package your Java web service in a JAR file. Maven is the common tool to do that, though gradle is also very popular. There are other build tools for Java but you probably want to choose one of these two and learn it. Gradle is somewhat simpler to start with but it gets complicated pretty fast (it is basically a scripting language for building with a lot of "magic" - which often implies a stiff learning curve). Maven looks more daunting at first - with all that messy XML to read and write - but its internal complexity peeks really fast and then adding new functionality is basically just using (or creating) new plugins with the same simple configuration language.

2. Create a container image from your JAR file that can run it as a container: You obviously need to learn Docker and how to write Dockerfile scripts - this is pretty easy and straightforward, then look for examples how to run your specific application in a container - depending on which Java framework you're using. My weapon of choice is Vert.x and here's the documentation for that on Docker: https://vertx.io/docs/4.3.7/vertx-docker/. If you are using Maven then you can use a plugin to automate building the container image for you - but you should still learn how to do it yourself to understand what's going on. I use com.spotify:dockerfile-maven-plugin (it is very simple and stable but also have stopped development) or you can use io.fabric8:docker-maven-plugin which is newer and more capable but also more complex. You may be able to use these with Gradle as well - I don't have any experience with that.

3. Create an AWS account and learn about setting AWS Fargate and AWS Application Load Balancer (you should use an AWS load balancer to expose your Fargate service to the public internet - the alternative is at best much more complicated and at worst unreliable). AWS has a lot of good documentation on the subject. You can start by setting everything up in the AWS console, but you should really learn how to do it with the AWS CLI tool and also recommended to use an automated provisioning tool such as AWS CloudFormation or Terraform. The advantage of using Terraform is that it is not AWS specific and if you ever want to move to a different provider, you can take Terraform with you, OTOH it is more complex to learn and operate.

4. Set up a continuous integration (CI) pipeline to automatically build and deploy your service. There are many good options, but you should probably stick with what your source control service provides: Github Actions, Gitlab CI, Bitbucket Pipelines, Azure DevOps or maybe even AWS CodePipeline (if you already use AWS you might want to go full in). AWS also has a full git repository hosting (AWS CodeCommit) and integrated CI/CD (AWS CodeStar) so you can keep all your eggs in one basket - they do make it very simple and easy to maintain and control, but the standard caveats about eggs and baskets apply.

5. Deploy your service and then monitor it - this is a completely different huge ecosystem that you'd need to know about when you actually need to maintain a "real" production service. I use StatusCake (for external status monitoring), AWS CloudWatch (internal status monitoring and alerts) and OpsGenie (on-call management, alerting and escalation).

Firstly, there's nothing wrong with Firebase for scalability, not can I see anything wrong with "cheap" - unless you expect to need the more complex tools that MongoDB offers (such as Map/Reduce, GridFS and such), I don't think you would want to pay more to get the same capabilities. That being said, there are advantages to move to an open-source code base that you have the option of hosting yourself - preventing vendor lock-in is a legitimate requirement.

Now, as for hosting MongoDB: there are a lot of providers that will host MongoDB (or compatible, see AWS DocumentDB) for you - AWS, Linode or Digital Ocean all offer managed database as a service, so you don't have to mess with VMs and installing and maintaining your own instance of the database server - they are often also cheaper than just running a VM. There's no need to co-locate the database near the application - all of those managed MongoDB services offer great connectivity so unless millisecond latency is critical for your application, any will do.

That being said, your best bet for starting to work with MongoDB is probably MongoDB's own Atlas service - it is a managed service provider that allows you to select in which cloud hosting provider to co-locate a managed MongoDB instance - they support AWS, Azure, GCP and others. They always have the latest and greatest MongoDB version (they make it themselves) and they even have a free tier for starting development on the cheap.

It is mostly dependent on what you feel comfortable working with (or, if you are unfamiliar with either - whether you will better connect with either one, which is not easy to predict).

I personally prefer PHP as the language is more complete and has more robust runtimes platforms. Node.js can be problematic and the NPM.js ecosystem is much more problematic than even PHP's. That being said, each have their strengths and weaknesses and one of Node.js strongest appeal is that you can use more modern languages that build on top of Javascript - such as TypeScript and still use all the existing Javascript APIs.

Now regarding the Google Maps API - Google offers a Javascript API but not a PHP API, so please note that. Its important to understand what you are getting here - the Google Maps Javascript library is meant for frontend development - i.e. to run in the browser. You didn't explain what you expect to use the Google Maps API for, but if its for displaying a map on the website and letting users click that and interact with the map, then you'd need to use the Google Maps Javascript API, but it doesn't require any specific server implementation - even if you use the server Google API SDK with Node.js, it will still look and behave differently than the frontend API, because they are meant to do different things.

If you want to use the Google Maps API on the server - for example to updates places or get routing directions, you'd need to look at the Google API HTTP examples (here's the one for routing: https://developers.google.com/maps/documentation/directions/get-directions#maps_http_directions_toronto_montreal-txt ) and figure out how to use these in your server. The Google documentation has samples for Javascript but not for PHP, but the official Google PHP client library has documentation that explains how to use these examples with the PHP library: https://github.com/googleapis/google-api-php-client#making-http-requests-directly .

Of the two options you mentioned, only Django is a backend technology. AngularJS is another toolkit to build web applications, though more of a framework with a complete set of technology than Bootstrap which is just a UI library.

I think that the best way to push yourself forward is indeed to learn multiple technologies and multiple programming languages, and Python is often a good choice - it is simple, clean and has a lot of mindshare (i.e. you can easily find help).

So when looking at the next technology to learn and the next programming language, Django is a good choice. If you want to stick with Javascript, then I can echo the recommendation to look at Node.JS as a backend service - though if you want to push yourself and become a better software engineer, then putting all your eggs in the Javascript corner is probably not the best choice. Good engineers have a large set of tools to draw from and knowing more than 1 language can both increase your marketability and tech you to think in more than 1 way.

If you are looking for CI, BitBucket is not the preferred solution - it has many limitations that Azure DevOps does not have. That being said, GitLab is probably a superior solution to either as it has a very sophisticated and flexible CI solution and you can even run your own CI workers if you need access to resources that aren't available on the hosted service: such as specific hardware, very long run times or licensed software.

Other than that, if you are only interested in source control, and specifically git - either will be a good offering as well as quite a few others. You do need to make sure that the software you plan to control is a good fir for git - specifically, if you are looking to store large data sets (I'm thinking BI, yes) as a source of truth, git will be a poor choice and you should look for hosting based on Subversion or Mercurial.

The main advantage PostgreSQL has is additional data types that can be very helpful in some specific use cases, such as arrays (which are actual SQL standard, but unimplemented by the MySQL family) and geometric types (and a few other unique things). If the optimizations offered by these column types fit your use case, then PostgreSQL is probably the best choice for you.

If these sound like edge cases that don't apply to you - welcome to the club of 99.999% of RDBMS users. For that club, MySQL (or its MariaDB fork) are the best fit: 1. High performance out of the box. 2. Choice of a per-table database engine to optimize usage (need ACID compliance: InnoDB, need high read throughput: ISAM, need clustered in-memory access: NDB). 3. True multi-master replication to increase write throughput in a cluster environment, as well as a variety of proxying technologies. 4. Optimization for key/value and document storage use cases with the X protocol. 5. Much simpler setup and maintenance.

In one company I worked for (granted, a few years back), we started with PostgreSQL and after failing to get any of the expected performance, purchased an EnterpriseDB (commercial PostgreSQL) license - and when the experts also failed to get us good performance, we moved to MySQL and I have never looked back.

Before I recommend a tool, I think it is important to look at your requirements and capabilities - as you have looked at 3 very different tools: different programming languages, different implementation strategies and different target audience. It sounds like you don't already have a set of dedicated developers, so it is likely that your choice should be mainly driven by how easy it is to get developers that are familiar with the tools - so I'm going to list some considerations that I think you should review, starting with what I believe would be the most important for your bootstrap process:

1. Mindshare: how easy it is to get developers that are familiar with the technology and can immediately start working on your project. This is definitely where Node.js shines - Javascript is one of the fastest growing languages and Node.js played a huge part in this. I would bet that wherever you are located, Javascript developers would be the easiest to come by.

2. Fit for purpose: from your description we can understand that you are looking at a backend technology to implement some sort of REST API for a mobile app. The 3 different options you offered each fit on a different place on such a stack: Ruby is a programming language and not even a service framework - if you choose it, you then have to choose a server implementation and REST framework (and there are a lot, mostly as Ruby has a standard API for connecting a web server and application frameworks, and so this space has blown up) it used to be that Rails was the most popular, so you may choose that, but the interest in it has waned a bit in recent years; Node.js is a server framework, but it also has a dominant application framework called Express, that is geared well to your usage, so you'd likely work with that; Laravel is an application framework - it uses the PHP programming language, whose use has declined a bit in recent years, and was originally built for MVC type applications - though it has workflows for REST APIs and would probably work well for you as well.

3. Scalability: while this is probably the least significant issue at the moment (when it gets to a point where the backend service is your bottleneck, you'd likely have enough resources for a rewrite), and also the most dependent on factors that you didn't specify and are hard to estimate (such as: session complexity; amounts of data; sensitivity to locality; sensitivity to latency), it is still worthy to address it. Unfortunately, I don't have any good news: Ruby is notoriously bad at getting the best performance (the current BKM for milking performance from a Ruby codebase is to run the app on the Java virtual machine); Node.js has severe memory limitations that will make it very hard to scale if your backend needs to do a lot of work (I have a very personal and troubling experience with this issue); and PHP has as many scalability optimization strategies as there are PHP developers (this is not a good thing).

My suggestion to you as to how to proceed can be summarized to this prioritized list of options: 1. Get a good head developer with a lot of experience and let them choose the best tool - they'd likely go with what they know, which is likely to be a good choice - and if not, when scalability will become an issue, you could rewrite. 2. Choose something (likely Node.js) and don't worry about scalability - see (1) above. 3. Use Vert.x: it is a highly scalable application and service framework that offers great performance as well as a lot of tools to solve data scalability, locality and latency, and it works with multiple programming languages, such as Javascript and Ruby.

As others have noted, MySQL Workbench cannot be used instead of Microsoft SQL Manager to manage Azure SQL (MS-SQL Server, I hate that Microsoft uses generic category names for their products).

If you're considering switching to MySQL (Possibly using Azure MySQL managed database), then please not that unlike MS-SQL Server, you do not need the MySQL Workbench to connect your application to MysQL: just use the correct driver for your stack, and you're all set (if your stack is using the .Net platform, use MySQL Connector/NET from: https://dev.mysql.com/downloads/connector/net/ ).

If you do want to use a graphical interface to maintain your MySQL database, then MySQL Workbench is a great choice, but you are not limited to it - as others have mentioned, there is a plethora of competing graphical database management tools that would work just as well with MySQL - one of the advantages of choosing MySQL for your stack is the huge eco-system that is built around it.

You are probably looking at another hosted solution: Jenkins is a good tool but it way too work intensive to be used as just a backup solution.

I have good experience with Circle-CI, Codeship, Drone.io and Travis (as well as problematic experiences with all of them), but my go-to tool is Gitlab CI: simple, powerful and if you have problems with their limitations or pricing, you can always install runners somewhere and use Gitlab just for scheduling and management. Even if you don't host your git repository at Gitlab, you can have Gitlab pull changes automatically from wherever you repo lives.