Non-Functional Specifications

1. Performance Constraints

Lambda Spin Up Delay

Using AWS Lambda functions gives us the ability to scale and easily deploy to alternate server locations for redundancy and lower latency for clients around the world. As Lambda functions do not persist and only spin up instances when demand requires it, we can take advantage of cost savings due to billed usage being tied to the execution time of the Lambda. However, this has a performance constraint that should be noted.

When a request is made to a Lamda function that is not already active due to a previous call, the instance of the Lambda must spin up to a workable state in order to start processing the request. This results in a small perceptible delay in request response time every time a new Lambda is spun up.

Message Refresh Timing

Initially it was planned to set up the connection to the backend for message retrieval as a persistent Web Socket link. Initial testing unearthed an issue with the AWS gateway continually dropping the connection when the Lambda terminated, and we were unable to rectify the problem in the timeframe provided. Ultimately, periodically polling the REST gateway for new messages proved to be an acceptable solution.

The current poll rate for new messages is every 5 seconds.

Free-Tier Services

As this is an assignment and not a commercial exercise, we have used the free-tier of all the services we have used. Naturally, this gives an allocation of a low level of virtualised hardware longer that results in longer latency, lower bandwidth, and a reduced capacity to handle load.

The AWS Lambda free tier is limited to one million requests per month, and has a lower priority when requesting access to compute resources. This means that we are limited by the load that the Lambda functions can handle, and their responsiveness is often less than that provided within the paid tiers.

The MongoDB Atlas free tier we configured is limited to shared virtual server running on AWS that uses a shared CPU and memory, and allows for just 512MB of storage. This limits our capacity, and increases response times, especially under periods of higher load.

The Vercel free tier has both constraints on development resources as well as reduced bandwidth. During development we were restricted to only one member of the team having direct access to Vercel, as team members are not permitted on the hobby plan, while builds are slowed and cannot occur concurrently. Pro plans also offer a bandwidth of 1TB, as opposed to 100GB for the hobby plan.

2. Operating Constraints

Member Constraints

As is often the case, the time commitment that each member was able to devote to the project differed greatly, as did the level of knowledge and each member could provide. These constraints meant that there was often only one or two members of the team that could be allocated to certain tasks, reducing the progression of the project.

Accessibility Constraints

The free tier systems we used to develop the project created several issues during development, and would be a further issue during the ongoing maintenance and operation of the application.

Each of the services we used are limited to a low-priority email-only support level. This created a major issue when Vercel suddenly stopped validating our connection for automated builds, resulting in the application not being built and deployed for an extended period. Support was sadly lacking and resulted in a lot of frustration and waisted time. In a commercial setting, this would be unacceptable. Additionally, Vercel does not allow team members to be assigned to a project when using the hobby plan. This meant that there was only one person that could deal with the issue.

3. Interface Constraints

One of the major issues when building an application for the browser is that you must take into account that it will be used in many different operating environments. More real-world testing should have been carried out using a wide variety of devices, operating systems, browsers, and form factors.

While the interface is functional, and does meet the majority of needs, it would greatly benefit from further design improvements. An example of this is that the "audio" element is rendered very differently in different browsers resulting in an inconsistent interface being presented to the user.

Another issue that this caused was with the Safari browser in particular. The RecordRTC library was chosen to record audio as we were having issues with cross-browser functionality using in-build JavaScript functions. This resulting in audio recording working in Chrome and in Firefox, but we could not get it working on Safari running in iOS. Eventually it was discovered that the latest build of Safari broke audio support in the library, however it was too late in the project to devise a solution.

Automatic scrolling was implemented in the application to ensure that the screen scrolled up when the latest messages arrived to make sure the user sees them as they arrive. Unfortunately, this proved to be inconsistent across browsers, and was unresolved at the time of writing. This results in the scroll function not going all the way to the latest messages in the message display area.

Finally, the other major issue with the interface is there is no indication when a new message is received in another channel. We added an audio alert to sound when a new message comes in for the channel the user is actively viewing, but there is no notification of a new message being available in any other channel.

4. Economic Constraints

While the application has been built using free resources, this would not be feasible for a commercial release. Each of the services we used would require migration to a paid tier.

Migrating to the Pro tier of Vercel would allow project access for up to 10 members and offer higher bandwidth for $20/month for each member.

MongoDB Atlas has a number of tiers that could be progressively moved through as demand for resources increased, starting at the M2 plan for $9/month that would give us 2GB of storage on a shared instance.

The AWS free tier we are using is time-limited to 12 Months. After the free period expires, Amazon charges based on the amount of resources used each month and is a much harder cost to calculate. Costs would be incurred based on the number of requests processed by the gateway (https://aws.amazon.com/api-gateway/pricing/) plus the amount of resources consumed be the Lambda functions (https://aws.amazon.com/lambda/pricing/). In addition, there are likely to be additional costs in setting up additional services required for a commercial deployment such as domain and routing costs if a custom domain was required.

5. Design Constraints

While the code should be easily maintainable and extendable by anyone in the team, and the frontend of the application can be deployed virtually anywhere, there is a major design constraint that is a biproduct of utilising a serverless backend.

As the backend functions are written specifically to take advantage of AWS Lambda functions, migrating the backend to a different provider would be a difficult undertaking. Every lambda function would have to be partially rewritten to run on a different system even if the system still utilised NodeJS. This vendor lock-in is an unfortunate side-effect of cloud services.

Even more intrinsic to the design of the application is the MongoDB database used. While migrating the data set to a different MongoDB server such as moving to a self-hosed build would be trivial, migrating the service to a different database system would be a massive undertaking. Every interaction with the database is coded as MongoDB function calls, and would require the backend Layer functions be entirely rewritten.