Select development language

We have no experience in developing web applications aimed at monetizing.
However, we have experience in developing web applications as a closed system within a company. The development language at that time was JAVA.
In addition, although it is a batch process, we have a track record of coding with python.
Based on this, we considered the following options

1. JAVA
2. HTML + JavaScript
3. HTML + JavaScript + python

We selected a combination of HTML + JavaScript + python

The biggest concern when choosing a development language is whether there are many application developers.
If it's a language such as JABA Javascript python that I chose this time, wouldn't it be too hard to find an app developer.
There is no difference from the viewpoint of application team, so I chose it according to the preference of the infrastructure team.
Of course, as an infrastructure manager, I should choose one that is easy to construct and has a low maintenance load.

About JAVA:
JAVA has a bad reputation from the viewpoint of infrastructure staff - it is just a personal impression -.

• Release is troublesome. Compile / Create WAR file / Upload to Server / Deploy
• The size of the WAR file is large. It is still good if it is via LAN, but this time it was supposed to be in the cloud, so I was also concerned about the size of the file to be transferred
• Pay attention to the timing of release as the system will stop during deployment
• I wanted to have a mechanism that automatically compiles and deploys to the development server when source code is committed, but it is necessary to install dedicated middleware to implement it with JAVA.
• Tomcat is heavy for CPU and memory. It takes long time because all apps are deployed every time you restart it.

JavaScript only:
Backend programs developed in JavaScript inevitably run on the nodeserver.
This is my first time using nodeserver, so I decided by experimenting. This was a great reference for the settings. The Node Beginner Book
Every time JavaScript is released, you need to add a function to index.js. This is fine compared to JAVA, but it's a bit annoying.
Also, it is operationally careful that nodeserver needs to be restarted after release. At least I felt that it was not easy to use as the main system - it is just an individual impression -.

HTML + JavaScript + python：
After all, the conclusion was that this most orthodox style was the simplest and best.
No compilation is required, and deploying is just a matter of copying the source files. We don't have to restart and we don't have to worry about the release timing.
In the future, even if the application team requests PHP, Perl or Ruby, it will be executed on cgi same as python, so there is no problem.

About Go language

I also tried the Go language. It's a compiler language, so it's the same hassle as JAVA. I didn't find the language as good as its reputation - It's a personal impression -.
If the person in charge of the app requests Go language support, I will check "Why is it necessary?" And reject it if the reason is "cool".

Select WEB server

Consider the following candidates as WEB server

1. Firebase Hosting + Firebase Functions
2. Compute Engine + apache or nginx
3. Compute Engine + tomcat
4. Compute Engine + nodeserver

We chosed a combination of Compute Engine + nginx.

About Firebase Hosting:
I tried experimenting, Firebase's Hosting and Functions can show their true value when selected in pairs instead of using either one.
But I felt this was not suitable for our project as security was difficult to manage - it's just an impression -.

• Firebase Hosting exposes apikey in /__/firebase/init.js.
• I'm worried about the protection of apikey only with the HTTP referrer.
• With Cloud Functions, It seems difficult to control such as limiting the functions that can be used by the user.
• I felt that it would be difficult to separate development and production. And little bit troublesume to deploy.

apache or nginx:
Since nginx had a reputation for being newer, faster, and more resistant to heavy loads, we decided to nginx.

Abount tomcat:
In other projects, the JAVA system is operated by tomcat, so the candidate application server is tomcat. However, we decided not to use JAVA as the development language, so it didn't make sense to use tomcat.

nodeserver:
There is an advantage that javascript can be executed on the back end, but management is troublesome when the number of programs is large. When javascript file is added, it must be registered in index.js.
If we need to use JavaScript for backend processing, use nodeserver as an exception.

Select Database

Since we are targeting business software, a database is essential for the backend.
Since this project is for new web application, there are no special requirements from application team, so I can choose it according to the preference of the infrastructure team.
We examined the following options.

1. Install DBMS on our server (Oracle / PostgreSQL / MySQL / SQLite ... )
2. Cloud SQL ( see Official documents / Google Cloud databases )
3. Firebase Firestore or Firebase Realtime Database

Install DBMS:
We have experience in construction and operation with ORACLE. Like your system, it was hard to deal with frequent problems such as backup operations, exhaustion of tablespace and temporary tablespaces, and lack of redo logs and so on.
Based on that experience, I didn't want to have a DBMS on my own. We decided that the cloud service should be used unless there are special requirements on the application side.

About Cloud SQL:
In Google Cloud you can also use SQL DBMSs such as MySQL, PostgreSQL, and SQL Server. This time, the adoption was postponed for the following reasons

• Setting is a little troublesome, such as having to create a unique instance
• In some cases, operations such as starting and stopping instances occur.
• More instances to manage, so monitoring is also needed
• It can be operated automatically, but you also need to worry about backup.

I felt that Cloud SQL would be a little operational. To put it the other way around, you can control the details yourself, so it may be perfect if you have such operational requirements.

Firestora or Realtime Database:
For this project, we wanted to reduce the operational load to the maximum, so we chose Firebase because it has no complex settings, is well documented, requires no maintenance, and doesn't have to worry about future scale-up support.
Firebase has two types of DB, Realtime Database and Firestore. Since the target system this time is a general Web system, select Firestore. ( see Official documents / Choose a Database: Cloud Firestore or Realtime Database )
It might have been a bit of a hassle for app rep because they can't code with the SQL they're used to. However, the documentation is extensive, so it seems that they got used to it immediately.

Authentication

Using Firebase Authentication was a natural conclusion, as we have already decided to use Firebase as our database.
On the contrary, I didn't know any user account management services other than Firebase Authentication, so I had no other choice.
Abount Firebase Authentication:
Firebase Authentication has all the necessary functions such as confirmation by e-mail when creating a new account, in that e-mail user is guaided to the initial password setting screen, send request to reset fogotten password, cooperation with Google and facebook account, etc... It is very helpful.
If I had to build an account management system on my own, I would have wasted a huge amount of time.
This is definitely recommended.