API Language

• Status: Active

• Last Modified: 2023-06-30

• Related Issue: #27

• Deciders: Lucas Brown, Aaron Couch, Sammy Steiner, Daphne Gold, Billy Daly

Context and Problem Statement

This ADR is to decide what programming language the API server for simpler.grants.gov will use. This API server will initially be responsible for responding to queries to search a replicated database, but will grow to encompass all the back-end responsibilities of grants.gov

In addition to the Nava and HHS teams ability to develop and maintain an API in the chosen language, it is also important that this language lends itself to open source engagement.

Decision Drivers

• Nava and HHS familiarity with language and common libraries

• Performance of language and associated frameworks at scale

• Support of Open Source community

• Cost of necessary licenses, support, etc.

Options Considered

• Python

• Javascript and Node

• Java

Decision Outcome

Chosen option: Python, because it is free and open source and designed to be easy for anyone to learn quickly and contribute. Additionally, while all the languages can support the technical needs, Python in particular is optimized to handle the large and complex grants.gov dataset, and makes other parts of the project simpler, including ETL and data analysis for the analytics endpoints.

Positive Consequences

• We're hopeful that this choice will lead to open source contribution and adoption

• We can make use of python libraries designed for complex data queries to quickly deliver features and analytics

Negative Consequences

• Will require some context switching when going from work on the API to the front-end

Pros and Cons of the Options

Python

Python as a scripting language is fast and productive. Web-based applications can be created quickly and the code is highly readable. Python syntax is easy to understand, well-defined and extensible. APIs built over Python are highly scalable, reliable, and fast.

Because of its popularity in the open source community, Python makes it easy for open source contributors to support our work.

• Pros

  • Nava and HHS experience with Python and APIs built with Python

  • Number of available libraries and frameworks

  • Robust data science and algorithmic libraries

  • Free and open source to use

  • Ideal for data computation and complex database queries

• Cons

  • Single threaded locking of GIL can make computationally expensive operations slower than other options

Javascript and Node

Node JS is used to build fast, highly scalable network applications based on an event-driven non-blocking input/output model, single-threaded asynchronous programming. It also suits well for microservice-based products. Such Node.js utility is accomplished by such characteristics as support of a non-blocking input-output and a significant number of connections.

Because of its popularity in the open source community, Javascript and Node makes it easy for open source contributors to support our work.

• Pros

  • Nava experience with Javascript language and Node based API servers

  • Fast single threaded but asynchronous event driven operation

  • Free and open source to use

  • Same language as most front-end apps requiring less context switching for developers

  • Could use the same framework for front end, simplifying infrastructure

• Cons

  • Not as mature as other options

  • Responsiveness may be slowed by any CPU intensive computation

Java

Java is widely used for building enterprise-scale web applications as it is one of the most stable languages on the market. Java’s advantages include platform independence, multi-threaded processing, automatic garbage collection, and security.

Because of its proprietary nature, Java is not as popular with the open source community, which adds some barriers for open source contributors to support our work.

• Pros

  • Multi-threaded processing

  • Long track record of reliability and stability as an Enterprise solution

• Cons

  • Commercial use requires expensive licenses and not as open source friendly

  • Compilation and abstraction by the Java Virtual Machine makes performance slower

  • Nava team is not as familiar with Java as they are with the other options