3 minute read

Categories:
, ,
Tags:
, ,

The release of the Trade Audit mobile app is almost here. It is currently in MVP stage, but its infrastructure is a pretty typical cloud based deployment. This article discusses design choices made, evaluating how effective they were.

Project Requirements

Trade Audit is a mobile app targeting anyone using Twitter for stock trading ideas/recommendations. This side of Twitter is colloquially referred to as “fintwit”, ie: Financial Twitter.

Twitter has a feature called “cashtags” where users can represent stock ticker symbols within Tweets using a dollar sign, for example $spy represents the SPDR S&P 500 ETF. The mobile app allows Tweets made about stocks (with or without cashtags) to be recorded, tracked via price information, and aggregated to create historical performance records for Twitter accounts.

Infrastructure

Project Structure

Mobile App iOS/Android Client

For developers not wanting a separate codebase for iOS and Android, there are 3 options:

Framework Release Language Support
Xamarin 2011 C# Microsoft since 2016
React Native 2015 JavaScript Indirectly by Facebook
Flutter 2017 Dart Google

The choice for your mobile app, if at all, depends on many factors. While Flutter lacks the maturity of Xamarin and the larger ecosystem of React Native, it is arguably the most intuitive development environment. The risk is that without Google’s continued support it may not survive, but adoption continues to grow lessening this concern.

All solutions evaluated for client-server communication should offer self-documented contracts; preferably with code generation and multi-language compatibility if applicable. Best practices to minimize maintenance is to ensure that incompatible changes to server schema will immediately break client compatibility before runtime.

GraphQL is a flexible approach and a good choice in multi-consumer scenarios with varied workloads. However, the quickest approach to get up and running is gRPC due to its clean abstraction of networking, making it transparent in code that already has proper asynchronous or streaming support.

Server-side API

The Trade Audit server-side hardware is a mix of non-cloud Virtual Private Servers (VPS) and serverless AWS. During pre-adoption phase (for bootstrapping ventures; seed investment is different) the emphasis is on economics while remaining flexible to scaling in the future. A monthly VPS server is cheaper than even a yearly reserved instance in AWS, while being more financially flexible. For stateless services leaning on proper DevOps tools including Ansible swapping out on a VPS is trivially more complicated than even the most streamlined AWS EC2 upgrade paths. The public cloud excels in (i) serverless and (ii) irregular loads, as pointed out by large companies when they decide to leave the cloud.

gRPC API and website.

There is no one-size-fits-all language or framework for server implementations. Generally this is a good reason to choose a client-server interface with multi-language support. Even if features align initially to a single server-side framework, feature growth often is better served by expanding server-side languages or frameworks in the future, especially when implementing under a microservice paradigm.

The initial server-side implementation chosen for Trade Audit is based around Akka-HTTP and Akka-Streams.

It should be noted that the Sept 7, 2002 license change will require paid licenses to use *future* Akka releases; this also won’t apply to many no/low revenue projects, and not-upgrading will likely continue to be a popular and supported choice but should be evaluated.

Databases

The data layer can really make or break an application. Trade Audit currently requires:

Implementation Type Host
PostgreSQL Relational VPS
SQS Buffering AWS
DynamoDB Key Value AWS

The AWS offerings for RDS seem to be the least compelling; both by cost and additional features over VPS. The primary reason to use public cloud is rapid scalability, and outside of AWS Aurora it seems like the same amount of effort.

Google Play / App Store Informational Website

While a lot of mobile apps can get by without a separate website, there are many reasons to create one, including:

  • flexibility not offered by Apple App Store and Google Play Store sites
  • full web equivalent, or teasing a limited feature-set on the web
  • avoiding 15-30% service fees for transactions within the app

In the case of Trade Audit, the URL https://tradeaudit.app is hosted from a GitHub Pages repository. GitHub Pages can be a simple and free option for static sites. Dynamic data for this site loads from CORS JSON requests to the main Trade Audit mobile API server, and the data is highly cacheable. There are many free (or low cost) IaaS solutions providing highly configurable caching and DDOS protection such an AWS CloudFront or CloudFlare that will protect your API layer without a separate Nginx install.

Categories:
, ,
Tags:
, ,
Updated:

You May Also Enjoy

Job Queue Execution Management using ZIO Scopes

8 minute read

, ,

Job Queues are critical parts of Enterprise workloads. Complex queues use distributed nodes, state machines, and complex scheduling to trigger and track running jobs. But when simplicity allows the best approach is to create small idempotent jobs. The smaller the unit of work the easier progress can be tracked, jobs can be restarted or rerun with minimal waste, composability and reuse are increased, and logic is easier to reason about. These are the same arguments for Functional Programming and their Effect Systems, such as ZIO. Effect systems are congruent to the enterprise job queue, with ZIO fibers performing work and ZIO Resource Management forming the scheduling and supervision backbone. An efficient job queue can be written using ZIO constructs using surprisingly minimal amount of code.

Realtime Client Database using gRPC Bi-Directional Streams and ZIO Hub

1 minute read

, ,

Realtime pushed-based databases such as Google Firebase are a convenient way to ensure clients have the most recent data locally. Data updates are automatically streamed to clients immediately as they happen, or in the case of a client disconnect, immediately after reconnecting. gRPC server streaming and ZIO Hub allow this functionality to be easily replicated and customized beyond what expensive paid-for services such as Firebase can do.

Http4s Streams and Multipart Form-Data File Uploads

10 minute read

, ,

Streaming is the primary mechanism to reduce memory requirements for processing large datasets. The approach is to view only a small window of data at a time, allowing data to stream through in manageable amounts matching the data window size to the amount of RAM available. A practical example is a file-upload, where multi-GBs file streams can be handled by MBs of server RAM. However, enforcing streaming in software code is prone to errors, and misuse or incompatible method implementations will lead to breaking stream semantics, and ultimately to OOM exceptions. This article focuses on streams within the context of file uploads, using the Http4s library for examples.

Compiling Scala Native in a GitHub Action; Alternatives to GraalVM

11 minute read

, ,

Scala Native is a compiler and JDK written in Scala with the goal of removing Scala’s dependency on the JVM. This isn’t meant to achieve a higher performance such as with JDKs, and it is targeting a specialized use-case not considered to be today’s typical Scala development. Its competitors are Rust and Go, not GraalVM, Java or Kotlin. This article goes through common steps and challenges encountered when compiling Scala Native for linux with a GitHub Action.