A monolithic web API built on NodeJS/Express
- Authorization through temporary token submittal
- NodeJS and JavaScript (ECMAScript 39)
- ExpressJS as the middleware
- TediousJS for SQL in Node
- AWS Elastic Beanstalk. Deployed this application in Elastic Beanstalk from source code.
- Docker for containerizing this application.
- AWS ECS. Deployed this application on AWS ECS as a container
- Azure App Service. Deplyoed this application as an Azure App Service from soruce code.
- Cloud deployment of NodeJS apps to Amazon AWS and Microsoft Azure infrastructure.
- This application was first deployed as an Azure Web Service. I used remote github deployment which allowed me to update the application whenever a repository change was detected. I did not use auto-scaling.
- This application was also deployed in AWS Elastic Beanstalk. I uploaded the source code as a folder to the AWS portal, which was a more cumbersome proccess than using a github repository. Once again, I did not use any auto-scaling settings. In the case of AWS Elastic Beanstalk, auto-scaling is automitcally enabled.
- Monolithic applications are not fesible for most production environments. This application is prone to errors upon load increase.
- This application was again deployed on AWS, this time on AWS ECS. The application was turned into a docker container and then uploaded to AWS. I found this proccess to be very easy with NodeJS. This proccess was maybe more powerful than the other deployment methods because the applciation has access to a full containerized environment.
- NodeJS call limits are a problem. Though NodeJS is singlethreaded, it is lightning fast for IO operations and in proccessing requests. When the servers load increases, there will be a threshold in which API calls are no longer responsive. This is usually because of a slowdown in the API call it self, not because of NodeJS's connection limits or expenses.
- SQL calls are the most time intensive per-call function invokation in this application. While certain queries will be slower than others, query optimization would be an easy way to achieve performance gains.
- Microservices addresses the above problems by spreading the load throughout multiple instances of the application. This differs from a monolithic application because the code is split further into seperate applications, usually in independent projects. Using seperate services increases the modularity of the entire application by allowing flexibiltiy in programming language and in development.
- While each application instance has the same aformentioned limits, each application should stay under their own load limit by having the service scale out. Popular approaches to this a few years ago would be SaaS platforms to automate the scaling layer, such as AWS Elastic Beanstalk or Azure App Service. More popular approaches now include containerized environments, such as AWS ECS or AWS EKS.
- Monolothic applications cannot be directly deployed as a Microservice app.
- Microservices require inter-application communication. No longer is it feesible to use simple timers or scheduled tasks because each instance of the application would be doing the same tasks. Many Microservice frameworks solve this issue. There are some SDKs that do this, such as ZooKeeper. Various SaaS applications can also achieve orchestration.
- A lead Netflix engineer gives a detailed history of the evolution of their technology/backend, making it clear that the lack of modularity and cripple larger projects. Large applications can suffer from a large amount of dependencies that can make updating their software extremely time intensive.
- API routes should be clearly defined and accesible to programmers, clients and servers. By avoiding hard-coded URLS or IP addresses the application becomes easier to update and more modular; most Microservice frameworks provide this functionality.
- Rewrite this applciation into an application per serivce using microservices.
- Avoid chained database calls one-after-another. Write queries to do more in each query.
- Hash passwords and emails. Instead of storing raw password and other sensitive data from the server into a database, store (hashed data)[https://jwt.io/]. NodeJS does not have hashing built in, so a third-party SDK like the Crypto package is required.
- Replace string token authorization with JWTauthorization. This allows for a client-server handshake and potentially encrypted connection data. The connection it self is not encrypted or using SSL or HTTPS.
- Use headers to authorize user instead of a query parameter. This includes JWT fields for encryption.
- Allow flexibility in query parameters and JSON post data.